A scripted test suite is a written record of what somebody imagined while writing it. Its coverage ceiling is not the number of tests. It is the imagination of the author on the day they wrote them. Edge cases, by definition, sit outside that set: they are the states nobody pictured, so nobody encoded them. This is why a team can add two hundred tests and still ship the same class of production bug.

Key Takeaways

Scripted coverage is bounded by authoring imagination, not by test count. Writing more tests expands the set you already thought of rather than the set you did not.
Most production edge cases fall into five buckets: state, timing, data, environment, and interruption. Interruption bugs are the ones mobile suites miss most consistently.
An AI agent does not find bugs by magic. It removes the authoring cost that made exploring unlikely paths uneconomical, which is a different and more honest claim.
Agent exploration is non-deterministic by design, so anything it finds that matters should be promoted into a deterministic regression test. Exploration finds, regression guards.
Autosana runs intent-based flows on real devices, so interruption and environment cases that emulators cannot reproduce execute in the conditions that actually cause them.

Why do scripted test suites keep missing edge cases?

Every automated test begins as a sentence in somebody's head. An engineer thinks "a user logs in, adds an item, and checks out," and encodes it. The resulting suite is an accurate map of the paths that occurred to the people who built it.

The problem is structural rather than lazy. You cannot write a test for a scenario you have not conceived of, which means the uncovered region is defined precisely by what the team failed to imagine. Adding tests makes the covered region denser. It does not reliably make it wider.

This is why coverage percentage is such a misleading comfort. A suite at eighty percent line coverage has exercised eighty percent of the lines, through the paths someone chose. It says nothing about whether the untested combinations of state are the dangerous ones. An engineer on r/QualityAssurance made the point that coverage metrics reassure management far more than they reassure the people who get paged, which is the right instinct about what the number actually measures.

There is a second-order effect worth naming. Suites are usually written from the specification, and specifications describe intended behaviour. Edge cases live in unintended behaviour. So the artefact you test from is systematically biased away from the failures you most need to catch.

What actually counts as an edge case in mobile and web testing?

"Edge case" gets used loosely enough to lose meaning. In practice, production surprises cluster into five recognisable buckets, and they are worth separating because they are missed for different reasons.

Bucket	Example	Why Scripted Suites Miss It
State	Resuming a half-finished checkout after the token expired	The test always starts from a clean state
Timing	Tapping submit twice before the first response returns	The script waits politely; a real user does not
Data	A name with an apostrophe, a 400-item cart, an empty list	Fixtures are written to be convenient, not adversarial
Environment	2G, airplane mode mid-request, device storage full	CI runs on good network and a clean device
Interruption	An incoming call, a permission prompt, OS-level back during a payment	Nobody writes the test where the phone rings

Interruption is the bucket mobile teams miss most consistently, and it is also where the costliest bugs live, because an interruption during a payment flow is a money-losing state rather than a cosmetic one. A developer on r/androiddev described the familiar version of this: a flow that is bulletproof in the emulator and falls over the first time a real device does something ordinary like backgrounding the app mid-request.

Timing deserves a note too. Scripted tests are implicitly polite. They wait for the element, then act. Humans are impatient and tap twice. A suite composed entirely of patient actors will never produce a double-submit, which is why double-charge bugs reach production so reliably.

How do AI QA agents find edge cases that scripts do not?

Here is the honest mechanism, because the marketing version of this is wrong.

An AI agent does not possess insight into your product that your engineers lack. It is not reasoning about your business logic and divining where the bugs hide. What it does is change the cost of trying an unlikely path.

In a scripted world, exploring "what happens if I rotate the device during the payment confirmation" requires someone to decide the question is worth an hour, write the test, debug the test, and maintain it forever. Most teams correctly conclude that is not worth it for any individual weird scenario, and so the entire category goes unexplored. Not because it is unimportant, but because each instance is individually uneconomical.

An agent that navigates by intent can attempt that path without anyone writing it first. The marginal cost of one more exploration approaches zero, and once the marginal cost collapses, the calculation changes for the whole category at once.

That is the real claim, and it is narrower than "AI finds your bugs." A practitioner on r/Playwright framed the distinction well while discussing automation tooling generally: the value of a tool is usually in what it makes cheap rather than in what it makes possible, because most things were already possible and simply not worth the effort.

Three modes do real work in practice.

