If you are in any way involved in software development, you have likely heard the term “Shift-left” thrown around. Shift-left is a joint effort of developers and QAs (Quality Assurance) engineers to incorporate testing as early as possible in the software development life cycle. This approach fits in with the agile methodology allowing code development and testing in small increments.
What is Shift-left?
More than a decade ago, the standard software development and QA cycle revolved around base levels. Developers wrote code for a “base level” and passed it to the QA team for testing. They would test the code and report any bugs and defects back to developers repeating this cycle as many times as necessary, often at great costs in time and resources. This approach made it very hard to give estimations, hit milestones and meet deadlines.
Shift-left leverages the fact that bugs are easier and cheaper to fix the earlier they are detected. In order to find bugs early, you need to shift testing to an early stage of the project. When defects are detected early you can take corrective steps before things get too complicated. The easiest way to explain the idea of shift-left is an attempt to introduce testing as early as possible in the SDLC. Shift-left is also a mindset that testing should be a priority in every stage of development.
Getting Started With Shift-left
As with any change in development approach and methodology, shifting left is an incremental process. It takes a lot of time, learning, organization, and participation of both tech and management teams. Depending on your current strategy, shifting left can require extensive changes to your team structure, roles, and organization. It can be a good idea to implement the shift-left approach on a small team before rolling it out in full. Regardless of scale, there are three basic steps that can get you going on the right path.
Step 1: Automate
In order to shift-left in a meaningful way, embracing automation is a must. Automation should not be limited to unit and functional tests, but also to testing the deployment of new builds. Automated builds with pre-loaded tests ensure lightning fast feedback about the quality and stability of new code. More importantly, it is a regression testing safeguard to make sure new changes did not break existing functionalities.
Although automation might seem like a lengthy process when you have to start from scratch, it will speed up the SDLC and reduce time to market in the long run. Having automated tests in place takes some of the burden off the QA team and gives them more time for exploratory, usability, and other types of tests that are not easily automated. Automation reduces the number of bugs that sneak into production, and provide a higher level of confidence in product quality.
Step 2: Implement Coding Standards
To be successful, shift-left requires your entire team to be on the same page. The first step on this journey is to agree to a shared set of coding standards. Having clear coding standards not only makes code more readable but also makes code reviews faster- and time is money. Having an overarching coding standard also ensures new team members can get acquainted with code quickly. It also reduces potential merge conflicts when several programmers are working on the same code.
There is no “one size fits all” coding standard that will work out of the box. Discuss with your team which tools would be the most relevant and effective for your codebase. There are a lot of static code analyzers on the market that highlight bad coding practices in real-time and offer fixes. If implemented correctly, this step will decrease the number of bugs and issues and decrease the amount of flaky and insecure code.
Step 3: Test Early Reduce Cost
Teams should test code as early as possible to reap the benefits of shifting left. Given that approximately 85% of all bugs occur in the coding phase, testing at the end of the SDLC surrenders the chance to fix bugs when they most often occur. Testing early requires a joint effort and a shift in mindset across the entire team. This approach aims to bridge the divide between developers and test engineers and promotes collaboration and knowledge sharing.
Continuous testing increases the confidence in the quality of the software, and gives managers and stakeholders a realistic picture of the state of the project. It also saves a lot of money. According to the 1-10-100 rule, prevention is cheaper than correction and correction is less costly than failure. This cost of failure formula states that investing 1$ in prevention saves $10 in correction and 100$ in failure
Shift-left in Real Life
So, what does shift-left daily activities look like when a team fully integrates it into every part of the project? A lot of waiting was once common for conducting tests for requirements, for new builds, and for completing development efforts before starting regression testing. This does not happen when test engineers are incorporated earlier in the development process.
When working as part of an integrated team, testers and developers share a similar cadence for more collaborative work. QA members take part in design and planning sessions with developers, even if they do not have in-depth programming knowledge. Getting familiar with the code and being part of the planning process puts testers in good stead to add quality to the project. Developers can help testers write unit and component tests and eliminate waiting around for deployments to a test environment.
A direct result of separating testing from development is often a few common misconceptions. For example, measuring the performance of a QA team solely on the number of tests they run and bugs they find. Another one is assuming that a release is imminent when there is a decrease in the number of new documented tests. These misconceptions disappear when the whole team works on making testing happen earlier.
