· Alexander Vukovic

Shift Left Testing — or how testing finally arrived back where it originally came from

Why testing is moving back to the requirements and into the delivery team

Illustration of a developer team writing code

In 1979 a certain Glenford J. Meyers published a book that would revolutionise the world of software development for the long term: “The Art of Software Testing”. Up until that point, software development was simply software development. Testing was part of software development, just like punching punch cards, writing code, drawing architecture diagrams and so on. But Meyers put forward some theses that were very controversial at the time, such as:

  1. Testing is running the software with the goal of finding errors
  2. Testing can therefore only be done properly by people who are not themselves the developers
  3. Testing is therefore its own important discipline, equal in standing to software development, and it requires its own methods and experts

Interestingly, Meyers reaffirms these theses in the third edition of 2011. In the 1990s and 2000s they led to a proper development team being paired with a proper, dedicated test team. The profession of the tester developed, the collaboration between development team and test team had to be rebuilt over and over again with the help of sweets, and because there was no other way to automate, everything was automated via the user interface.

Without those turbulent times, we would not know today: “The concept did not work”!

  • Collaboration between development and test teams was always difficult
  • Either the developers no longer tested themselves at all, “the test team does that anyway”
  • Or the developers felt controlled/patronised by the “professional” testers, who as a rule had no idea about developing
  • The test team often acted as a project brake: “as long as we haven’t ‘finished’ testing this, we can’t ship”
  • Or the test team produced masses of bugs — without finding the truly critical bugs in the process

Many companies had to learn this the hard way — for example those who outsourced their testing to crowd-testing platforms and paid their testers per bug. They got a lot of bugs.

That said, it wasn’t only down to the separated test team. Software development as a whole developed in the wrong direction in the 1990s and 2000s. Everyone was propagating industrial software development modelled on car assembly lines. Model-driven software development, CASE tools, software “generators” — there were countless approaches heading in this direction. The waterfall model did the rest, and it came as it had to: countless software development projects failed. They failed on time, they failed on scope, they failed on budget, but — and this does not speak in favour of Meyers’ approach — they failed above all on quality.

The agile revolution

The world of software development could not continue like this, and more and more alternative methods and development processes saw the light of day. Extreme Programming (XP) brought many new concepts with it, such as unit tests, Test Driven Development, user stories, story points, etc. Feature Driven Development, DSDM, Kanban, Scrum — all of these methods emerged at this time out of the fact that so many projects were failing.

What came afterwards is history: the agile methods were brought together under the “Agile Manifesto” and began their triumphant advance that continues to this day.

What fell by the wayside in the process? You’ve probably guessed it: quality and testing.

A large part of the problem is the ultra-conservative and traditional view of software testing found in various certifications such as the ISTQB Certified Tester Foundation Level. For example, the process models underlying the Foundation Level, such as the “fundamental test process”, claim universal validity regardless of the development process.

The countermovement to the traditional certifications were books like “Agile Testing” or “More Agile Testing” by Janette Gregory and Lisa Crispin, or the Certified Agile Tester certification, which dominated the market in particular from 2011 onwards.

All of these developments exposed the weaknesses of Meyers’ concepts. Testing migrated back into the agile team, and our product portfolio also evolved: with our Agile Quality Coaching we help agile teams to better integrate all of quality assurance into their development lifecycle, and with our Remote Testing Services we extend our customer’s testing capacity, embedded directly in the agile process.

So what does all of this have to do with Shift Left Testing?

Shift Left Testing is the logical evolution of the agile testing concepts that have developed over the last 10 years.

A selection of the most important cornerstones of Shift Left Testing are:

  1. Make quality a cross-cutting mindset. Quality concerns every single activity in the entire software development process
  2. Use quality gates like Definition of Ready and Definition of Done in the process to fix and safeguard the level of the necessary quality
  3. Safeguard quality during requirements elicitation through better communication
  4. Safeguard quality at the level of the requirements description through reviews
  5. Ensure maintainability and readability — and thus the long-term value of the code — already in the development environment by using the appropriate tools (beautifiers, coding style guides, etc.)
  6. Safeguard quality through static code analysis already in the development environment
  7. Track technical debt, ideally with tool support
  8. Collect and monitor code quality metrics such as duplication, cyclomatic complexity or code smells
  9. Safeguard quality at the code level with unit tests
  10. Aim for the right 100% of unit test coverage
  11. Use every opportunity to test without the UI, e.g. through Consumer Driven Contract Tests or API tests
  12. Avoid automated UI tests as far as possible and use them only for the most important end-to-end regression tests
  13. Run all further regressive quality assurance steps automatically via the Continuous Integration/Delivery/Deployment pipeline
  14. Concentrate manual testing activities on the creative and important tests
  15. Use Session Based Testing and timeboxing as early as possible in the process
  16. Apply the principles of software development to test artefacts as well (versioning, no redundancies, modularisation, class over mass, and so on)
  17. Document all testing activities automatically through test evidence
  18. Use test methods such as boundary value analysis, equivalence classes or pairwise test case reduction at all levels (which requires everyone in the team to know these techniques)
  19. Report the quality status automatically in real time
  20. Make all testing activities transparent and viewable by the customer too

The selection shows that Shift Left Testing brings testing back to where it once was: to the requirements and into the delivery team. Testing is always and everywhere, and team members should be able to slip into the testing role at any time, just as into that of a programmer, an architect or a requirements engineer. AI will be able to make every single one of the points listed above easier and support them in the future.

Conclusion: everything becomes technical

Shift Left Testing reflects a trend that has intensified more and more in recent years and has now received another big boost from AI: testing is becoming ever more technical, and being a good tester without development skills is only possible in the very limited setting of acceptance testing, for example for the customer’s business department. Working in an agile team in any case requires the corresponding technical skills in order to be able to walk the path of the Shift Left. This of course has decisive consequences for the profession of the software tester. The outdated form that Meyers, for example, propagated will have no relevance whatsoever in the medium term.

Then what should never have been separated is reunited. But one great advantage of the temporary separation of development and test is that testing nonetheless developed strongly as a result, and the new shared whole of “Shift Left” is thus considerably stronger than software development in 1979 could ever have been.

Sources and further information

Originally published at SEQIS Blog