Intent-driven variation. Given "complete checkout," an agent can reach the goal through different routes across runs. A scripted test takes one path forever. Over many runs, route variation surfaces state combinations nobody enumerated.

Condition injection. Running the same intent under degraded network, low storage, or mid-flow interruption tests the environment and interruption buckets without a bespoke script per permutation.

Anomaly noticing. An agent evaluating "did the order confirm" against the actual screen can flag that the confirmation rendered with a blank total, which a scripted assertion checking only for the string "Order confirmed" would pass straight through.

Where do AI agents fail at edge-case testing?

This section matters more than the previous one, because a tool oversold is a tool distrusted by the second sprint.

Agents do not know what is important. An agent can tell you a screen rendered oddly. It cannot tell you that this particular oddity costs the company money while the one next to it is cosmetic. Severity is a product judgement and it stays with humans.

Non-determinism cuts both ways. The same property that lets an agent vary its route means a given edge case may surface on run forty and not on runs one through thirty-nine. That is acceptable for exploration and unacceptable for a merge gate. Treat agent exploration as a discovery activity, not as a pass-fail contract.

Domain-specific invalid states are invisible. An agent does not know that a policy cannot be both lapsed and in-renewal, or that a transaction over a threshold requires a second approver. Those are business rules, and if they are not expressed somewhere the agent can read, they are not testable by exploration.

Cost scales with exploration. Unbounded exploration is unbounded spend. Budget it like fuzzing: a defined window, on a defined surface, with a defined stopping condition.

A tester on r/softwaretesting captured the general failure pattern with new testing tooling, which is that teams adopt it for the demo scenario, hit the first case it genuinely cannot handle, and then discard the whole thing rather than scoping it to where it works.

How should a team combine agent exploration with scripted regression?

The two are not competitors. They answer different questions, and the workflow that actually pays off connects them.

Scripted regression answers "does the thing that worked yesterday still work." That requires determinism. You want the identical path, the identical assertion, every run, so a failure means something changed.

Agent exploration answers "is there something here nobody thought to check." That requires variation, which is the opposite property.

The loop that works:

Explore on a schedule, not on every pull request. Nightly or weekly, against a defined surface such as the checkout funnel.
Triage findings for severity, which is a human step and not a delegatable one.
Promote anything real into a deterministic regression test. This is the part teams skip and it is the part that compounds. An edge case found once and not encoded will be found again in production.
Keep the PR gate deterministic. Exploration never blocks a merge, because a non-deterministic gate trains developers to ignore it.

Step three converts a discovery activity into permanent coverage. Without it, you are paying for exploration repeatedly and banking none of it. A QA lead on r/Everything_QA described the same discipline from the manual side: exploratory sessions generate value only when findings are written up as repeatable cases, otherwise the knowledge leaves with the tester.

What should you explore first?

Rank by blast radius rather than by curiosity. The surfaces worth an exploration budget are the ones where a failure costs money or trust: payment and checkout, authentication and account recovery, anything that writes to a user's data irreversibly, and anything touching a third party you do not control.

Everything else can wait. An agent exploring your settings screen for six hours is a well-funded way to find nothing that matters.

A worked example: how one interruption becomes three bugs

Take a checkout flow that passes every test you have. A user taps "Place order," and while the request is in flight their phone rings.

A scripted suite never produces this, because the script taps and then waits for the response it expects. Nothing in it models a competing event arriving mid-request.

What actually happens on a real device is a cascade. The OS backgrounds the app, which may cancel the in-flight request depending on how the networking layer is configured. The user ends the call and returns, and the app restores to a cart screen because the activity was recreated and the in-flight state was not persisted. They tap "Place order" again. Now there are two possible outcomes, and both are bugs: either the first request completed server-side and they are charged twice, or neither completed and they believe they ordered when they did not.

Three distinct defects, one trigger. A state bug (in-flight state not persisted across recreation), a timing bug (no idempotency key on the submit), and a data bug (the client's view of order status diverging from the server's). Each would need its own scripted test, and each test would need somebody to first imagine this exact sequence.

An agent running "complete a checkout" under a condition that backgrounds the app mid-request produces the whole cascade in one run, because it is following a goal rather than a step list and will attempt recovery the way a user does. It still takes a human to look at the result and say "that is a double charge, fix it this sprint."

How do you measure whether exploration is actually paying off?

Exploration is easy to justify in theory and easy to quietly waste money on. Three numbers keep it honest.

