Reducing QA churn: building a more useful acceptance-testing loop

Teams lose time when tickets, implementation decisions, and QA expectations don’t line up.

A ticket moves toward testing with an outcome described in a sentence or two. QA starts exercising the feature and finds questions the ticket never answered: What should happen when a field is missing? Is this message the expected result? Does the change need to work for an existing user, too? The answers travel back to development, the implementation changes, and the ticket returns to QA. Sometimes the next round reveals another assumption that was never written down.

That back-and-forth is part of building software. When expected behavior is scattered across ticket descriptions, comments, and conversations, each handoff asks people to reconstruct the context. We’re building a more useful acceptance-testing loop that makes expectations explicit and gives everyone clearer evidence of what happened.

Start with what the ticket actually says

LightningQA is being built around a simple idea: use the acceptance criteria in a Jira issue as the starting point for a browser-based check, then return results people can inspect.

The first step is to check whether the issue describes observable behavior clearly enough to test. When an important outcome is ambiguous, the system should ask for clarification before a run. That keeps an unconfirmed assumption from becoming an automated test, and

automation can quickly verify clear expectations. The team still decides how undefined behavior should work, and the criteria gives everyone a shared contract for the check.

A small, inspectable architecture

We’ve started with a Jira App and a separate worker service, with a narrow boundary between accepting work and running a browser test.

The coordinator accepts authenticated run requests and stores them in a database with idempotency checks. Repeating a request with the same run ID and content returns the existing run; reusing that ID with different content is rejected. That gives us a durable starting point for a workflow that may eventually run asynchronously.

For criteria preflight and spec authoring, the worker uses an agent harness in a private workspace. Preflight reads the issue input and writes a structured criteria report. If the criteria need clarification, the run stops before a test encodes an unconfirmed assumption.

When the criteria are ready, a separate authoring phase can create a spec and invoke a fixed runner command. The test outcome outputs a structured report, giving the system concrete results, like video recordings and screenshots, to evaluate and show to a reviewer.

The browser runner is designed to be disposable. It runs in its own container, separate from the coordinator. The worker reads the testing URL, credentials, and callback URL from deployment configuration. The harness filters the environment passed to the model, keeping raw test credentials out of its input.

These boundaries keep responsibilities clear while the product takes shape. Security and operational work will continue as the system grows.

Evidence should help the next person

A pass or fail helps, and reviewers also need to see what the test attempted and where behavior diverged from expectations.

The test runner produces a structured report and a browser recording. We’ve also been working on making those recordings easier to follow: a caption strip at the bottom of the page shows the current criterion and action, while leaving the application itself unobscured. The goal is to connect the visible browser behavior back to the requirement being checked.

The workflow distinguishes product failures from unavailable testing server, authentication problems, and runs with insufficient evidence. It uses outcomes such as failed, blocked, inconclusive, and needs clarification to help teams choose the right next step.

Current progress and next steps

We can run the worker against our application. It exercises criteria preflight, spec authoring, browser execution, structured reporting, and video output. It gives us a place to test the core loop and learn from its rough edges before connecting every production component.

The next integration milestones are production queue dispatch and callbacks to Jira. Those will connect job intake to the typical Jira experience, where users can start a run and review its report on the issue.

We’re sharing the project as we work through the questions behind a useful browser check: when a requirement is clear enough to test, what evidence helps a reviewer, and how to keep automation from turning uncertainty into false confidence.

We’re building toward an acceptance-testing loop that helps QA and developers spend less time reconstructing intent and more time acting on clear, reviewable results. If that problem sounds familiar, join the waitlist and follow along as we connect the pieces.