“Quality comes not from inspection, but from improvement of the production process.“Edwards Deming
Why is this important?
Product quality is critical for satisfying customers and retaining their loyalty, so they continue to buy from the business in future. Quality products are critical to the long-term revenue and profitability.
Traditional, plan-driven testing frequently leads quality problems and delivery delays due to bottleneck
Plan-driven approaches allocate time for testing towards the end of development.
It may seem practical allowing to test entire system through several quality assurance cycles and fix (“debug”) the entire, integrated system at once. However, when defects or usability issues are inevitably found late, the release will be delayed until these have been fixed. In this model, testing usually becomes the bottleneck that seriously impedes the ability of projects to deliver on time and achieving high product quality.
It is always cheaper to fix bugs earlier on in the development cycle rather than stabilize the completed system with deep-seated defects. Moreover, developers will have to refresh the code in their mind incurring additional so-called switching costs. The time gap between changing the code and running all necessary tests on this code must be minimized in order to reduce the costs and improve the product quality systematically.
Test early and often – “shift left”
Agile practices encourage to “build product quality in” through process improvements including faster, earlier and more frequent testing in the software development lifecycle (SDLC). Bringing development and testing together early is commonly referred to as ‘shifting left’.
To overcome the testing bottleneck of the plan-driven model, agile product development moves the initiation of testing as far to the left as possible beginning at the requirements gathering and product definition stage intended to find and prevent defects early in the software delivery process. The idea is to improve quality by moving tasks to the left as early in the lifecycle as possible.
Cost alone is a very strong incentive for shifting your testing to the left. It has been estimated that over half of all software defects could be identified during the requirements phase, with less than 10% emerging during the development phase of the lifecycle. The cost of resolving these defects works in reverse:
A defect that is removed after the product has gone into product will cost around 100 times more than one that is identified and removed during the requirements phase.
The following pages discuss common approaches and practices to build quality into the product from the start of the effort.
Inspired by the blog post: