Software projects falter, more often than not. When you slice and dice the reasons behind the failure, there could be a number of causes. Bad planning, dependencies, changing requirements and losing key people are some of the reasons.
On the top of the list, testing and validation is one of the key reasons why either a software delivery gets delayed or a delivered software gets into an abyss of problems.
During the waterfall era, testing was typically done after the development phase. Any significant bugs identified would potentially delay software delivery while it awaited redevelopment. And testing it separately as a phase introduced a good probability of recoding owing to the nature of the bugs.
As we moved towards Agile, testing was done iteratively in sprints, and it generally covered functional testing and you could say that it was merely a glamorous version of unit testing. Before going into production, a unified functional and integration testing was carried out. Any bugs identified at this stage could still potentially delay the software launch.
In order to arrest testing related delays, the remedy is shift left testing. The whole process of shift left is to move the testing cycle earlier in the software development lifecycle. Which necessarily means that we do the testing a whole lot earlier and not just before production go-live. I will talk about how we do it a little bit later.
Why is it Referred to Shift Left Testing?
Shift left testing refers to testing often and testing early in the lifecycle. So, why would it be referred to as shift left testing?
In English and in most other languages, we write and read from left to right. The term shift left refers to shifting the tests early which can be explained in this diagram.
In the waterfall method, as the name suggests, the completion of requirements phase gives rise to the design phase, the design to coding and then testing. Bugs identified during testing is passed back to coding to carry out defect fixes and redevelopment as needed. Once the testing is completed to satisfaction, the binary gets deployed into production. the verification is done after the software code is completely written. As you can see there is a whole lot of idle time for testing folks while coding is happening and vice versa when testers are at work.
This is where the change of shift left testing gets introduced. The testing cycle moves along with the coding activity. Instead of testing coming after coding, we move it earlier in the cycle and we do it often.
To reiterate, the advocation is not to carry out testing as a separate phase but as an iteration along with coding. When I say testing, I don’t refer to functional testing alone but rather the whole shebang of testing, be it regression testing, integration testing and non-functional testing as well.
Agile and Shift Left
The idea of Agile software development and shift left testing fits each other like a hand and glove. Agile advocates coding and testing to be included as a part of short development cycle called a sprint. With shift left too claiming its place alongside coding, both the Agile and Shift left are inferring to the same process.
The behavior driven development (BDD) approach takes into consideration writing acceptance test cases before writing the code and the objective of the developed code is to pass the BDD test script. This methodology helps promote shift left testing and accelerate the process of adoption.
Think about it! BDD test scripts are written in a natural language which is understood by all stakeholders including the non-technical ones like the product owners. This brings all the roles under a common umbrella which ensures that the quality of the product developed is great or somewhere close to this mark.
What’s the magic behind testing early and testing more?
Let’s say that you are building a house and you are following an architect’s plan. You lay the foundation and then the walls and the roof. As you construct the roof, you find out that the construction is not as per the architect’s plan. You have deviated so much that you have no other choice but to demolish the walls and redo the foundation. Suppose you had tested sooner, tested enough, you could have identified the flaws of the building construction during the foundation stage itself.
It is estimated that about 85% of the bugs are introduced in the coding phase. If testing is done in phases as in waterfall method, then the bugs get identified during the testing but not all of them will be fixed before going into production. Some bugs enter production and users and customers have to live with it until the future releases are designed to primarily take care of these defects.
Did you also know that it costs about ten times to find and fix a bug during system testing and even more in production than when you do it during the development stage?
Testing early and testing more has a lot of benefits. It helps you to detect the bugs early in the lifecycle, and most possibly in the lowest of environments. Rework will be minimal, as the potential changes that are to be made is minimal as you build and test in smaller batches.
Benefits of Shift Left Testing
Here are some of the benefits that we can derive out of shift left testing:
- Identify bugs early in the software delivery lifecycle
- Identifying bugs early leads to cost reduction – which is due to reduced rework
- Quality of the software or product developed is high, most of the identified bugs will not go into production and gets fixed in lower environments
- Gain customer satisfaction on the back of high quality products
- Sanctity of the codebase is maintained
The Road to Automation
Testing early and testing more requires a lot of efforts. I spoke of reduced costs owing to shift left testing. How can I test more while reducing the costs? Automation is the answer.
Unless and until we automate testing, there is absolute no chance of testing more. While we test early, we test several times daily. And this is not possible if you depend upon a human tester. You need to employ the machines to do the job.
Bring in the automation test tools. There are plenty out there in the market, open source ones or licensed ones depending on your need and application. The key is to leverage on automation that is fit for purpose and fit for use.
Once you automate testing, the next step on the ladder is continuous testing. This is a process where you further automate the testing process by constructing a pipeline to test every time you make a change to the codebase.
Many organizations fail because they try to run before they could walk. They go in for continuous testing before successfully automating their testing solution.
Shift Right Testing
While I try to declutter the shift left testing, it is to be noted that there is a shift right testing as well. If you are a betting man, you would have guessed that the waterfall testing method is called shift right testing.
Be glad that you did not place any bets on shift right testing today. It is something else altogether.
Shift right testing is the testing that is carried out in the production environment. There are certain types of scenarios or bugs that cannot be identified under test circumstances. There may not be a way to replicate the production environment, say for example an enterprise software with thousands of integrations or performance that cannot be reproduced by the performance testing tools.
It doesn’t necessarily mean that we move the untested binary to production and keep our fingers crossed that things work out alright. We use several techniques like A/B testing and canary releases to carry out testing on production.
Like for example in a canary release, we deploy software to production only to a small group of users. These end users may or may not know that they are the guinea pigs but the idea is to get the feedback from a small group before rolling it out to a larger segment. You might have seen messages indicating asking you to check out a beta site instead of a regular website. That is based on the canary model.
