Case studies / QA flow

Achieving 12x faster test authoring with AI QA agents

Dark-themed QA flow user interface on a computer screen showing a dashboard for e-commerce tracking, with test scenarios, pass/fail statuses, and user assignments.

5 min

A full QA suite written, against an hour by hand

22 hrs

Back on a QA engineer's calendar every week

~$64k

Capacity returned per engineer, per year

TL;DR

Writing, running and reporting tests took close to an hour per ticket before a single test was executed.

QA flow is an AI QA agent that reads any spec, writes the test cases, runs them unattended and files the bugs it finds.

Authoring dropped from about an hour to five minutes, returning about 22 hours a week per engineer.

Every ticket starts with a specification and someone reading it: a user story, a design frame, a pull request. On anything non-trivial that is close to an hour of work before a single test runs, and several people digest the same document separately and reach slightly different answers.

QA flow does that first pass. It reads whatever spec exists, writes the cases a QA engineer would write, runs them unattended and files what breaks. Five minutes instead of an hour, with one engineer reviewing a complete draft rather than a blank page.

The challenges

Every ticket runs the same loop before anything gets tested. It is careful, necessary work, and it takes most of the week.

Authoring from a blank page
Read the story, work out what the change touches, think through edge cases, write the cases out. Close to an hour before anything runs.

Execution with someone present throughout
Open the case, read step one, go do it, come back, read step two. Roughly eight minutes per test case, with attention on it the whole time.

Writing the failure up a second time
Anything that fails becomes a bug report, a second pass over work already done once.

The judgment goes last
Edge cases and impact analysis are what a QA engineer is for, and they get squeezed because authoring and execution fill the day first.

What we built

Three things stay with the engineer: approving the suite, adding the edge cases only they would think of, and fixing the bug. Everything else runs without anyone watching. It was built in-house by a four-person pod working full time for six months across the front end, the back end and the agent itself.

User interface with a purple background showing a task selection panel titled 'Select user stories' where 'User stories' is checked, 'Pull requests' and 'Design frames' unchecked. The panel allows filtering tickets by source 'Linear' and team 'Lululemon'. A search bar is present with a list of tickets below, including selected tickets 'Flow-821 Onboarding flow' and 'Flow-234 Refactor data layer', and an unselected ticket 'Flow-934 Integrate analytics dashboard'.

1. Writes the tests from whatever spec exists

A Jira ticket, a Linear story, a screenshot or the repository itself, with nothing cleaned up first. The test type is a choice too: the blend a QA engineer would assemble, or one named type from end to end and integration down to unit, smoke and accessibility..
A test summary interface showing 4 passes, 1 fail, 3 attention, and 0 skipped. Test details include: 1.0.1 User can enter a valid email address - Fail due to changed email input field locator; 1.0.2 User can enter a valid password - Pass; 1.0.3 User can toggle password visibility - Pass; 1.0.4 User can click the 'Continue' button to attempt sign-in - Pass; 1.0.5 User must receive an error message for invalid email format.

2. Runs them without anyone watching

A run finishes in about three minutes against roughly eight per test case by hand. Failures become tickets on their own, formatted so a developer can act without a follow-up question. One step stayed manual: a case that signs in as a particular user needs those steps edited first, because the run uses one set of credentials.
Test report interface titled 'Scenario 1.0.3' by Lana Doe, updated 2 days ago, verifying if user can toggle password visibility; status marked as Failed with options to run tests and share, displaying test steps including navigating to sign-in page and entering password.

3. Shows what failed, and what fails most

A dashboard shows how many cases exist, how many failed and which types failed most, so UI breakage reads differently from unit breakage at a glance. Each failure opens onto the scenario, its status and the steps that ran up to where it stopped.

4. Getting the agent accurate took longer than building it

Early output passed cases that should have failed and failed cases where nothing was wrong. False positives and false negatives went into a shared spreadsheet, run by run, and the model was tuned against that record until the rate came down, then moved to a newer version. That accounting is where most of the six months went.
“Authoring used to take an hour a ticket. Now that hour goes to the edge cases nobody had time to test.”
Disha Rana

Engineering, Islands

Conclusion

Authoring drops from about an hour per feature to five minutes. Execution drops from roughly eight minutes per test case with an engineer watching to a three-minute run that needs nobody, and the separate write-up disappears. What comes back is about twenty-two hours a week per engineer.

Want this pipeline running on your backlog? Get in touch.

5 min

A full QA suite written, against an hour by hand

22 hrs

Back on a QA engineer's calendar every week

~$64k

Capacity returned per engineer, per year

Spec sources: Jira, Linear, GitHub repositories, screenshots
Test types: end-to-end, integration, unit, smoke, accessibility
Agent: fine-tuned model, false positive and negative rates tracked run by run across six months
Output: generated test cases, unattended execution, automatic bug tickets, results dashboard
Build: four-person pod, full time, six months across front end, back end and agent

FAQ

How does an AI QA agent write test cases from a spec?

QA flow reads a Jira ticket, Linear story, screenshot or repository and writes the cases a QA engineer would write, as a blend or a named type: end to end, integration, unit, smoke or accessibility.

How much faster is AI test authoring?

About five minutes for a full suite against an hour by hand, and runs of about three minutes against roughly eight minutes per test case manually.

How do you make an AI testing agent accurate?

Track false positives and false negatives run by run, tune the model against that record, and upgrade the model as the rate comes down. See stop building AI agents that work in demos.

Can AI replace a QA engineer?

No. The engineer keeps approving the suite, adding the edge cases only they would think of, and fixing the bug. Learn more about our QA service.

About QA flow
QA flow reads a user story, writes the test cases a QA engineer would write, runs them, and files the bugs it finds. It was built in-house over six months by a full-time pod.
qaflow.com ↗
Tags
Product & engineering
Tech stack
Jira
GitHub
Linear
Want similar results?
We build AI agents and software for teams ready to move faster.
Get in touch
contact image