Continuous Testing Manifesto
4. Shift Left
Traditionally, QA gets involved later in the software development lifecycle. The earlier you can start testing, the easier most issues are to fix. Why? Slower feedback cycles create distance from the problem. Developers become forgetful and shift to other tasks, losing context. Additionally, code can change under them, complicating the process of fixing the issue.
Testing earlier surfaces errors more quickly, tightening the feedback loop between QA and development.
Shortening the entire development cycle brings other benefits too. A major one is reducing the risk of shipping the wrong thing, as you get feedback from users quicker.
Some reasons to avoid shorter release cycles include:
- Regulatory issues around changes.
- Shipping embedded or on-premise software.
- Having customers that are highly averse to changes.
Some common ways of moving QA earlier in the release cycle are:
- Pull Request-based development combined with automatic environment creation. Every pull request automatically has its own environment setup. This can be home-rolled, or provided by an external service. This allows human-powered QA, or automated integration tests, earlier access to changes in the SDLC. Setting this up can be a pain, however, as following good dev/ops practices are a prerequisite.
Example SaaS services for this:
Generally, manual QA by non-developers isn’t practical before pushing to a pull-request. This is due to speed and cost of the resources needed; developers are fast, expensive; manual QA can be slow. Automation helps solve this, if used correctly, as it may be executed on a developer’s machine. This allows developers to get feedback as early as possible in the SDLC, while coding. They still have context around the errors as they occur, which makes fixing them faster.