This article is based on a summary of perspectives from Gartner and Tricentis originally published on cio.com (2019). Specific Gartner report titles and Tricentis report titles referenced in the original post are cited where relevant.
Why Traditional QA No Longer Fits Modern Software Delivery
Modern software delivery pipelines move fast. Continuous integration, continuous delivery, and cloud-native infrastructure mean that code changes can flow from a developer’s laptop to production in hours rather than weeks. Traditional quality assurance was designed for a world where releases happened quarterly or monthly — and it shows.
According to Gartner (as cited in the Tricentis report “Reinventing Software Testing for DevOps and Modern Application Delivery”), “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.”
Several specific pain points illustrate why the status quo is untenable:
- Testing is the number-one bottleneck in software development and delivery pipelines. When testing is slow and manual, it creates a hard ceiling on delivery speed no matter how fast development and operations move.
- Testing consumes 30–40% of an organisation’s application budget, according to figures cited in the Tricentis report — a significant spend that delivers diminishing returns when the process itself is misaligned with modern delivery cadences.
- Siloed QA structures optimise the wrong thing. When testing is isolated in a separate team that only engages late in the cycle, organisations end up tuning individual sub-processes rather than optimising the end-to-end user experience.
From Quality Assurance to Quality Assistance
The most important conceptual shift described in both the Gartner and Tricentis material is the move from Quality Assurance to Quality Assistance. The difference is not merely semantic.
In the traditional model, a dedicated QA team owns quality. Developers write code, throw it over the wall, and QA catches bugs before release. This model creates a structural bottleneck and diffuses accountability: developers have less incentive to write testable, high-quality code because someone else will catch the problems.
In the Quality Assistance model, quality becomes a shared, cross-functional responsibility. QA engineers shift from gatekeepers to enablers — embedding with development teams, helping define quality objectives early, building automation frameworks that developers can run themselves, and coaching the whole team on testing best practices.
The practical effect is that quality is no longer the roadblock standing between accelerated development and automated operations-driven delivery. Instead, re-envisioned QA helps the entire team collaborate to ensure that each release does not place the business or its users at risk.
Continuous Testing: More Than Just Shifting Left
“Shift left” has become a popular phrase in DevOps circles, and it captures something important: catching defects earlier in the pipeline is significantly cheaper and faster than catching them late. However, relying solely on shifting testing to earlier stages is an incomplete solution.
Continuous Testing is the more complete practice. It means executing automated tests as an integrated part of the software delivery pipeline at every stage — from the moment a developer commits code through integration, staging, release, and into production monitoring — with the explicit goal of surfacing business risk as quickly as possible.
The key principle is delivering the right feedback to the right stakeholder at the right time:
- A developer committing a change needs fast unit and integration test results — ideally within minutes.
- A release manager preparing a production deployment needs a risk assessment across the entire application.
- Operations and product teams need monitoring data from production fed back into the quality loop to inform future releases.
For decades, testing was deferred to the end of the delivery cycle. By the time testers surfaced critical findings, teams had little practical recourse beyond delaying the release — an outcome that satisfied nobody. Continuous Testing breaks this pattern by ensuring that actionable feedback reaches people when they can actually act on it.
Importantly, Continuous Testing also involves shifting right — extending quality practices beyond release into production. This includes A/B testing, canary deployments, chaos engineering, and using production telemetry (error rates, latency, user behaviour) as quality signals that feed back into the development cycle.
The Path Forward: People, Process, and Technology
There is no single transformation path. The right approach depends on your organisation’s current maturity, architecture, and tooling. Some teams need to start by automating heavily manual testing processes. Others already have extensive automation but need to orchestrate and correlate results across a fragmented landscape of tools, teams, and application components.
Regardless of starting point, reaching a state of continuous quality requires investing across four capability areas:
1. Resilient, DevOps-Ready Test Automation
Automation that was designed for waterfall-era testing tends to be brittle — it breaks frequently as the application evolves, requiring constant maintenance overhead that erodes the time savings. Modern test automation must be resilient enough to survive continuous code changes and fast enough to surface impact within minutes of a commit.
2. Modernised End-to-End Testing Coverage
Modern applications are not monoliths. They span APIs, microservices, web front-ends, mobile clients, and often include packaged enterprise applications (ERP systems, CRM platforms, and similar). End-to-end testing strategies must cover this full landscape — not just the greenfield components — to give accurate risk signals before release.
3. Orchestration Across Teams and Tools
Large organisations commonly have multiple development teams running different test automation frameworks, on different cadences, for different components of the same overall product. Accelerating release cycles at scale requires orchestrating and correlating these disparate efforts — including open-source tools — so that release readiness can be assessed holistically rather than component by component.
4. Centralised Visibility and Predictive Risk Signals
When testing is distributed across teams and tools, risk can hide in the gaps. Centralised dashboards that aggregate test results, coverage data, traceability to requirements, and predictive analytics enable release managers to make informed go/no-go decisions based on overall business risk rather than anecdotal signals from individual teams.
Key Takeaways for DevOps Teams
- Traditional QA structures are structurally incompatible with DevOps and cloud delivery speeds. Recognising this is the necessary first step.
- Quality must become a shared responsibility across development, testing, and operations — not a sequential handoff.
- Continuous Testing is not synonymous with shift-left. It means testing continuously throughout the entire delivery lifecycle, including production.
- The goal of all testing activity is to provide actionable risk information to the right people at the right time — not to produce a test report at the end of a cycle.
- Reaching continuous quality requires investment in resilient automation, broad coverage, cross-team orchestration, and centralised visibility.
As Gartner notes in the material cited by Tricentis: “Going fast isn’t jumping out of a plane without a parachute.” Accelerating delivery without a strategic quality framework does not reduce risk — it simply defers it to production, where the cost of failure is highest.