As we are evolving in a more Agile world, IT teams are expected to move faster and reduce the length of time to delivery all the while trying to improve the quality of every product, without increasing costs. This means that developers and testers are both incorporated into the software development process earlier than before. This process is then known as shifting left.

Hence, we have asked experts in the industry to shed light on the importance and future of shift-left testing.

What is shift-left testing?

Shift-Left testing, as its name indicates, literally pushes testing to the left, meaning to the very beginning of the software development.

Indeed, shift left testing is about carrying out testing early in the lifecycle in order to find defects earlier and reduce the rework or repair cost of defects, according to George Ukkuru, Head of Test Engineering at UST.

Nick Kirby, Tester at Dootrix, adds that the intent of shift-left testing is to involve QA earlier in the test process by compartmentalizing the elements of the software and delivering them as independently testable elements. For instance, if a database is needed, the DB is created, the QA team can test and validate the various fields before API or the front end are available.

Fundamentally, it is the intent to get QA into the project earlier.

Shift-left testing vs traditional testing

George points out that traditional practices focused on carrying out activities such as regression testing and performance testing towards the end of the release. In many cases, release deadlines were missed, and the cost of fixing defects was high as too many defects were identified late in the life cycle. This becomes more difficult when moving to the Agile mode with 2 to 3 weeks of Sprints.

Nick also notes that a QA may want to confirm that a field can accept the name James O’Brien or Cyrillic characters, for instance. Being able to do this directly inside a test database exposes a problem with the middleware or front end. This helps QA.

An alternative approach is not to directly test individual components but to still look at the system holistically but ‘up front’ instead of at the end. With UX or accessibility testing, if the design is created before the API then QA can write automated scripts against the elements themselves, preparing well in advance.

Performance testing becomes easier if a project is compartmentalized as well. For instance, retrieving or inserting data into/from a records system could be measured directly on the DB to improve its performance before adding more weight.

Should businesses shift left?

It is essential to provide immediate feedback to the development team and fix defects in the same phase where the defect was injected, George points out. For instance, if a fault was introduced due to an ambiguity in a user story, it should be identified within the Sprint rather than finding it when you are carrying out testing with a release or hardening sprint.

The cost of fixing defects multiplies by many folds as you move from one phase to the other, and the objective should be to keep this minimal.

As a QA, Nick emphasises that it is always better when everything is nailed down in detail upfront. Otherwise, it is complicated to start working… Last-minute changes and additions are the banes of Quality assurance. Big bugs coming in as part of system testing are disastrous.

All organisations suffer from wanting to set a deadline for the release of their work. Humans are not very good at estimating the time needed to do something – what might be 5 minutes to one, could be 5 hours or days to another. We do not plan well because to some, the process is disengaging. Many of the creatives in IT want to ‘do’, not ‘plan’.

Thus, Nick continues, if the team creates the product not as an individual effort but instead as the team aiming to get a small piece of work fully complete in a given time frame the perspective changes.

Therefore, shifting left means allowing developers to detect and fix bugs early and easily. Bugs that are identified when the code is being written or reviewed are the easiest to fix, as the code units are smaller and more manageable. Implementing testing earlier and more regularly guarantees the quality of the project as well as allows your organization to save time and money.

Moving to shift left

Moving testing left is becoming more and more vital to businesses as it enables them to save time and cost but also to be more efficient. George underlines that by moving left, many activities that we carry out late in the life cycle can be done earlier, such as:

• Reviewing user stories manually or by using Natural language processing tools to minimize rework cost of software and test deliverables
• Carrying our automation of test cases within the Sprint using BDD based approaches
• Using Service Virtualization to eliminate dependencies on environments and applications to enable end to end testing early
• Focusing on running SAST and DAST scans within sprints to identify security flaws early
• Automating API Testing to validate the business logic before the UI screens are ready
• Carrying out performance testing of API’s and features to uncover design and architectural issues
• Running regression testing daily to identify issues early

Moreover, Nick notes that moving to shift-left testing involves the entire business being behind the ethos and the reasoning. In the early stages, it is going to mean less is produced as people become used to the new way of working.

Therefore, PMs are going to see themselves getting less actual output. After all, we’re testing the car body can survive a crash, is the right weight, materially and dimensionally exact before we start with the mechanicals, let alone the electronics and bodywork, etc.! Developers will need to put the brakes on as well as they won’t be able to continue until QA has completed, so they will become QA as well – acres of unit tests, performance tests, a secure, reliable pipeline, consistent results. A sprint within a sprint within a sprint cycle!

The whole business will have to accept getting less while the adaptations are made inside the product creation teams.

Benefits & Drawbacks

Shift left testing offers a number of significant benefits for businesses.

Indeed, George notes that it minimizes the rework cost of application software and test deliverables. Early feedback also provides an opportunity to take corrective actions and meet the release schedules.

Nick showcases that if the shift is done right, and the necessary changes made, businesses are able to build more consistent, reliable, and better products. He points out that it’s the difference between digging out a road to the foundations, shoring up, securing, repairing, and relaying an entirely new surface with fresh paint as opposed to patching a pothole.

Another great benefit of shift-left testing is the reduced time to market as the QA process is quicker than ever as well as the possibility to have faster development teams that have more time to build and innovate. Businesses that shift left also have the ability to use test automation tools.

However, there are still some drawbacks associated with shifting left. Some of the challenges of shift-left testing are cost, time, and resource waste (in people waiting for input), according to Nick.

Indeed, time to market would lengthen as better-quality work takes longer to produce. The more pro-active engineers who prefer to be doing will find it difficult to not begin the next section of work as it is antithetical to ‘stop and wait’ for QA, but this is a cultural issue to be addressed in the writing of more tests and pipeline improvements to prevent downtime.

There are few drawbacks, George adds, but in order to succeed, one has to plan and prioritize the activities not to get overwhelmed with many activities within a sprint. Organizations will have to invest in upskilling the employees so that they are equipped to take up additional tasks. For example, engineers working in Sprints need to be trained in performance and security testing if performance and security testing is planned within sprints.

The future of shift left testing

George believes that Shift Left testing will be a practice that will become the norm going forward. Shift Left practices will help to bring in more predictability in releases and will also help to minimize cost.

Nick also believes that shift-left testing will grow as the business seeks ever new ways to get stuff out the door faster. A new ‘approach’ to try that will miss the point. Software is shoveled out the door as fast as possible – for entirely understandable reasons, better something to market that works if it’s not great than great to market too late, after all.

However, bad products are rife because of how complicated the full exploration of a product is. It’s expensive to put quality first, especially when it’s a one-off, little-used app. Yet… he takes the example of his dishwasher that is getting on for 12 years old. Mechanically, it just keeps going. So, he imagines it is because someone, somewhere took a week longer to adjust the operation of a part to reduce friction, vibration and as a result created a better product that means he’ll buy that brand again.

The push to foist unproven, immature technology proves that everyone gets it wrong. No amount of phrasing will change the cultural shift needed to put quality – to put the customer – first.

Nick wonders if what we need is an honest re-evaluation of value to items that are reliable, consistent, well supported and, more expensive instead of the disposable, throwaway culture we have at the moment. Maybe what we need isn’t a change in the development method but in ourselves.

Special thanks to Nick Kirby and George Ukkuru for their insights on the topic!