“Integration” is one of those loaded business words that sounds terrific in theory but is hard to put into actual practice. When it comes to integrating quality assurance with scrum, Tommy Norman aims to demystify the process in a meaty article at InformIT.
Norman has four tips at the heart of the discussion:
- Know the Underlying Agile/Scrum Principles Regarding Testing
- Find and Remove Impediments to Adopting Agile Values Before Modifying Your Process
- Learn and Test as You Go
- Accept That It’s a Journey
For that first tip, you need to remember that a big tenet of undergoing a sprint is having a “release ready” deliverable at the end, whether or not it is intended for actual release. With a sprint, you commit to get something “Done,” and a sprint whose goal is to fix bugs is not a sprint at all. In the beginning, it can sometimes feel like the sprint does not go on long enough to finish on time, but such feelings usually are indicative of deeper problems. This relates to the second tip. Norman likes using a “Why?” technique, which he asks when presented with a problem, and he keeps asking why until he hits to the core of the problem at hand.
The third tip has very much to do with QA, who Norman says have been indoctrinated by waterfall processes to believe that testing cannot begin until an application is complete. You need to get QA on board as soon in the process as you can, and Norman provides an idealistic example:
Agile is a big proponent of short feedback loops inside a Sprint, and a team with tight collaboration between software developers and QA analysts can test elements of a feature before it is completed. A developer might be writing a web page to capture customer information that includes their name, address, contact information, and tax number. If they are developing the feature iteratively, they might get just the name and address working all the way first and have QA take a look at it while they work on the contact information section. If QA finds an issue, they can discuss it with the developer who can add a task to the Sprint Backlog to address the issue and the test case will be updated to not allow the issue to escape the Sprint.
The final tip then becomes self-explanatory. There are no sure things in IT, not even in Agile, but you take the good with the bad and you learn as you go. That versatility is kind of the point of Agile. To read all of Norman’s informative article, you can click here: http://www.informit.com/articles/article.aspx?p=2179295