Shifting quality to the left

Aside from building in quality, another way of summarising the agile approach to quality is “shifting quality to the left”. Part of the shift means NOT treating testing or quality assurance (QA) as a phase which is done after development, or as a function which is owned by a separate team or individuals.

This even applies when working in two-week iterations / sprints. There are no hand-offs to testers in agile teams. They treat quality as a continuous and collaborative focus.

Some of the core practices which support this approach are:

• Continuous Delivery (CD)
• TDD (Test Driven Development or Design)
  • Including continuous refactoring
• ATDD (Acceptance Test Driven Development)
• BDD (Behaviour Driven Development)
  • Including the “3 amigos” conversations
• Continuous exploratory testing (i.e. exploring the product for edge cases, fitness for purpose and other quality considerations as opposed to simply “testing stories”)
• Automated regression checks (these come for free when practising TDD and ATDD)
• Exploratory testing – This should be done frequently on a product-wide level (by product owners, testers and others) in a fully integrated environment so that bugs, missing behaviour and poor UX outside of a team’s current sprint/feature focus can be identified and rectified early.
• Fully integrated working product – ****Rather than testing versions of the software which only have the current developer’s feature branch integrated rather than all the latest features, it’s way less risky to have a production-like environment always available with ALL of the latest (development complete) features. This way, the system simulates what the real production system will be like when all features are released. See “Deploying and Releasing”.
• Zero bugs policy – Bugs should be seen as something to eliminate and prevent. The existence of big “bug backlogs” is a leading indicator of poor quality in the product (where it’s easy to introduce further regression bugs, product/features not performing as the customer expects, etc.) and a culture of tolerating/accepting bugs. Bugs slow you down. They drastically reduce your capacity for value-adding work, both in the short-term and longer term. The way to deal with bugs when they arise – especially regression bugs – is to immediately add a new unit or integration test which only passes when the bug is fixed. This means the bug is not only fixed, but it is guaranteed to never return. This means a change in process. You might choose to defer certain types of bugs (e.g. isolated cases on obscure browsers), but as a rule it is better to have a zero-tolerance approach to bugs because it contributes to a culture of quality. If you already have a bug backlog, it is worthwhile doing root-cause analysis on those bugs to see which ones are regressions, which ones are related to a particular part of the system or codebase, remove duplicates, etc. – then follow the process for each bug as described above.