The dark testing factory: continuous testing, finally realized

Continuous testing didn't fail. Its promise was simply incomplete.

For more than two decades, software teams have chased the same goal: test continuously, get feedback early, and release with confidence. Every major shift in software delivery, from Agile to DevOps to CI/CD, reinforced the same idea: quality should move at the speed of software. That vision became known as continuous testing.

Yet despite years of investment in automation frameworks, CI/CD pipelines, and testing tools, something stayed incomplete. Teams automated more tests, shifted testing left, and folded quality into delivery pipelines. Quality never became truly continuous, because continuous testing was never just about running more tests, more often. The real ambition was bigger: a quality system capable of keeping pace with software delivery itself.

For years, that ambition stayed out of reach. Not because the idea was wrong, but because testing lacked coordination, autonomy, and learning, it needed to operate continuously.

Continuous testing was always the aspiration

Continuous testing changed how organizations approached software quality. Instead of treating testing as a final gate before release, teams began embedding it throughout the development lifecycle to get faster feedback and reduce risk.

Automation made that possible. Regression suites that once took days ran automatically. Pipelines executed tests after every commit. Coverage expanded, and feedback loops tightened.

But most test automation focused primarily on execution. Organizations still had to decide what to test, prepare environments and data, maintain automation as applications changed, and judge where risk mattered. That coordination works never belonged to any single tool, and as delivery accelerated, it became the real constraint. A lack of coordination, not execution, was the bottleneck.

The missing ingredient wasn't more automation

If coordination was the bottleneck, more automation was never going to fix it. What was missing was an operating model with governed autonomy at its core.

Traditional automation executes predefined instructions well. But modern software delivery increasingly produces changes, dependencies, and risks that cannot all be anticipated through predefined instructions. According to the Faros AI 2026 AI Engineering Report, which analyzed telemetry from 22,000 developers across 4,000 teams, the volume of code-related tasks developers complete is up 210 percent, while the incident-to-pull-request ratio has tripled over the same period. Development is accelerating faster than the quality systems built to keep pace with it.

That capability gap can be closed in stages, not all at once.

Automated testing executes predefined instructions. AI-augmented testing helps people interpret results, generate test assets, analyze outcomes, or make faster decisions, but a person still holds the agency. Autonomous testing goes further: an agent takes responsibility for a defined task or a bounded lane, such as executing a suite or repairing a broken selector, without waiting for a person to approve each step inside that lane.

Each stage is real progress. None of them, on its own, is the operating model for continuous testing needed. An autonomous point of capability still needs a person to decide when to invoke it, how it fits with everything else running, and what to do when it conflicts with another workflow. Autonomy inside one lane is not the same as autonomy across the system.

The dark testing factory: an emerging operating model

It doesn't replace continuous testing. It's the operating model that can finally deliver it.

A dark testing factory borrows its name from manufacturing, where a dark factory describes a production system automated enough to run with minimal human presence on the floor. Applied to software quality, it describes an emerging operating model for agentic software testing: AI agents, automation, orchestration, reusable quality knowledge, and human expertise working together across the testing lifecycle, rather than in isolated pockets.

Consider a single change entering the delivery pipeline. The quality system evaluates what changed, estimates the business and technical risk, and identifies the requirements and tests it affects. It prepares the data and environments those tests need, selects and executes the right validation, and analyzes any failures. Where an automated test can be repaired, the system will repair it. It updates its own risk model based on what happened and escalates to a person only the decisions that require judgment, not every decision.

That is what an operating model looks like in practice: continuous coordination, not continuous execution.

Governed autonomy is what makes this trustworthy rather than risky. In practice, that means human approval for high-risk decisions, role-based permissions on what agents and automations can touch, and full traceability of what ran and why. It also means policy-based thresholds that decide when something can proceed on its own, clear escalation paths, and a default to human intervention whenever context is incomplete or ambiguous. None of these are exotic. It is the same governance discipline organizations already expect from any automated system operating at scale, applied to testing.

Many of the enabling pieces already exist and are being used today: agents that help generate and refine tests from requirements and enterprise context, automation that self-heals broken selectors, and orchestration that sequences agents, automations, and people into one flow. What doesn't yet exist broadly is all of it running as one coordinated system by default. That is the frontier organizations are building toward now.

From continuous execution to continuous quality

This is how continuous testing expands into a broader model of continuous quality. Continuous testing asks: can tests be executed continuously throughout delivery? The dark testing factory asks a harder question: can the quality system continuously decide what needs to happen next?

That second question covers more ground than execution alone. It includes evaluating change as it arrives, assessing risk, prioritizing which validation matters most right now, preparing data and environments, coordinating work across agents and people, analyzing outcomes, maintaining the testing assets that would otherwise decay, and adapting future decisions based on what was learned. Traditional continuous testing has often emphasized how continuous and extensively validation is executed. Continuous quality measures whether the system made the right call about what to do next, and got better at making that call over time.

Humans become more important, not less

A system that decides, learns, and escalates on its own raises an obvious question: what is left for people to do?

More than it might seem. Testers define business intent that no specification fully captures. They supply the context a system cannot infer on its own, resolve ambiguity, set risk tolerance, and approve the exceptions that require judgment rather than pattern-matching. Every one of those interventions becomes reusable knowledge that improves how the system handles the next similar case. People teach the factory. They do not operate every part of it by hand.

That is a different job than running tests, and arguably a more valuable one.

Getting there is not one leap

No organization moves from today's automation to a fully governed operating model in a single step. In practice, it looks more like a sequence: automate the repeatable work first, then connect testing activities that used to run in isolation. Introduce AI assistance where people still hold the decisions. Delegate bounded tasks to agents inside a defined lane. Orchestrate agents, automations, and people into a shared workflow instead of parallel ones. Capture the decisions people make along the way as reusable knowledge. Only then does routine intervention start to shrink, while governance stays in place the entire time.

Continuous testing, finally realized

Continuous testing was never the wrong idea. It was an aspiration that arrived before the operating model that could deliver it. Automation solved execution. It never solved coordination, and coordination, not execution, was always the harder problem.

Continuous testing gave quality a place in the delivery pipeline. The dark testing factory gives quality the ability to operate within it.

The dark testing factory will not appear overnight. It will emerge one governed workflow, one reusable decision, and one autonomous testing loop at a time.

Dive deeper: read our white paper on the dark testing factory.