How does QA fit in?

Question from Liz:  The team and I are starting agile and we can’t get much info on where QA fits into Agile.

Answer:
First, I want to reiterate Jeff Sutherland’s concern (mentioned in this blog post), that the biggest problem is too many teams are not getting to working product (working software) within a Sprint (a 1 to 4 week consistent time box).

In my view, the absolute minimum Definition of Done for a typical software “story” or PBI (product backlog item) is:
* [requirements were defined]
* coded
* unit tested
* functionally tested (aka testing by the QA folks)
* all identified bugs fixed
* reviewed by the Product Owner, and all ‘problems’ fixed

This is the minimum definition, and might be this low if one starts with significant impediments.  The ideal definition includes ‘live, in production, being actively used by the customers with normal volume.’

Now, let’s add a key principle: The bad news does not get better with age.  In other words, it is much cheaper to slow down, test and fix now (even though it does have some cost) than to not test in the Sprint and discover the bad news later (where the price is much higher).

So, good professional testers must be in the Scrum team.  Ideally that means 1 or 2 testers 100% allocated to one team (that is 7 people, including the PO and SM).  In rare cases, maybe 3 testers.  If ‘everything’ were automated, one might imagine 1 tester in a team of 7….seems unrealistic to me.  At a minimum, the testers are 50% allocated to one Scrum team.

So, then: Where does QA fit in?  Well, the QA people are the testers usually.  Sometimes QA means truly “quality assurance” per se, in which case the QA people look at the Scrum team (and the process elsewhere as well) to see if sufficient quality is being baked in the best possible way.

We are also asking that coders help testers, and vice versa.  Each side no longer looks at the other as an enemy.  Still, the testers are always trying to “break it.”  So, they maintain that attitude.  And each coder views any break identified now as a ‘win’ for the team, not as a loss for his ego.

Also, in most firms there is a ‘landing strip’ (my name for it) which includes the final testing where the code of say 3 teams comes together into one stream.  It is ‘finally’ tested. (With some bug fixing, and a final release candidate.)

A common pattern is that a ‘test scrum team’ does the final testing, and sends bugs back to the ‘development’ teams.  Obviously, QA people populate most of the test scrum team.   This is a common pattern when you have lots of impediments; and not a bad pattern in that situation.  (A better pattern, if possible, is each team releases independently, and we do not need a ‘test scrum team.’  Not always possible, at least now.)

Hope I answered your real question.
There are other situations and complexities that might be addressed, but I wanted to hit the highlights.

 

« « Release Planning: Business Value Points || Getting higher velocity! » »