Intent-Driven Testing: Write a Sentence, Get a Complete Test Case

THE PROBLEM

Writing test cases is a translation problem. And translation is expensive.

Ask any QA engineer what the most time-consuming part of their job is. It's not running tests. It's writing them.

A 12-step test case, something that represents maybe 30 seconds of user behaviour, takes roughly 10 minutes to author manually. Not because the tester doesn't know what to test. They know exactly what to test. The friction is in the expression: converting a clear intent in your head into a precise sequence of machine-readable steps.

Every tap, every scroll, every search suggestion click has to be spelled out. And because step definitions are hand-written, they're often ambiguous or incomplete. You find out on the first run, when something breaks at step 4 that you mis-described two minutes ago. Then you fix it, rerun, patch, rerun again.

That cycle: authoring, breaking, fixing, rerunning, is where QA time actually goes.

"The tester already knows what to test. We just made everything else disappear." — Asad Abrar, Founder & CEO, Drizz

The problem compounds at scale. A QA team running dozens of tests a week spends a disproportionate amount of its time on mechanical translation work that produces no insight and catches no bugs. The authoring bottleneck is the thing limiting coverage, not capability, not tools, not people.

THE FEATURE

Fathom: from intent to deploy-ready test case in one sentence.

Fathom is Drizz's intent-driven test generation module. Instead of writing steps, you write a goal.

"Set location to HSR Bangalore, go to Instamart, search for Wheat, and add an item to cart."

That's the input. Fathom takes that sentence, understands the app's interaction patterns, and generates a complete test case: specific steps, correct sequencing, accurate element targeting, ready to run without modification.

How it works

Fathom doesn't template-match or fill in blanks. It reasons about the app. It knows that searching for "Wheat" in Instamart involves opening the search bar, waiting for suggestions, selecting from the suggestion list, and waiting for results to load, because it understands how the app behaves, not just how it looks. You don't need to know any of that. You just need to know what you want to test.

The three friction points that consumed the old 10 minutes:

Before	Now
Translation friction — converting intent into step language ~4 min	✓Write one plain-language goal. Done.
Anticipation errors — missed steps surface only on first run ~2 min	✓Model knows app patterns — steps are complete from generation.
Fix & re-run cycle — edit, rerun, patch ~3 min	✓No fix cycle. Generated steps run clean the first time.

BY THE NUMBERS

Real tests. Real results.

Two tests were run on the Swiggy application without optimisation, baseline performance only.

Test Intent	Steps	Authoring Time	Execution Time
Instamart — set HSR location, search Wheat, add item to cart	12	6 min (was ~10)	1 min 30 sec
Dineout — find restaurant with 50% off, book a table	11	~5 min (was ~10)	1 min 18 sec

Baseline run — no optimisation applied. Speed and accuracy are actively improving.

Previous manual baseline for either test: ~10 minutes to author, before a single run.

50% reduction in authoring time. Zero fix cycles. Steps that executed correctly on the first attempt.

These numbers reflect current, unoptimised performance. Speed and accuracy are both improving actively as Fathom develops further app-context awareness.

WHY IT MATTERS

The bottleneck wasn't writing tests. It was everything writing tests prevented.

Five minutes saved per test doesn't sound like much. But authoring time is a multiplier on everything else. When writing tests is slow:

Coverage decisions are time-constrained, not strategic. You test what you have time to test.
Teams run fewer tests than they should because the cost per test is too high.
Senior QA time goes to mechanical work instead of thinking about what actually needs testing.

When authoring is no longer the bottleneck, that changes. Teams can cover more flows in the same time. Coverage becomes a deliberate decision, not a function of how fast someone types.

The generated steps also tend to be more precise than hand-written ones, because Fathom knows the app's interaction patterns and doesn't miss intermediate steps that a human might skip over when writing quickly. Fewer ambiguous steps means fewer false failures downstream.

"The intent stays with the tester. Everything else is handled."

GETTING STARTED

Fathom is available now. Write your first intent-driven test today.

Fathom is live for Drizz users. Write your test intent in plain language, and Drizz handles generation and execution. No scripting. No selectors. No fix cycles.

To see it running on your own app, book a demo and we'll walk you through your first intent-driven test case.

‍