This article is based on a webinar sponsored by CA Technologies and hosted by ITWC, featuring Jonathon Wright, Chief Technology Evangelist at CA Technologies, and Julie Gardiner, Director of Product Management at CA Technologies. Original coverage appeared on itworldcanada.com.
The Speed vs. Quality Tension in Modern Software Delivery
Does your software testing process slow down your ability to release new applications quickly enough to meet market demand? For a significant proportion of organisations, the honest answer is yes. Despite widespread investment in agile methodologies and rapid development practices, traditional quality assurance (QA) approaches continue to act as a bottleneck — one that can quietly undo the speed gains teams work hard to achieve.
According to Jonathon Wright, who spoke at an ITWC webinar, 94% of senior managers report increased pressure to release applications more quickly. Drivers include rising customer expectations, intensifying competitive threats, and the relentless pace of technology change. The implication is clear: the way organisations have historically approached QA is no longer fit for purpose in a world that demands continuous delivery.
Why Traditional QA Creates Bottlenecks
In a conventional software development lifecycle, testing is treated as a phase that happens after development is complete. Teams write code, hand it over to QA, wait for results, fix defects, and then release. This sequential model made reasonable sense when release cycles were measured in quarters or years. It becomes a serious liability when business strategy demands weekly or even daily deployments.
Wright noted that most large organisations still take around 18 months to respond meaningfully to marketplace changes. In an era of what he described as “massive digital disruption,” that lag is no longer acceptable. The cost is not just speed — it is relevance.
The problem is compounded by user behaviour. Research cited in the webinar suggests that 79% of users will abandon a website or application if they cannot quickly find what they need. This means poor quality is not just a technical embarrassment — it has a direct and measurable impact on customer retention and revenue.
The Real Obstacle Is Culture, Not Technology
One of the more counterintuitive insights from Wright’s presentation is that the primary barrier to better QA is not tooling or infrastructure — it is organisational culture. “It’s about getting ready for the change from a people, a mindset and a process perspective,” he said. “The practices and behaviours have to change.”
This observation aligns with broader findings in the DevOps community. Technical improvements in automation, test frameworks, and CI/CD pipelines deliver far less value when teams still think of quality as someone else’s responsibility, or when QA remains siloed from development. Changing the tools without changing the culture tends to produce only incremental gains.
Digital Assurance: A Framework for Faster, Higher-Quality Delivery
Wright proposed a modern approach to QA that he labelled digital assurance. Rather than treating testing as a discrete phase, digital assurance embeds quality thinking throughout the entire software development and delivery lifecycle. It rests on two complementary concepts: shifting left and shifting right.
Shifting Left: Test Earlier
Shifting left means introducing testing activities much earlier in the development lifecycle — ideally at the requirements stage. Rather than waiting until code is written before thinking about test cases, teams write test cases at the same time requirements are defined. This approach offers several concrete benefits:
- Defects are caught earlier, when they are cheaper and faster to fix.
- Requirements ambiguities surface before they are baked into code.
- Developers gain a clearer, testable definition of “done” from the outset.
- QA engineers become active participants in design and planning, not just validators at the end of the pipeline.
Shifting left also supports practices like test-driven development (TDD) and behaviour-driven development (BDD), where automated tests guide the writing of production code rather than following it.
Shifting Right: Incorporate Real-World Feedback
Shifting right focuses on gathering feedback from actual users in production or near-production environments. Rather than relying solely on pre-release testing conducted in controlled conditions, organisations monitor real user behaviour, collect telemetry, and run experiments such as A/B tests or canary releases to validate assumptions about features.
Understanding why a customer wants a particular feature — not just what they asked for — can make a significant difference to the quality and relevance of the result. Shifting right closes the feedback loop between delivery teams and the end users they serve.
Continuous Testing: The Engine of Digital Assurance
Underpinning both shifts is the practice of continuous testing — automated test execution integrated directly into the CI/CD pipeline. Wright was direct on this point: “If you can’t do continuous testing, you’re going to get stuck.”
Continuous testing means that every code commit triggers a suite of automated tests — unit, integration, performance, security — and results are available within minutes rather than days. Teams get fast feedback, failed builds are caught before they propagate downstream, and the overall quality of the codebase is maintained without manual gating.
Implementing continuous testing effectively requires investment in:
- Test automation frameworks that cover a meaningful proportion of the codebase.
- Service virtualisation to simulate dependencies that are unavailable or expensive to use in testing environments.
- Environment management to ensure tests run in consistent, reproducible conditions.
- CI/CD tooling that integrates test execution into every stage of the pipeline.
Real-World Results
Wright cited ING as an example of a large-scale organisation that adopted continuous release and continuous quality practices. According to the figures presented at the webinar, the bank achieved a 97% improvement in time to market for new applications and software updates — a dramatic illustration of what is possible when QA is integrated into, rather than appended to, the delivery process.
Wright also pointed to CA Technologies itself as an example of the model in practice. The company moved from one major product release per year to shipping a new release every month after applying digital assurance principles internally.
“When you build this into your process with DevOps and you change the culture, the processes and the tools, you can get incredible results,” said Julie Gardiner, Director of Product Management at CA Technologies. “You’ll wonder why you weren’t doing it ages ago.”
Key Takeaways for Engineering Teams
- QA is a shared responsibility. Quality cannot be delegated to a separate team that operates at the end of the pipeline. Every member of a delivery team owns quality.
- Shift testing left. Write test cases when requirements are defined, not after code is complete.
- Shift feedback right. Use production monitoring and real user data to validate assumptions and guide improvements.
- Automate continuously. Integrate automated tests into every CI/CD pipeline stage. Manual-only testing cannot scale to the cadence modern delivery demands.
- Address culture first. Technology investments will underdeliver unless teams adopt a quality-first mindset and break down silos between development and QA.
The gap between the speed that agile promises and the speed that traditional QA allows is a solvable problem — but solving it requires more than purchasing new tools. It requires a deliberate change in how teams think about quality and where in the lifecycle they choose to invest in it.