Earlier, for software development, organizations used to make use of the ‘waterfall’ model. In the waterfall model, the software development life cycle goes sequentially in the below order:
Requirements ⇒ Design ⇒ Coding ⇒ Testing
The testing phase was towards the end of the software development life cycle or if you start from left to right, the testing phase was towards the extreme right.
Since the testing was carried out at the end of the software development life cycle, it took time to find out and fix the bugs found in the software.
Apart from these, such practices were not able to handle the changing expectations and requirements which resulted in negative outcomes for the businesses or organization such as:
➢ Increased cost
➢ Increased time to market
➢ Unexpected error
PC: freepik.com
A small change in requirements led to reworking and retesting the entire application.
Thus, bugs that were found at the end of the development cycle were expensive to fix. In contrast to this, it was found that when the same bugs were found during the initial phases of development beginning from requirements and design phases - those bugs were easy to fix.
When testing is shifted left to other phases of development including - requirements, design, and coding - it is called shift-left testing.
As we saw above shift left testing, when done right, can save a lot of time and cost. Now, let’s discuss the scenarios when shift left testing should be implemented for getting results:
How to implement shift-left testing
Shift left testing can be implemented in different stages of software development in various ways. Let’s review them here before we discuss the scenarios that they can work in.
We will discuss the ways of implementing shift left testing according to the different stages of the software development life cycle.
1. Requirement phase - During the requirement phase, the business managers and product managers define the requirements that will need to be implemented.
PC: freepik.com
These requirements are also converted to acceptance criteria. The acceptance criteria can also be converted to steps that a user would do and converted to user scenarios. These user scenarios are reviewed by the testers for any glitches that could present as bugs later.
These user scenarios can also be written by the business managers and product managers as the first stage of test automation. Thus, the testing (including test automation) can be shifted left to the requirements phase of the software development life cycle.
For the implementation of automated testing - the best kind of tools that support automation during the requirements phase are the tools that let you automate without interaction with code. For eg. BDD, NLP tools.
Cucumber is the most popular BDD tool while Testsigma is a modern test automation tool that is completely codeless and also helps you implement shift left.
2. Design phase - When we incorporate the opinions of multiple people in different roles, it makes sure that we have an all-around view of things during the different phases of development.
PC: freepik.com
During the design phase, when testers are involved they can figure out any bugs in assumptions or functionalities and help reduce the cost of fixing the same bugs later.
The test cases created in the requirements phase can be reviewed at this stage to make sure that they work with the designs created.
Also, if some details were added during the design phase, the same details could be added to the user scenarios as well.
3. Coding phase - During the coding phase, real details of the feature/functionality being developed are finalized. These details can then be used to finalize the testing of the user scenarios that were created in the earlier phases.
Also, testers can also be involved in code reviews before the code is given out for full-fledged testing.
PC: freepik.com
Once the development is complete, the developed feature can be tested in the planned ways - manual as well as automated.
Now that we understand the ways that shift left testing can be incorporated in the different stages of SDLC, lets move on to the scenarios when shift-left testing actually can work and give you the ROI. Because in the end every process that we put in is for a better return-on-investment(ROI) in some form.
Scenarios when shift-left testing will work and will give ROI.
1. Your software development process is set up such that it can easily transition to shift left.
Shift left testing, definitely, guarantees benefits that every organization would want. But, the fact is that shift-left testing cannot be implemented in every situation.
Most startups, for example, would not be following a proper process of software development, which is:
Defining business requirements well before the development begins
A separate phase for design creation and approval
Coding phase after the business requirements and the designs are finalized.
There might just be requirement gathering and coding, with no time for designing. When processes are not clearly defined and the stages overlap - shift left is not a recommended practice as this would only add up to the prevalent confusion.
As a solution, the organization should focus on implementing the basic stages of software development, namely - requirement, designing, coding, and testing, and then only move on to the implementation of shift-left testing.
2. The stakeholders in your organization and software development process want to implement shift left and are convinced that it will be beneficial.
If the software development processes in an organization are in place, implementation of shift left testing is a possibility. But, implementation of shift left testing means a big change will have to be implemented from the start of the development process.
The change means that starting from requirement gathering, testing feedback will be needed. This is only possible when the stakeholders of the product are convinced that this process is needed and are ready to put in the required time and effort.
3. Your team understands that quality is the responsibility of every member of the team.
When shift left testing is implemented, every member of the team - including the business stakeholders, the designers, and the development team has to be involved in each step. Though this is the ideal scenario - some teams might still not think that way.
PC: freepik.com
If yours is one of the teams that think only the quality assurance engineers are meant to handle quality then shift left testing is not for you. Before implementing shift left you will have to ensure that every member understands the importance of being involved in quality assurance.
4. Your quality assurance team has time while the development is going on.
When implementing shift left testing - the next requirement is that your quality assurance team should have time to be involved during the development phases too.
If your software development process is such that the testing team is usually involved in the testing of previously developed features, then, they might not be ready to be involved in the process of shift left testing yet.
In this case, shift left testing can be implemented once the software development process is changed to make time for the testing team during other phases of development too.
5. Your application is such that implementing shift-left for testing is possible there.
If your application is such that it won’t support the test automation in the requirements phase and design phase or the effort required would be more as compared to - if it was done after the development - then shift left test automation might not be for you.
Now that we have discussed when can shift left testing work, do you think your team is ready for implementing shift left? If not, then, are you willing to make the necessary changes to implement the shift left? Do let me know in the comments.
Latest comments (0)