How to Plan and Run a Test Run

A test run is a focused, time-boxed pass through a defined set of tickets or test cases, by named testers, against a specific build. Done well, it answers one question with confidence: is this build ready to move on? Done badly, it's a spreadsheet of ticks that nobody quite trusts.

Here's how to plan and run one properly.

Step 1: Decide what the run is for

Every run needs a purpose you can say in one sentence. "Release candidate 2.4 on staging." "Sprint 18 stories before the client demo." "Hotfix for the export bug."

Pin down three things before anyone starts clicking:

• The build and environment. Testing the wrong deployment is the most common wasted afternoon in QA.
• The scope. Which tickets are in, and, just as important, which are out.
• The exit rule. What has to be true to call the run complete? All critical tickets passing is a common bar.

Step 2: Choose tickets and testers

Pull in the tickets that changed in this build, plus the regression areas around them. If you're unsure what to include, look at what failed last time; failures cluster.

Assign testers deliberately. The developer who built a feature is the worst person to sign it off, because they test the path they intended. Spread tickets so each tester has a realistic load and someone fresh looks at the risky ones.

Need proof your work was tested? See how Flow records test runs and sign-off as evidence. Get started with Flow →

Step 3: Run it and record as you go

Results recorded "at the end" are results half-remembered. During the run, testers should:

1. Mark each ticket pass or fail as soon as it's checked.
2. Log an issue for every failure, with steps to reproduce and a screenshot or recording.
3. Note the environment and data used when anything looks odd.
4. Pause the run, rather than abandon it, if the build turns out to be broken.

If developers fix something mid-run, retest it and amend the result rather than starting over.

Step 4: Close the run properly

A run isn't done when the last ticket is ticked. Review the failures, decide which block the release, and record the outcome. If a client or auditor will ask how this build was tested, the closed run is your answer, so it should read clearly to someone who wasn't there. Our guide to test evidence covers what that record should contain.

How Flow runs a test run

TestRail is a mature, dedicated test-management tool, and Zephyr is popular with teams who want test management as an app inside Jira. Both are good options if you want large test-case repositories in a QA-specific product. Livex Flow takes a different angle: test runs sit on the same tickets your team already plans, builds and releases.

• Test-run wizard. Pick the project, the tickets and the testers in one guided flow.
• Start, pause, cancel or complete, with the time spent recorded automatically.
• Pass/fail per ticket, with amendments. Change a result after a retest and keep each ticket's failure history.
• Issues with attachments, plus auto-saved drafts so a half-written bug report survives a closed tab.
• Sealed Test Evidence Report. Produce a verifiable test-evidence document from the run, useful when you need to show how quality was checked.

If you're comparing approaches more broadly, read what test management is first.