You are right, let’s shift left!
Shift-left testing is an approach to software and system testing in which testing is performed sooner in the software development life cycle. Debugging is often a case of finding a needle in a haystack. The smaller the haystack (the code you’re looking through) the easier it is to find the needle (or bug). Testing continuously and early in a confined scope ensures the epigram.
Why do we want to shift left in quality?
- To develop a cost-effective faster feedback loop for the developers to catch impactful bugs early in the lifecycle.
- To enable the organization to release faster with quality standards intact.
- To enable teams to fail fast and fix fast.
- To test and scrutinize codes multiple times in the workflow that inturns boost confidence.
- To establish a trustworthy, realistic and non-flaky test/feedback execution mechanism.
- To generate well-rounded collaboration practices between the three amigos (product management, dev and QA).
- To deliver a high-quality product that eventually increases customer satisfaction and improves business results.
Shift Left Workflows
- Typical Dev/Release Process:
2. Shift Left pipeline:
Achieving Shift Left Testing Approach
- Reducing the gap between development and quality engineering. The quality validations in the isolated workflows should be planned and achieved together.
- Engaging quality functions from the beginning of requirement analysis workflows. This is how quality engineer will be able to influence design and architecture to reduce defect rate and provide acceptance criteria before the development stage.
- Timeboxing test development activities by establishing in-sprint test execution practices. Test development and product development can be taken place in parallel leveraging virtualization mechanism. Synchronization is the key.
- Establishing suitable development practice to keep testability in mind while developing code components. this way of thinking makes developers aware of issues that can break functionality or cause operational issues. When software is created with its suitability for testing in mind, Shift Left Testing becomes far more effortless.
- Specifying quality standards. The developers are not usually trained in testing from scratch. Therefore, they cannot be expected to intuitively figure out the finer points of testing. Quality engineering should outline the level of quality, performance and operational benchmarks to set the expectation properly from the developers.
How quality function can engage
- Clearly, the shift left asks for more engagement than usual from the product engineering team (including all functions). The frequency of test, communication and development reviews can get overlooked and break the cultural chain.
- Sometimes the scope of testing does not fit in the delivery cycle. The testing scope should be precise and focused. If it is too large without proper justification, there’s no room to integrate it into the build cycle to shift left.
- Maintenance of the test suite can be an overhead. It is a fundamental duty in shift left to ensure the test suites remain valuable over time. Teams need to audit and maintain their suites between builds. This ensures that the testing scope is relevant over time.
- Organizational maturity needs to reach a certain point when it can drive the cultural shift. The better path to not directly Shift Left, but Expanding Left! Sorry for another jargon!
Share your journey and thoughts in the comment.