Insight for: QA
The price of an error in each individual case may be different. Occasionally, correcting a defect, regardless of the stage of its identification, will not cause considerable losses. And in some cases, there will be inevitable material and reputational damage. Moreover, in the second scenario, there is often a direct dependence: the later an error is found, the more expensive it is to fix.
Let's talk about the problem and its solution using the example of software development and the Shift Left Testing (SLT) method. According to research by the Rothman Consulting Group, the cost of fixing bugs after product release is on average 20 times higher than during full-scale multi-step testing during development. Logically, the concept of testing as a separate final stage of development seems unviable where quality needs to be ensured in a context with high development speed. As a result, Agile emerged as a counterbalance to the traditional (Waterfall) model.
The principles of it should have built the position of testing as a continuous process rather than a separate stage. However, the misunderstanding of Agile methodology often ends up only in the introduction of formal rituals and ceremonies, without qualitative changes from the inside. Once again, there is no panacea. Shift Left Testing (SLT) is remarkable as it requires revising the processes at the root, which you can't imitate with external attributes.
The idea of the approach is not new and once again states the well-known commonplace truth "Measure twice and cut once". The point is simple: start testing before the code is written. This way errors will be detected and corrected before they are actually digitized, which will significantly reduce financial costs and risks to the project and, therefore, speed up the process and improve the quality of the final product.
The SLT can be summarized literally in 6 points:
The method, as an extension of Agile principles, can be interpreted in the traditional development model as well. Improving product quality and communication, speeding up the process, increasing product loyalty, increasing productivity seems to be the pluses of Shift left testing.
But will it affect the final cost of the project? Yes, the cost of development can increase at the stage of SLT implementation: early testing, new tools, high proportion of communication will inevitably entail additional costs. Costs where there were none before.
However, when considering an SLT implementation that focuses as much as possible on the early stages of development, it is worth remembering that its goal is to solve problems that arise at the very end of the process. Therefore, in the long run, you will definitely find significant savings on bug fixing.
Of course, claiming that Shift Left Testing is a cure for all ills is impossible, the benefits of SLT is directly dependent on the specific project and a number of factors, such as the size and maturity of the team, the complexity of the product, customer engagement and, of course, the desire to change something for the better. And the latter is probably the most important factor.
Our pilot implementation period was based on a simple and understandable flow: a QA specialist starts working on a task at the backlog level. During the process, they analyze requirements, ask clarifying questions, and create an acceptance checklist covering both system and user aspects. Then, developers review the testing documentation before starting actual coding. This ensures that requirements are interpreted into specific checks that developers are aware of in advance. Specialists focus not only on technical implementation but also on delivering value to end-users. The probability of misunderstandings in task requirements is minimal, and the expected result is transparent.
In terms of numbers, our experience has shown that early testing activity by one QA specialist on a task takes 2-5 hours. It's difficult to estimate time saved on bug fixing and retesting, but feedback from the development team confirms that SLT focuses on details often missed during coding. Even basic math shows that a few hours of additional activity by one specialist on a task is much cheaper than the work of the entire team on bug fixing and retesting even one, albeit not the most significant, bug.