DevOps and Cloud Mean the End of QA as You Know It


According to Gartner, “Digital business is driving a faster pace of delivery to support the continuous delivery of incremental changes. Traditional testing cannot meet this pace nor the expanded view of quality required.”[1]
Undeniably, traditional QA must change to accelerate application delivery and become a catalyst, rather than a barrier, to digital transformation. But what is the ultimate goal of QA in the new world of DevOps and cloud speed – and what’s needed to achieve it?
Those are the burning questions that Gartner’s “It’s the End of QA as Know It (And We Feel Fine)” aims to answer. This package includes the Gartner reprint, “DevOps and Cloud Speed Are Driving the End of QA as We Know It” as well as the Tricentis report, “Reinventing Software Testing for DevOps and Modern Application Delivery.”
Here’s an overview of some of the key points and recommendations from both reports.
Recognize that traditional QA isn’t working
To highlight just a few reasons why…
Software testing remains the #1 bottleneck in the software development and delivery process. If you have a slow testing process standing between highly accelerated development and operations processes, there’s no way that you can achieve the desired delivery speed.
Software testing consumes 30-40% of an organization’s application budget.
Traditional (siloed) development/testing structures focus on optimizing the subcomponents—distracting organizations from the real goal of optimizing the broader user experience.
QA must shift from “Quality Assurance to “Quality Assistance”
With this shift, quality becomes a shared responsibility rather than the sole responsibility of one part of the team. The QA role is then expanded and elevated to assist teams with defining and achieving quality objectives.
Traditional QA is all-too-often the roadblock that stands between highly accelerated Dev processes and highly automated Ops-driven delivery processes. However, a re-envisioned QA helps the entire team collaborate to ensure that the release doesn’t place the business at risk – undermining the very “customer experience” that digital transformation is dedicated to enhancing.
Adopt a continuous approach to quality
Accelerating time-to-market without a strategic focus on quality is a quick way to drive away the very customers that you are trying to attract and retain. As Gartner notes, “Going fast isn’t jumping out of a plane without a parachute (though that may be the fastest way back to earth). Cross-functional teams must adopt key practices to integrate testing and quality into the process.”
This MUST involve Continuous Testing, which could involve “shift left” as well as “shift right.”
Continuous Testing involves executing automated tests as part of the software delivery pipeline to obtain feedback on the business risks associated with a software release as quickly as possible. It really boils down to providing the right feedback to the right stakeholder at the right time.
For decades, testing was traditionally deferred until the end of the cycle. At that point, testers would provide all sorts of important feedback…but nobody really wanted to hear it then. It was too late, and there was little the team could feasibly do, except delay the release. With Continuous Testing, the team provides actionable feedback to the appropriate people when they are truly prepared to act on it.
Continuous Testing is commonly lumped together with “shift left.” However, to deliver the right feedback to the right stakeholder at the right time, Continuous Testing needs to occur throughout the software delivery lifecycle – and even beyond that to production (e.g., monitoring information from production and feeding that back from the quality perspective). Just as the name indicates, Continuous Testing involves testing continuously. Simply starting and finishing testing earlier is not, by definition, Continuous Testing.
The path forward
How do you reach this level of continuous quality and Continuous Testing? The path forward is different for every team. Some might focus on automating traditionally manual processes while others might wrestle with orchestrating and correlating all the various test automation tools they’ve come to master. The challenge is getting to the point where you can report on whether an overarching application or project involving all these different teams – with different cadences, architectures, tool stacks, structures, and challenges – has an acceptable level of risk.
Ultimately, you should ensure that you have the people, process, and technologies required to:
Expose change impacts in minutes with advanced, resilient test automation that’s built for DevOps and cloud speed.
Modernize end-to-end testing, including testing across SAP and packaged apps as well as APIs, mobile, web, etc.
Accelerate release cycles by orchestrating and scaling testing efforts across your teams, projects, applications, and tools (including open source).
Reduce risks with centralized visibility/traceability, predictive analytics, and “release readiness” dashboards.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x