Defining “Done” (or, the role of QA on an agile project)
Quality assurance testing is an important part of any software project, but QA is especially important on an agile project. This is because in an agile world, we are striving for higher quality, quicker turnaround times, and more frequent releases. This requires that QA is in step with the rest of the team.
On many of the projects that I have been on, the relationship between QA and the rest of the team is decidedly un-agile. Instead it has worked something like this:
- BA writes the technical specifications
- Developer starts working on the feature, and might discuss the feature with the BA to iron out the details
- Developer completes the feature and throws it over the wall to QA
- QA begins to test the feature
There are many problems with doing things this way.
- The QA team has not been included on any discussions about the feature, so they might not be privy to some important information that came out in dicussions between developers and BAs
- The developers have developed the feature without having a test plan from QA, so they don’t really know if QA will find bugs or not
- There was no discussion about how QA should test the feature, so QA might not know how to write a test plan
- It might take time for QA to write the test plan and test the feature, and by that time, the developers might be several days into the next feature
- This leads to situations where developers give features to QA without being sure that the feature is completely working (they just didn’t think of something)
- This leads to an “us vs. them” mentality between developers and QA people
This is not agile, this is more akin to the “Scrummerfall” methodologies that many projects fall prey to. The main problem I see with this is that there is no definition of “done”. If a developer doesn’t know what it takes for a feature to be complete, how can you expect them to complete a feature without any bugs?
I would argue that QA should be involved much earlier in the process. Before a developer writes code for a feature, they should have:
- Detailed technical specifications from a BA, including a list of acceptance criteria
- A test plan from QA outlining how QA will test the feature
- No outstanding questions on what the feature should do (or at the very least, a plan to get the answers within a short time, if it’s a minor question)
Now we have a true definition of what “done” is. Not only that, QA has been involved in discussions much earlier on in the process. QA will be able to discuss with the development team how they will test the feature and they can point out edge cases, potential problem areas, etc. This way, when a developer finishes with a feature, there should be no bugs, because the developer will go through the QA test plan to ensure that everything is working from a functional perspective (along with writing unit tests for their code to ensure that their code is working from a technical perspective).
This feels more like agile to me. Agile is more about building quality into the software development process instead of trying to verify quality through brute force testing. QA has now taken on a new, better role in the process.
- Preventing bugs instead of finding bugs
- Quality assurance, not quality control
- Collaboration with the development team, instead of trying to keep developers under control
- Removing the proverbial “wall” between QA and development
This may require QA to work differently than they have in the past. QA testers will need to be more involved in the software development process, with many of the skills that a BA would need. They might need to learn how to use automated testing tools, which may require some basic programming skills. QA testers will need work alongside BAs and developers while a feature is being developed, writing and refining test plans as you go. Sure, there is still going to be some manual clicking-through-the-app testing, but there should be much less of that now.
To me, this makes much more sense. Now the entire team is working together to build quality into the application. This means less bugs, better team morale, and faster delivery of software. And who doesn’t need more of that?
