The dark testing factory: how testing moves from manual effort to governed autonomy at scale

As AI accelerates software delivery, quality engineering needs a new operating model grounded in governed autonomy, with agents and automations scaling execution while people set the policies, risk thresholds, and outcomes.

Most quality engineering leaders have felt it this year: software output is climbing, and confidence in that output is not rising with it.

AI is reshaping how fast software gets built. Developers are completing more tasks, closing more epics, and 60% of AI-generated code is now being accepted into codebases. By several delivery metrics, software development is moving faster than traditional quality systems were designed to absorb.

A second, quieter trend is moving in the opposite direction. Bugs per developer are climbing. The ratio of incidents to pull requests has roughly tripled. Recent research found 31% more pull requests merging without review. Put plainly: organizations are creating software faster than they can confidently test it, and the gap is widening. The same study* calls this "acceleration whiplash."

Most leaders do not need convincing that delivery is accelerating. They feel it in every release meeting. What is less obvious is that the fix is not hiring more testers or writing more test scripts. Both are finite solutions to what has become a systemic problem: testing capacity that scales linearly against a delivery pipeline that no longer does.

The math is unforgiving. Every tester you add is a fixed, one-time increment of capacity—someone to hire, ramp, and retain—while AI-assisted delivery compounds. You can double the team and still fall behind, because the gap does not close; it just widens more slowly.

Quality cannot scale when the only lever is headcount. The businesses that pull ahead will scale testing without necessarily scaling testers—building quality capacity into the system itself, not just the org chart. That requires a new operating model built around governed autonomy: agents and automations taking on more of the execution, within the policies, risk thresholds, and escalation paths people define.

From point capability to operating model

Software testing has moved through recognizable stages over the last 20 years. Manual testers doing the work by hand, then automation scripting every step, with a person directing every run. Next, the era of AI-augmented tools where someone prompts and reviews but still steers. And most recently, autonomous testing, where an agent takes over a single, narrow task on its own.

Each stage moved more execution off someone’s plate. But each one is still a capability, something added to a pipeline. The next shift ahead is different in kind, not just degree: instead of a capability you run, quality becomes a self-operating system guided by human leadership.

We call it the dark testing factory, borrowed from manufacturing’s “dark factory” concept, where production keeps moving with minimal intervention on the floor. Applied to software, it describes a quality system where test generation, execution, analysis, and maintenance increasingly operate around the clock inside the delivery pipeline, without waiting for someone to kick off the next run.

What makes it an operating model, rather than simply more automation, is how those capabilities work together. Testing activity is connected across the delivery lifecycle, routine decisions are delegated within defined boundaries, and exceptions are routed to people based on policy. Every action remains traceable: what was tested, why it was tested, what the system decided, and when a person intervened.

The point is not just more automation. It is a new operating model for software quality.

When the lights turn off, humans move up, not out

It is worth being precise about what the dark testing factory is not: it is not testing without people.

Manufacturing’s dark factories still have engineers who set specs, monitor output, and intervene when something goes wrong. They have simply moved off the floor. Software’s version works the same way.

Agents and automations handle repetitive execution: discovering what changed, designing and running tests, triaging failures, healing broken scripts, and routing issues. People set the policy: what risk is acceptable, what requires human sign-off, what “done” means for a given release, and when the system should escalate.

Testers do not disappear. They move from running tests to governing the system that runs them.

For a chief information officer (CIO) or VP of Engineering, that reframes an old question. Instead of “how do we hire or automate our way to more coverage,” it becomes “who owns the risk policy this system operates under, and can we prove what it tested, why it tested it, and what happened?”

That is a governance question as much as a testing question. The winning model is not unchecked autonomy. It is governed autonomy: clear policies, auditable decisions, human escalation paths, and evidence of what was tested, why it was tested, and what the system learned.

That is the question leaders are starting to ask as AI-generated code becomes a larger share of what ships.

Where to start

You do not need the whole factory on day one. In fact, you should not expect to. A dark testing factory is built in stages.

The dark testing factory is not a product switch. It is a maturity path. Teams start by connecting existing automated tests, requirements, execution data, and escalation workflows, then progressively delegate more routine decisions to agents under policy control.

Pick one domain where your team is buried in tedious, repetitive maintenance. Maybe it is a core SAP process with brittle scripts that break every release. Maybe it is a web flow your testers rewrite by hand every sprint. Maybe it is a regression suite that takes too long to prepare, run, analyze, and repair.

Then ask three questions:

• Where does testing already run without someone driving it end to end?

• Who owns the escalation path when it does not?

• How is that decision captured, so the next cycle is smarter than the last?

Most organizations already have fragments of this in place. The work now is connecting them under one governance model instead of adding another disconnected tool.

This shift is already showing up in measurable outcomes. Organizations using UiPath Test Cloud are reducing test execution time, expanding automation coverage, and freeing teams from repetitive manual work. But the larger opportunity is to connect those capabilities under one governed system: orchestrating testing work across agents, automations, tools, and people; maintaining traceability across decisions and outcomes; and escalating work when human judgment is required.

The broader takeaway is clear: the path forward is not just testing harder. It is turning quality into a system that can scale.

Development is not going to slow down to let quality catch up. The organizations that pull ahead will not be the ones asking people to run more tests. They will be the ones that stopped treating software testing as something people run, and started treating it as a system that runs on its own, under their command.

The dark testing factory is bigger than one blog post. This is the leadership question it raises: can your quality system scale at the same speed as your development system without giving up governance, traceability, or human control?

Explore the full dark testing factory operating model and see how organizations are building toward self-operating quality systems with UiPath Test Cloud.

*Faros AI, AI Engineering Report 2026: The Acceleration Whiplash, 2026.