“Shifting Left” – Integrating Testing Earlier into the DevOps Lifecycle

Writing for DevOps.com Mike Vizard ponders this trend, commenting on a report published by PractiTest that suggests professional application testers have become more adept at working within DevOps workflows.

Surveying more than 1,000 application testing professionals they found that 80% of all application testing within organisations is being done by test engineers, test leads, testers and automation testers, with 92% of survey respondents highlighting they are working within the context of an agile methodology, while 42% cited DevOps specifically.

To the heart of this article, they also identified that more than half of respondents (59%) said testing is “shifting left” within their organisation, but only a third (33%) said programmers participate in the testing process.

This is defining the major evolution of not moving the demand of testing on to developers, but rather involving testers earlier in the cycle, to be part of the sprint process.

Interestingly, this does not decrease team sizes but rather the opposite – the number of organisations with 16 or more testers increased by 10% to 34% compared to a year ago. PractiTest believes this is because organisations are launching more complex application development projects or launching multiple projects at the same time.

Embedding Testing into DevOps

Another DevOps.com article explores the detail of this evolution. Frank Ohlhorst says ‘App Testing Must Evolve Within the DevOps Pipeline’.

He describes the importance of not treating testing as an isolated silo but rather an integral part of the DevOps workflow, and how this can present a major culture change for testing organisations, highlighting how there is often a disconnect between the cultures of QA teams and development teams, requiring improved methods of collaboration:

“Communication between developers and testers is taking on renewed importance. Using tools that can hand off statuses between teams, while also enabling different members to participate in the processes, proves to accelerate execution times.”

In particular, he states a key insight that it is not just about automation alone, but also the ability to run tests in the background – “Automation should also bring with it the ability to concurrently run multiple tests in the background, which, in turn, accelerates the testing processes.” This would address a major bottleneck that arises when attempting to better incorporate testing into DevOps:

“In many DevOps shops, QA has become a speed bump in the CI/CD pipeline, meaning that developers often have to wait for testing processes to complete before they can deploy anything. What’s more, developers are often disconnected from the status of testing.”

Unified Toolchain

Another complication to address as part of this transformation is highlighted: Currently, many vendors are focused on subsets of the testing process, such as headless browser testing, PDF validation, UI/UX testing, backend integration and so on.

This is understandable, as each area is a domain of specialism and complexity in its own right. Testing web browser UI is quite different from testing application APIs for example.

While employing ‘the right tool for the right job’ is a logical consequence this can give rise to a situation where an enterprise has a multitude of different vendors and technologies making up their testing estate, a pain point that Frank identifies and addresses.

“This can be an indicator of just how complex the QA process can become if unified tools and automation are not introduced into the process. The trick, here, is to pick a tool that does not replace peoples’ processes, but transforms manual QA processes into something that can leverage automation”.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button