Many of us have heard the phrase “Test Early, Test Often”. There are quite a few blogs and articles out there explaining how testing early (catching defects early) reduces costs in software development efforts. It’s documented, and not many people really need to be convinced any longer.
So a recurring question I’ve been asked lately is “…at what point does QA get involved?” The simple answer is…as soon as possible. Testing early and often is no longer an Extreme Programming thing; it is an agile thing, which means that as a Product Team is thinking about the cool big idea, QA should be in there helping the team understand how this cool big thing should be tested.
Mostly, though, QA should be in there helping develop the personas and writing the stories. I keep hearing over and over again how even mature agile teams are still gold-plating the deliverables because they are not REALLY doing test driven development. So picture this:
- Product Teams break Epics or Features into Stories: QA helps by first writing out some very basic conditions of satisfaction
- Once the conditions are agreed upon, QA writes the Acceptance Criteria
- Story is fleshed out by the Product Team
- Core team now has very specific criteria to make tasks and code to
- Business Rules include a certain amount of traceability to the acceptance criteria
So, instead of having QA involved when the story is decomposed, how about having them involved earlier and more often in the story writing process?
For some additional reading on testing, feel free to refer to: http://www.versionone.com/pdf/WP_AgileTester.pdf