Promotion rate is findings that became deterministic regression tests, divided by total findings. Below roughly ten percent, your exploration is generating noise rather than defects, or your triage is not happening. Both are fixable, and they have different fixes.

Escaped-incident change by bucket is the one that justifies the budget. Take the bucket you chose to explore, and measure production incidents in that bucket before and after. If interruption incidents have not moved after a quarter of exploring interruption cases, you are exploring the wrong surface or not promoting findings.

Time to triage is the quiet killer. If a finding sits in a queue for two weeks, exploration has become a backlog generator. Session replay matters here more than most people expect, because the difference between a two-minute triage and a forty-minute one determines whether the queue clears at all.

What not to measure: total findings. It rewards volume over value, and an agent can generate an unlimited number of uninteresting observations if that is the number being watched.

How does Autosana handle edge cases in practice?

Autosana is an AI-native E2E testing agent for iOS, Android, and web. Flows are expressed as intent, and the agent decides the interaction sequence at run time against whatever the UI currently shows.

That matters for edge cases in two specific ways.

Because no stored step list exists, running a flow under a varied condition does not require a new script. The same stated intent can execute on a degraded network, on a device with low storage, or after an interruption, and the agent adapts rather than failing at a hardcoded step. The environment and interruption buckets become reachable without a bespoke test per permutation.

Because execution happens on hosted real devices rather than emulators, the conditions that produce interruption bugs are the real ones. Actual OEM skin behaviour, actual permission dialogs, actual backgrounding. An emulator cannot reproduce the specific way a given vendor's battery optimiser kills a background process, which is exactly the class of bug that reaches production.

When a run surfaces something, results arrive through the GitHub integration with session replay attached, so the triage step is watching what happened rather than reconstructing it. Teams running exploration from a coding agent can drive the same flows over MCP.

The limits stated plainly. Autosana does not know your business rules unless the intent expresses them, it does not rank severity for you, and its exploration is non-deterministic, so promoting real findings into deterministic regression tests remains your step. It changes the economics of exploration. It does not remove the judgement.

Where to start

Pull your last ten production incidents and sort them into the five buckets. Most teams find one bucket holds the majority, and it is usually interruption or state. That is your exploration surface, chosen by evidence rather than by instinct.

Then run exploration against that one surface for two weeks, nightly, with a fixed budget. Triage what comes back, promote the real findings into deterministic tests, and measure the only number that matters: did the production incident rate in that bucket fall.

If it did not, the surface was wrong, not the method. Pick the next bucket and repeat.

FAQ

What is an edge case in software testing?

A condition outside the expected or common path, typically involving unusual state, timing, data, environment, or interruption. Edge cases are missed by scripted suites because a test can only cover a scenario someone conceived of while writing it.

Can AI agents really find bugs that scripted tests miss?

Yes, but not through insight. An agent lowers the cost of attempting unlikely paths to near zero, so exploration that was individually uneconomical becomes practical at scale. The mechanism is economic rather than intellectual.

Should AI agent exploration block a pull request?

No. Exploration is non-deterministic by design, so the same case may surface on one run and not the next. A non-deterministic gate trains developers to ignore it. Keep exploration scheduled and reporting, and keep the merge gate deterministic.

What is the difference between exploratory testing and agent-based testing?

Both prioritise variation over repetition. Exploratory testing is a human applying judgement in real time. Agent-based testing applies machine variation at a volume no human can match, while still requiring a human to judge which findings matter.

Which edge cases do mobile test suites miss most often?

Interruption cases: incoming calls, permission prompts, OS-level back gestures, and backgrounding mid-request. They are rarely scripted and frequently expensive, because an interruption during a payment flow produces a money-losing state rather than a cosmetic defect.

How do you stop AI exploration from costing too much?

Budget it like fuzzing. Define the surface, the time window, and a stopping condition. Rank surfaces by blast radius, which means payment, authentication, and irreversible data writes first, and everything else later or never.

Do you still need scripted regression tests if you use AI agents?

Yes. Regression requires determinism, which exploration deliberately lacks. The productive loop is exploration to discover, human triage to judge severity, then promotion of real findings into deterministic regression tests that guard against recurrence.

Can Autosana explore edge cases without a written test?

Yes. Flows are expressed as intent with no stored step list, so the same intent can run under varied conditions on real devices. Autosana does not rank severity or infer your business rules, so triage and promotion stay with your team.