What does agile QA look like and what distinguishes it from traditional approaches? There are two ways to answer these questions. You could describe what QA would look like if you incorporated it into an agile framework like scrum while staying true to the underlying principles. Or you could describe the way development teams attempting to be agile are actually approaching QA in reality.
You’d think the two answers would be the same, but there’s a disconnect. Many dev teams still think of the QA people as last-minute code editors. When these developers finish the coding for each sprint, they hand it over to one of those infamous walls dreaded by agile enthusiasts, hoping what they’ve written passes inspection. This assembly-line approach is a holdover from the days of waterfall.
Interestingly, there’s another camp that goes to the opposite extreme from thinking of QA as an entirely separate—and somewhat antagonistic—team. This camp believes that since developers are now so often creating their own automated tests, and since new features and updates are expected to be rolled out in short iterations, QA as a separate specialty is headed toward obsolescence. (This viewpoint is often supported through references to the diminished role of QA at Facebook.)
What’s clear is that as more dev teams adopt agile practices, the role of QA is being forced to change. It shouldn’t continue to resemble some type of final pre-deployment inspection, but nor should you think you can do away with it altogether (and rumors of QA’s death at Facebook are greatly exaggerated).
One Function of the Cross-Functional Team
Software developers are learning to play a part in QA as they write automated unit and integration tests for their own code. At the same time, though, QA specialists are getting involved earlier in the process, often during sprint planning meetings. So, while certain parts of their roles are being taken over by developers, other aspects of their roles are expanding.
The claim that QA as a specialty is on the wane is predicated on the false notion that QA is synonymous with testing. But automated tests are only good at certain tasks; they may be good for identifying areas of buggy code or integration issues, but quality is about far more than functionality.
Think of a sentence you write that gets nary a green or red mark from Grammar Check but ends up being gibberish when you go back and read it. With software, too, there are quality issues a human would be able to detect at a glance that a machine would miss entirely. Just as there’s more to good writing than grammatical correctness, there’s more to quality software than a lack of bugs.
Rather than careening toward obsolescence, Quality Assurance is finally being incorporated into the cross-functional teams that distinguish scrum from waterfall. You shouldn’t be hearing developers talk about “passing the feature through QA” anymore, as if it were the final station on an assembly line; the QA people should be working alongside the developers the whole time.
In place of the final-stage inspectors from the waterfall days, QA specialists are being tasked with creating overall strategies for testing and quality control. That’s why they’re participating in
sprint planning meetings; quality software is defined in terms of its business value, so to ensure quality you have to know the user story each feature is being built to support.
Risk Assessment and Prioritization
If you’re wondering whether it’s best to do testing and bug fixes at the end of the current sprint or at the beginning of the next one, then you’re still thinking of development as progressing through assembly-line stations. You should be testing throughout the sprint: performing unit tests as you build features and then regression and API tests as you complete them.
Your QA specialists are often the ones who do the regression tests, but they can guide your dev team as they create unit tests as well. Then there are system tests and user acceptance tests. The QA’s role is to create a general approach for how these and other tests will be applied from the outset of the development project to its completion.
The main thrust of this more strategic role is prioritization. For each sprint, you’re dealing with a certain amount of code which has to be written and tested in a certain amount of time. With a potentially infinite number of edge cases and different types of invalid input, there’s really no such thing as 100% coverage of any complex application. So quality experts have to consider the user story behind each feature, determine what the greatest risks are, and decide how best to minimize those risks.
Assuring Quality the Agile Way
This kind of sprint-by-sprint iterative prioritization replaces the waterfall approach of copiously documenting every test case upfront and proceeding by ticking them off the list sequentially. Agile methods are based on the understanding that the more you work with an application the better you appreciate how it should work. So those test cases written at the outset are like sandcastles set to be washed away at high tide.
But, while you may be doing away with comprehensive documentation, applying scrum also means working to shorten the feedback cycle. With waterfall, developers often received reports of problems months after they finished coding the feature. With agile, they can be getting immediate feedback from automated unit tests, more feedback after regression tests, and still more feedback from product owners after demos.
These demos, incidentally, should also be thought of as part of testing. If the feature fails to support the user story—if the software doesn’t help users do what they’re trying to do—then it won’t matter if the code is completely bug-free. This is why it’s so important for the quality expert to understand the purpose of the application, which is in turn why you’ll want to include him or her in the planning stages of the project.
Scrum and the agile framework are essentially efforts to make as much of the development project as possible about delivering business value. This is achieved by breaking the overall project down into smaller subprojects—iterations—and taking them on in order of priority. Quality Assurance for scrum projects should work the same way. You test with an eye to what will most directly help users accomplish their goals, and you prioritize guarding against the bugs that pose the greatest risk of preventing them from doing so.
Also check out: