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:
Some common ways of moving QA earlier in the release cycle are:
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.