Is QA always the bottleneck?
We live in a fast, agile world with an instant need for gratification. In the software world, we want to follow continuous integration continuous deployment so we keep adding value in increments. We have learned to break features into the smallest chunks and push it to production.
In this extremely fast-paced software world, I have often heard QA experts, Engineering leaders, and QA Engineers ask if they are being a bottleneck.
I find this question to be a philosophical one. Why do we call QA time a bottleneck? Is it because QA is actually taking way longer than they should to move work ready for merge? Or is it because the rest of the team thinks QA should be quick, way quicker than we actually are?
Let’s breakdown this question a bit more.
- What is the ratio of Developers to QA in your teams?
There is no universal formula which can provide us the ideal Developers to QA ratio. There are a lot of factors, like SDLC in the company, the complexity of the application, requirements, etc., which impact the speed of work and the time & effort needed by the QA Engineer. But most experts agree that 3 developers to 1 QA is a good ratio. If there are more than 3 Developers including UI engineers in the team, the likelihood of QA being slammed with work is higher and on the surface level, this would seem like a bottleneck issue.
2. Can we just accept that QA comes at the end of the life cycle?
I think the origin of QA being the bottleneck might have to do with QA being a dispensable part of the software life cycle. However, we have already proven that QA is an integral part of the ecosystem. We are the Quality advocate and last line of defense for the quality of the application. Development is probably the longest part of the Software Development Life Cycle. We rarely panic at this stage. We also spend a good amount of time in code review and design review. Again, no panic. However, the panic starts almost as soon as it hits the QA bucket. Can we really start testing a piece of work when it is still in development? Not really! We can certainly get our test plan and strategy ready. We can start writing our automation tests. But we do need coding, review, and design review phases to be complete before we can actually start the manual testing. If we truly accepted that QA is an integral part of the cycle and happens to be at the end of the cycle, we are probably not going to see QA as a bottleneck but rather just another phase.
3. Then is it an issue of differences in estimation expectations?
QA Engineers have made a great shift from running a full regression suite and testing every edge case for the feature, to now relying greatly on exploratory testing and regression testing only the part of the application we know is touched. In other words, we fit in just right with an agile world equipped with methodologies suited for a faster-paced environment. Then the questions arise: Are QA Engineers communicating clear estimates to the team? And are we bubbling blockers to the stakeholders as soon as we get stuck?
4. Are there other hidden blockers?
There are multiple other factors in my opinion which can seem like tickets are taking longer in the QA phase such as:
a. Available QA environments: In many companies I have worked, there was considerable wait time in order to have access to a QA environment. In some cases, even though the environment is always available, the QA engineer needs to prep data which might take painstakingly longer.
b. Frequent context switching: This has become far more common with very fast paced environments and believe it or not, switching context more frequently than needed can impact the time it takes for QA engineer to finish her tasks. It takes about 25–30 minutes to re-focus on a different or same task.
c. Unclear requirements: Unclear or not fully fleshed out requirements will add some delays and might cause the slice of work to go back to developers.
d. QA not being part of the planning phases: This is a huge factor which will contribute to QA Engineer taking longer to test something as she would have to understand the work from scratch and ask basic questions about how the new functionality should or should not work. Involving everyone in the delivery team during the planning phase will help with a clear understanding of the requirements.
e. Complexity of your application: This is another factor I have seen take QA members way longer to test, though it might seem easy. The more complex the application, the longer it will take any QA to test something ‘small’.
To sum it up, if you find yourself asking the question if QA in your team is a bottleneck, I encourage you to look underneath that question before you arrive at a conclusion. Happy Testing!
