It’s Thursday afternoon. The sprint is winding down. A developer pushes the last commit, marks the ticket as “Dev Complete,” and moves on to the next item in the backlog. Somewhere across the floor — or across a Slack channel, or across a time zone — a tester picks up the build. The handoff has happened. Code has been “thrown over the wall.”
If you’ve worked in software delivery for any length of time, you’ve lived this moment. You might not even notice it anymore. It feels as natural as breathing — development happens, then testing happens, then release happens. A sequence. A pipeline. A phase.
But here’s the thing about that handoff: it’s not a neutral act. It’s a structural decision — one that carries enormous downstream consequences for delivery speed, defect cost, team culture, and ultimately, the quality of the software your users depend on. And most organisations don’t even recognise it as a decision. It’s simply “how we work.”
Except that how we work is changing. Quietly but unmistakably, the concept of testing as a bounded phase — something that happens after building and before releasing — is dissolving. Not because testing has failed, but because the world it was designed for no longer exists. The question is no longer whether this shift is happening. The question is whether your organisation has noticed.
This matters especially across Southeast Asia, where software testing has grown into a significant profession and a major employer. Malaysia, Vietnam, the Philippines, and Indonesia collectively produce an enormous volume of software — for banking, telecommunications, government services, e-commerce, and an increasingly digital public sector. The region’s testing workforce is large, credentialed, and deeply invested in frameworks and processes that were built around the phase model. Understanding what’s changing, why it’s changing, and what comes next isn’t an academic exercise. It’s a workforce question, an organisational design question, and ultimately a competitiveness question for every enterprise in the region that depends on software quality.
How We Got Here: The Historical Inheritance
The idea of a distinct “test phase” didn’t emerge from software engineering. It came from aerospace. In 1982, engineers at Hughes Aircraft developed what became known as the V-model for the FAA’s Advanced Automation System program — a framework for building flight control systems where a single undetected defect could kill people. The V-model gave testing its own side of the diagram: a mirror image of development, neat and symmetrical. Requirements on the left, validation on the right. For systems where lives were at stake and deployment happened once, this was brilliant engineering.
But then something happened. The V-model migrated from aerospace to enterprise software. Waterfall adopted it. IEEE 829, first published in 1983, standardised the test documentation that accompanied each phase — test plans, test design specifications, test incident reports, test summary reports. Testing became not just an activity but a bureaucracy, with entry criteria and exit criteria, with gates and sign-offs, with its own department and its own budget line. The test phase was institutionalised.
When agile arrived in the early 2000s, it promised to dissolve these rigid phase boundaries. And to be fair, it compressed them. But compression is not elimination. Walk into most agile teams today and you’ll find a familiar rhythm: the first few days of the sprint are “dev days” and the last few are “test days.” The sprint contains a mini-waterfall. The test phase didn’t die; it shrank and multiplied.
Even the institutions that standardised testing are starting to acknowledge this. The ISTQB’s Certified Tester Foundation Level syllabus, updated to version 4.0 in 2024, has subtly but significantly shifted its language — moving from rigid “test levels” toward “test activities,” explicitly incorporating shift-left testing, and covering DevOps and continuous delivery for the first time. When the most institutional body in the testing profession starts updating its vocabulary, it’s worth paying attention to what they’re moving away from.
As Lisa Crispin and Janet Gregory, co-authors of the seminal Agile Testing and co-founders of the Agile Testing Fellowship, have argued for years: “Testing is an activity that happens throughout. It is not a phase that happens at the end.” That sentence, written over a decade ago, reads less like a provocation today and more like a description of where the industry is heading.
The Cracks: Three Forces Breaking the Phase Model
If the test phase was designed for a world of sequential delivery, bounded applications, and human-only execution, then three forces in the current landscape are making it structurally untenable. Each one, on its own, would require adaptation. Together, they demand a fundamental rethink.
Force 1: Speed Has Outrun the Gate
The most straightforward pressure is velocity. Deployment frequency across the industry has accelerated to a point where the concept of a “phase” between code-complete and production becomes physically untenable.
According to the 2025 DORA State of DevOps Report — the gold standard for delivery performance benchmarking, now in its tenth year with Google Cloud — elite-performing teams deploy on demand, multiple times per day, with lead times measured in minutes to hours, not days or weeks. Their change failure rate sits below 15%. These aren’t anomalies; they’re the benchmark the rest of the industry is chasing.
You cannot maintain a sequential test phase when the thing you’re phasing around happens continuously. If code moves from commit to production in under an hour, there is no room for a three-day test cycle, no room for a handoff to a separate team, no room for the ceremony of entry criteria and exit criteria. The gate has to move at the speed of the pipeline, or the pipeline routes around it.
The data bears this out. Continuous testing adoption — the practice of embedding automated verification at every stage of the delivery pipeline, rather than concentrating it in a distinct phase — surged from 16% to over 50% between 2020 and 2025. Shift-left testing, the principle of moving test activities earlier in the development lifecycle, has been adopted by 67% of DevOps teams. These aren’t fringe practices anymore. They’re the emerging mainstream.
And the market recognises the shift. The global software testing services market is projected to reach USD 55.2 billion by 2026, growing at 7.5% annually — but the growth is concentrated in automation, continuous testing, and AI-driven quality engineering, not in manual test execution or phase-gate consulting.
Force 2: The Test Object Has Outgrown Its Boundaries
The second pressure is subtler but more profound. The thing you’re testing is no longer a self-contained application. It’s a node in a mesh of microservices, third-party APIs, cloud infrastructure, data pipelines, and dependencies you don’t own and may not even be aware of. The boundary of the “test object” has dissolved, and the test phase — which was designed around a bounded object — dissolves with it.
Consider what happened on July 19, 2024. CrowdStrike distributed a routine content configuration update to its Falcon Sensor security software. Within hours, approximately 8.5 million Windows systems worldwide crashed and could not restart — an event now regarded as the largest IT outage in recorded history. Airlines grounded flights. Banks froze transactions. Hospitals reverted to paper. The estimated financial damage exceeded $10 billion globally.
CrowdStrike’s own root cause analysis revealed the failure mechanism: a mismatch between the 21 input fields defined in an IPC Template Type and the 20 fields actually supplied by the sensor code, combined with a missing runtime array bounds check in the Content Interpreter. In plain language: a content update pipeline produced a file that the software wasn’t equipped to handle safely, and the validation layer didn’t catch it.
This wasn’t a bug in the application in the traditional sense. It was a quality failure in the update mechanism of a dependency. No amount of conventional application testing — unit tests, integration tests, end-to-end tests scoped to the Falcon Sensor itself — would have caught it. The failure existed in the space between systems, in the interaction between a content delivery pipeline and a content interpretation engine, in the gap between what was promised and what was delivered across a system boundary.
This is not an isolated pattern. As architectures become more distributed — 85% of enterprises plan to increase their microservices footprint in 2025 — quality failures increasingly originate outside the boundary of what any single team owns or tests. Your application might be flawless, but if it depends on a third-party API that changes its response schema, a cloud provider that modifies its networking behaviour, or a data pipeline that silently introduces nulls where there were values, your users don’t care whose fault it is. They care that it’s broken.
New practices are emerging in response. Contract testing, exemplified by tools like Pact, allows teams to validate the agreements between services in isolation — a consumer says “I expect this shape of response” and the provider verifies it can deliver, without requiring a full integration environment. Chaos engineering, pioneered by Netflix’s Simian Army in 2011 and now adopted by Amazon, Google, and Microsoft, deliberately introduces failures into production systems to test resilience — a practice that only makes sense when you accept that your “test object” includes infrastructure you don’t fully control. API observability platforms monitor the health and behaviour of service interactions in real time, catching drift before it becomes a defect.
None of these practices fit neatly into a “test phase.” They’re continuous, distributed, and often running in production. They represent a fundamental expansion of what “testing” means — from verifying a bounded artifact to monitoring the health of a living system.
Force 3: AI Is Collapsing the Build-Test Boundary
The third force is the most recent and the most disorienting. Artificial intelligence — specifically generative AI and AI-powered testing agents — is collapsing the distinction between writing tests, executing tests, and analysing results. When an AI agent can generate a test case, run it, interpret the failure, and suggest a fix, where exactly does “development” end and “testing” begin?
The adoption numbers are striking. The World Quality Report 2025–26, published by Capgemini, Sogeti, and OpenText — now in its 17th edition, surveying over 2,000 senior executives across 22 countries — found that 89% of organisations are piloting or deploying generative AI in quality engineering. Of those, 37% are already in production use and 52% are in pilot. Self-healing test scripts, which automatically adapt to UI changes without human intervention, show a 95% reduction in manual maintenance. Organisations embedding GenAI into their testing workflows report a 40% increase in test coverage.
But here’s the finding that should give every quality leader pause: the 2025 DORA report found that while AI adoption improves throughput, it increases delivery instability. Teams using AI ship faster but not necessarily more reliably. The speed gains are real; the quality gains are ambiguous. AI makes you faster. It doesn’t automatically make you better.
This is where a distinction first articulated by James Bach and Michael Bolton in 2009 becomes operationally urgent. Bach and Bolton drew a line between testing and checking. Checking is the mechanical verification of known expectations — does this output match that specification? It’s binary, repeatable, and automatable. Testing, by contrast, is the human act of critical investigation: exploring a system, modelling its risks, questioning its assumptions, evaluating whether it actually serves its purpose. Testing requires judgment, domain knowledge, curiosity, and the ability to ask “what if?”
AI is extraordinarily good at checking. It can generate hundreds of check scripts in minutes, execute them in parallel, self-heal when the UI shifts, and flag anomalies that a human might miss. But testing — the sapient, judgment-dependent process of evaluating whether a system is fit for purpose — remains irreducibly human. The question isn’t whether AI will replace testers. The question is whether testers who only do checking will have a role when AI does it faster, cheaper, and at scale.
The World Quality Report’s data underscores the tension: GenAI is now ranked as the top skill for quality engineers (63%), ahead of core quality engineering skills (60%). Yet one-third of organisations report minimal productivity gains from AI adoption, and the top challenges remain integration complexity (64%), data privacy risks (67%), and hallucination and reliability concerns (60%). The tooling is powerful; the wisdom to use it well is still catching up.
What Replaces the Phase: Quality as a Property, Not a Stage
If not a phase, then what? If the bounded, sequential, gate-based model of testing is dissolving under the pressure of speed, complexity, and AI, what emerges in its place? The answer isn’t “no testing.” It’s a reconceptualization of quality assurance as a property of the system and the team rather than a stage in the pipeline. Three characteristics define the emerging model.
Continuous verification
In the emerging model, there is no moment when testing isn’t happening. Static analysis runs in the IDE as the developer types. Unit tests execute on every save. Integration tests run in the CI pipeline on every commit. Contract tests validate service boundaries on every deployment. End-to-end tests and performance tests run in staging. And in production, synthetic monitoring, observability dashboards, feature flags, and canary deployments provide real-time quality signals. The “test phase” hasn’t been eliminated; it’s been distributed across the entire lifecycle.
In the old model, quality was the QA team’s job. Developers built; testers tested; ops deployed. In the emerging model, quality is everyone’s constraint. Developers write testable code and meaningful unit tests. Product owners define acceptance criteria that are actually verifiable. Operations engineers build observable systems with quality signals baked in. The tester’s role doesn’t disappear — it transforms. The tester becomes the quality coach, the risk strategist, the person who makes the whole team better at quality rather than the person who does quality on their behalf.
Proactive design, not reactive inspection
The old phase model was fundamentally reactive: build the thing, then check if it’s broken. The emerging model is proactive: design for quality from the start, instrument for observability, test continuously, and respond to signals in real time.
This isn’t a new idea. W. Edwards Deming said it plainly in 1986: “Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product.” Deming was talking about manufacturing, but the principle translates directly. You cannot test quality into software any more than you can inspect quality into a car. Quality has to be designed in, built in, monitored, and maintained — continuously.
There’s an instructive parallel in manufacturing that predates Deming’s writing by nearly a century. In the early 1900s, Sakichi Toyoda invented a textile loom that stopped automatically the moment a thread broke. Before this invention, each loom required a dedicated operator watching for defects — an inspector at the end of the line. Toyoda’s innovation, which became the foundational principle of jidoka (“automation with a human touch”) in the Toyota Production System, didn’t eliminate quality control. It moved quality control into the process itself. The machine stopped the moment something went wrong. The root cause was addressed immediately. Quality was built in, not inspected in after the fact.
The analogy to software is precise. The old model stationed “inspectors” (the QA team) at the end of the production line (the test phase) to catch defects after they’d been built. The emerging model builds quality signals into every stage of the process — and gives everyone the authority (and the responsibility) to “stop the line” when something is wrong.
What does this look like in practice? Consider a mid-sized fintech company in Kuala Lumpur. Their payment processing team deploys to production eight times a day. There is no “test environment” in the traditional sense — staging mirrors production, and every deployment is a canary release monitored by automated health checks. The QA engineer on the team hasn’t manually executed a test case in two years. Instead, she maintains the contract testing suite that validates 47 microservice interactions, reviews every pull request for testability, runs weekly chaos engineering experiments that simulate third-party API failures, and meets fortnightly with the risk and compliance team to ensure that regulatory testing obligations are met through automated evidence collection. She is, by any reasonable measure, doing more quality assurance work than she ever did in the phase model. But her work is woven into the fabric of delivery, not bolted onto the end of it.
This is the direction of travel. Not every organisation is there yet — far from it. But the organisations that are moving fastest, shipping most reliably, and attracting the strongest quality talent are the ones that have stopped treating testing as a phase and started treating it as a way of working.
The Uncomfortable Implication: What This Means for QA Professionals
If the test phase dissolves, what happens to the people whose careers were built around it?
This is not a hypothetical question. Across Southeast Asia, thousands of professionals carry titles like “QA Engineer,” “Test Lead,” and “Test Manager.” Many of them built their careers in organisations where the test phase was the defining structure of their work — where their value was measured in test cases executed, defects found, and test cycles completed. If that structure dissolves, their professional identity is at stake.
The regional dimension makes this especially acute. Malaysia, Vietnam, the Philippines, and Indonesia are major software development hubs, and testing has historically been a well-defined career pathway — often the entry point into IT for graduates who didn’t start in computer science. In many ASEAN enterprises, QA departments are large, structured, and deeply embedded in waterfall or hybrid delivery models. The shift from phase-based to continuous quality doesn’t just affect processes; it affects organisational charts, hiring pipelines, and the career trajectories of tens of thousands of professionals. Government-backed upskilling programmes like Malaysia’s HRD Corp have invested heavily in testing certifications — ISTQB, IREB, TMMi — that were designed around the phase model. The question isn’t whether these certifications remain valuable (they do), but whether the organisations employing certified professionals are evolving their delivery structures to match what those certifications now teach.
There is also a brain drain dimension. Senior QA professionals in the region who have already made the transition to strategic quality roles — test architects, quality coaches, DevOps-embedded quality engineers — are in fierce demand, and many are being recruited to Singapore, Australia, or remote roles for international companies. The organisations left behind are often the ones most in need of the transformation these professionals could lead. Developing homegrown quality leadership, rather than exporting it, is a regional challenge that deserves regional attention.
But dissolution is not destruction. It’s transformation. In a model where quality is a property rather than a phase, the professionals who understand risk modelling, who can think in systems, who can design test strategies that span the entire delivery lifecycle, who can coach development teams on testability, who can interpret observability data and translate it into action — those professionals become more valuable, not less. The mechanical work of test execution is being automated. The strategic work of quality thinking is in higher demand than ever.
The real tension isn’t between testers and automation. It’s between the metrics organisations use to measure quality work and the reality of what quality work has become. Many organisations still evaluate their QA teams by test case count, defect detection rate, and test cycle completion time — metrics that actively reinforce phase-gate thinking. If your team is measured by how many test cases they execute, they’re incentivised to have a test phase in which to execute them. Changing the delivery model requires changing the metrics. Changing the metrics requires changing the incentives. Changing the incentives requires changing the culture. None of this is easy. All of it is necessary.
The World Quality Report’s finding that GenAI is now ranked as the top skill for quality engineers, ahead of core quality engineering skills, should be read as both a signal and a warning. The signal: the industry values professionals who can harness new tools. The warning: if “knowing AI” outranks “knowing quality,” the profession risks optimising for tooling fluency at the expense of the deep quality thinking that gives those tools purpose.
The path forward isn’t to resist the shift. It’s to lead it. QA professionals who proactively develop skills in test strategy, risk-based approaches, observability, and AI-augmented workflows will find themselves at the centre of the emerging model, not on its periphery. Those who wait for the phase to come back will be waiting a long time.
Not a Death, a Dissolution
Go back to that Thursday afternoon. The sprint is winding down. The developer pushes the last commit.
But this time, there’s no wall to throw anything over. The commit triggers a pipeline that runs static analysis, unit tests, integration tests, and contract validations in under four minutes. A canary deployment sends the change to 2% of production traffic while observability dashboards monitor error rates, latency, and user behaviour in real time. If something goes wrong, the deployment rolls back automatically before most users notice. If everything is healthy, the change gradually rolls out to 100%.
The tester on the team didn’t execute a single test case. Instead, she spent the sprint designing the risk model for a new feature, reviewing the developer’s test coverage for gaps in edge cases, pair-testing an exploratory session with the product owner, and updating the synthetic monitoring scripts that watch the system in production. She’s busier than ever. She’s more influential than ever. And the word “phase” hasn’t crossed her mind in months.
The test phase isn’t dying because testing failed. It’s dying because testing succeeded — it proved its value so thoroughly that it could no longer be contained in a phase. Quality escaped its boundaries. And for the organisations and professionals willing to follow it, the landscape on the other side is not smaller. It’s immeasurably larger.
Author
