This article is based on a piece originally published on softwaretestingnews.co.uk, written by Scott Dainty, Head of Enterprise Sales at SeaLights, a Software Quality Intelligence Platform.
Testing Is Still in the Dark Ages
The uncomfortable truth in software delivery is that testers, test engineers, and developers spend a disproportionate amount of their working day waiting. Even teams that have adopted continuous integration, continuous testing, and continuous delivery pipelines still contend with systemic inefficiency: too much waste, too much complexity, too many bottlenecks, and too much idle time.
That waiting persists whether a team runs automated pipelines or traditional waterfall processes. Every delivery process has choke points, and the most consistent bottleneck in software delivery is testing.
Software testing became a formal discipline in the 1990s. Despite decades of advances in automation, tooling, and practitioner skills, the fundamental approach has changed surprisingly little. The application under test remains largely a black box. Testers rarely get meaningful visibility into how code is executed at runtime, so they compensate by casting the widest possible testing net — hoping to catch defects through sheer coverage breadth.
The problem with a broad net is twofold:
- The holes are often too large — defects escape.
- The net is sometimes aimed in the wrong direction — tests validate code paths that haven’t changed while genuinely risky areas go untested.
Teams compensate by growing their test suites and automating more. But automation has a ceiling. Once the cost and effort of maintaining tests outweighs the value those tests deliver, further automation becomes its own form of waste. At that point, the principle of less is more — running fewer, better-targeted tests — becomes more effective than adding more test cases.
Consider this: a large proportion of the tests run in any given iteration cover code paths that haven’t changed in that build cycle. Those test runs produce no new information. Meanwhile, genuinely risky, recently changed, or poorly covered code paths may receive inadequate attention. The result is applications that reach production carrying hidden quality risks.
How AI Can Illuminate Testing
Artificial intelligence is broadly defined as the theory and development of computer systems able to perform tasks normally requiring human intelligence, such as visual perception, speech recognition, decision-making, and translation between languages.
AI performs best when it has large volumes of data to analyse, pattern-match, and draw inferences from. Software testing generates exactly that kind of data at scale. Modern applications can comprise millions of lines of code and thousands of associated test cases. The sheer volume makes human analysis impractical — no team can manually reason about which tests to prioritise across a codebase of that size for every build.
AI and quality analytics address this by instrumenting the application under test and observing how code is actually executed. By gathering millions of data points across test interactions — tracking which lines of code each test exercises and what behaviour it validates — an AI system can:
- Identify untested or under-tested code paths (test gap analysis).
- Correlate specific code changes to the tests most likely to detect regressions in those changes.
- Produce prioritised recommendations for where to invest new test effort.
- Surface actionable quality analytics in seconds, rather than requiring manual review of coverage reports.
In short, AI shifts testing from trawling with a broad net to targeted spearfishing: fewer tests, better aimed, with a higher probability of finding real defects.
Reducing Quality Risks Through AI
Even in mature Continuous Delivery pipelines, applications typically pass through multiple test stages — unit, integration, system, and user acceptance — before reaching production. Most teams rely on static code coverage tools to understand how much of their codebase is tested. However, static coverage metrics tell you whether a line of code was touched during testing, not how well the behaviour of that code was validated across different test stages and real interaction paths.
This gap in understanding creates hidden quality risks. Test suites can show high coverage percentages while still leaving critical logic paths unverified. Defects in those unverified paths escape to production.
AI-driven quality analytics address this by tracking the detailed “footprint” each test leaves across the application at runtime. By processing those footprints at scale, an AI system can:
- Identify the highest-risk areas of the application — code that is complex, frequently changed, or poorly covered.
- Pinpoint specific test gap traps where existing tests provide the illusion of coverage without meaningful validation.
- Guide teams to allocate test investment where it will reduce the most risk, rather than where it is easiest to add tests.
Reducing Test Execution Time Through AI
In a typical regression test cycle, the vast majority of the code being tested has not changed since the previous build. Tests that re-validate unchanged code paths provide no new signal — they consume time and infrastructure without improving confidence in the release.
If AI can identify which code has changed and which tests meaningfully exercise that changed code, teams can run a precisely targeted subset of their full test suite for each build. Advocates of this approach argue that intelligent test selection could reduce test execution time and commit-to-deploy cycle time significantly, though specific figures will vary by codebase, pipeline, and tooling.
An AI-powered test selection system can factor in multiple signals when composing an optimised test run:
- Change impact: Which tests cover the code paths affected by the current code diff?
- Flakiness: Which tests have an unstable pass/fail history that warrants closer attention?
- Production usage: Which parts of the application are accessed most frequently by real users, making regressions there most damaging?
- Complexity: Which recent changes introduced significant new complexity and therefore carry higher inherent risk?
- Historical failure rates: Which tests have the highest probability of detecting defects and should therefore run first and most often?
This targeted testing model finds defects earlier in the pipeline, tightens the feedback loop between code commit and defect detection, and reduces the cognitive overhead on developers waiting for test results. Faster, more precise feedback also means testers get quicker confirmation when their work uncovers a real problem — a meaningful improvement to day-to-day job satisfaction.
Embracing AI in Your Testing Strategy
Modern applications — particularly microservices architectures — involve millions of lines of code, complex dependency graphs, and thousands of test cases accumulated over years of development. No human team can reason about that volume of information in real time for every build. That is not a criticism of testing professionals; it is simply a scaling problem that manual processes cannot solve.
As business demands push teams toward faster release cadences and shorter cycle times, AI-augmented testing offers a practical path to:
- Maintaining or increasing delivery velocity without proportionally increasing test infrastructure costs.
- Closing coverage gaps that static analysis tools miss.
- Eliminating the repetitive, low-value work that leads to tester burnout.
- Giving developers and testers faster, more actionable feedback.
AI does not replace skilled testers — it removes the drudgery and amplifies their impact by directing effort where it produces the most value. The teams that adopt intelligent quality analytics early will carry less technical debt, ship with greater confidence, and spend more time on the creative and investigative work that testing professionals find most rewarding.
Originally written by Scott Dainty, Head of Enterprise Sales at SeaLights, a Software Quality Intelligence Platform. First published on softwaretestingnews.co.uk (October 2019).