Every business goes through a transformation, a transformation that takes place as technologies improvise on their previous update. As each improvisation on technology takes place, certain strategies become legacies and have to be replaced by the latest innovations. For example, testing strategies for many years were to release updates prior to which manual and automated processes run, right until the end of the production cycle and before the delivery process. However due to human error and leakage of bugs, defects were observed during the end user’s experience, making the hardware and software incapable of strong sales. The result of such observations started the intent to shift testing towards the development stage with several iterations and several rounds of testing.

What’s wrong with the existing Legacy Processes: The Waterfall Method

       According to a study which was conducted by SQS, 56% of defects originate during the requirement phase of the project as compared to a meagre 7% which is observed during the coding phase.

            This is a major and growing concern that businesses are struggling to realise. As such a high rate of defects passes through past the development and coding stages of the life cycle, existing and new functionalities have the possibility of getting affected due to unresolved critical and blocker issues. Observation of these defects takes place only in the latter stages after the coding phase is completed. Bug leakage is highly observed in the production and in the end-user environment.

Most companies until recently and even now are attached to the waterfall methodology for their testing process. The waterfall method had several phases – Obtaining system and software requirements, Having a complete detailed analysis, design of the program, coding and development, testing processes, and then the operational work such as monitoring and releasing – out of which the testing processes were conducted at the far end of the development cycle.

As teams try to move processes quickly towards delivery, the testing phase seems to be more like a bottleneck where the final stages are not just about testing, it’s more about the observation of defects, researching, and having a root cause analysis on each of the defects, followed by the development of new builds and retesting phase. The entire process of shift right testing causes a shift right in the delivery period.

The Beginning: When to start

The start requires a detailed analysis regarding the economics of quality assurance and quality engineering. There requires a need for a change or transformation in the methodology followed. Cost of Quality has been one of the factors behind the intent to shift left in the software development cycle. In simpler terms, the cost of poor quality, spent on resolving defects present in the production environment has always exceeded the cost of good quality spent on minimising the defects to a minimum. The analysis thus favours the need to start an early testing cycle, one that should run in parallel with the development process.

The Process: Moving Quality Assurance to Quality Engineering

The initial stage of the development cycle would have continuous planning and measurement from which details regarding the business strategy and customer feedback can be brought into the development cycle. Secondly, there should be a clear collaboration between the development, testing, decision making and business leading teams to ensure continuous delivery (CD). Continuous delivery comes into play only when continuous integration (CI) and continuous testing (CT) take place. In fact, a successful shift left testing approach is analogous with a chain reaction, where CT triggers CI which in turn triggers CD.

Once continuous testing takes place due to automation along with the development, testing is no longer a bottleneck and the delivery stage is passed through without hassles and customer feedbacks are mostly rendered positive. However continuous monitoring has to take place to achieve service levels with better visibility of customer feedback and helps in pinpointing pain points.

Benefits of having a Shift Left Approach and Investing in Quality Engineering

Any software development life cycle consists of certain mandatory processes – planning, development, testing, deploying, monitoring, releasing – which in part is framed as a DevOps principality. However the success of any software service provided is dependent on the quality of the product or technology (i.e. the number of defects observed per million observations). Small defect rates as low as 0.006 also affects sales due to COPQ. It is immensely important that there are adequate and intensive testing stages early in the development cycle so as to avoid any last minute hassles due to defect observation.

Shifting left also allows the testing team to collaborate with the stakeholders early in the development cycle. This provides for a clear understanding of the requirements of the software, so as to test the software intensively. This allows the software to ‘Fail Fast’. The defects are observed early and are fixed before the critical stages prior to delivery.

Final Resolution: A Hyper Testing Model

Testing procedures are getting highly innovative and testers are finding additional ways to test risk based functionalities which require several unique testing rounds to ensure security and efficiency. By not adopting a shift left approach – a part of hyper testing strategies – companies are risking, not enabling these novel testing methods and additional testing phases by getting re-work done on generic test cases. Hence more time is spent on re-work and less time is spent on requirement analysis of new functionalities and the testing processes concerning them. The perfect model is a hyper testing methodology where one would be able to approach shift left testing, where requirement analysis and necessary testing procedures are done, to ensure spike up in the performance levels. With such a testing methodology and focus on engineering quality, defects will be minimised and returns on cost of good quality would be maximised.

Follow Me
Latest posts by Ashish Ninan Cherian (see all)