Everybody’s been there. You’re working on an important project with a stringent deadline. You’ve hit a few snags along the way, but it looks like you’ll deliver on time. Just one week left to devote to finding and fixing bugs.
But then things start going badly. All mistakes, assumptions, rushed hacks, and misunderstandings surface simultaneously. The open issue count is higher than the number of stories across the project. Everyone is working nights and weekends, and even still, you miss your deadline.
If this happens every time a project meets its time to be tested, your QA process is likely the bottleneck. While the knee-jerk reaction might be to hire more testers, it’s more prudent to revisit your current process to locate inefficiencies, so that issues can be mitigated and avoided in the future.
One of the issues with the linear process is that when a problem is found, it is often assumed to be the fault of the developer. However, any of the largest, most impactful mistakes are made at a different point in the process, whether from product, design or somewhere else. For example:
Product Issues
Task Issues
Flow Issues
Design Issues
All of these are basic mistakes which should not happen, but it is most often not a question of the people – every member of your team will make mistakes. Their work is difficult, repetitive, and takes time. On top of that, their work is always rushed since the rest of the team can’t even start working until they have completed much of their work for the project.
Testing was born out of the realization that there will be mistakes in the development process. The integrated QA process takes this lesson and applies it to the entire project, from top to bottom.
The difference between the linear and integrated QA process is that the latter takes into account the fact that ALL project members – not just developers – will make mistakes. The QA team test the project continuously, not just when it is a completed app. The major advantage is that a product can be viewed at any point in its life cycle and issues can be recognized immediately. Things like product specs, flow, tasks and designs are looked at before the developer starts work. If there are issues, they can be corrected before development even begins.
The integrated QA process creates a completely different project flow:
Despite initial appearances, the integrated QA process saves a lot of time and frustration when practiced. The following highlights its advantages over the linear process, using an issue created at the product stage as an example.
If you look at this case in the linear QA process, it is an absolute nightmare. And this is from one small oversight, which happened to affect the entire team. Imagine what could happen if multiple mistakes were made?
On the other hand, in this same case the agile integrated QA process addressed the minor oversight in the first week. It was corrected before the spec doc even got to the architect, and the project continued as planned.
The integrated QA process also offers a number of additional benefits, which include:
By going agile and choosing to adopt the integrated QA process, teams can significantly improve the quality of their project, while ensuring that deadlines are met. Integrated QA simply provides added benefits that linear QA cannot.
This is the third post in our six-part series, Better QA. Read post #2, The Benefits of Using a Build Machine.