Run the tests, capture the data, adjust daily.
Eight steps for turning a test release into a verdict on quality.
Test execution is where the risk register becomes results. These eight steps cover selection, assignment, the per-test inner loop, blocking-issue resolution, and the daily replanning that keeps a cycle on the rails.
A test cycle that is not being re-planned daily is a test cycle that is already out of date.
Key Takeaways
Four things to remember.
Select by risk, not by habit
Every cycle starts with a fresh selection decision. The suites that were right last cycle may not be right this one.
The per-test inner loop is six steps
Set up initial state, provoke a condition, observe, report product bugs, resolve test system bugs, capture the record. Run it with discipline on every test.
Status daily; replan daily
Report, adjust assignments, reconsider plans and priorities every day. Anything less frequent and the cycle drifts.
Drop in reverse-priority order
When the schedule compresses, cut from the bottom of the risk register, not from whatever tests are in front of you. Make the compression visible.
Why this exists
The problem this process fixes.
Test execution is the most visible phase of the testing process, and also the most mismanaged. Teams execute without a selection strategy, skip steps in the per-test loop, fail to surface blockers, and present status once a week instead of once a day.
These eight steps make that failure mode unavailable. Selection, assignment, the six-step per-test inner loop, and daily replanning are all made explicit — so that "we are in execution" means a specific, observable set of activities rather than a generic label.
The checklist
14 steps, in order.
- 1
Based on risk prioritization, project constraints, and any other pertinent considerations, select the test suites (from the test set) that should be run in this test cycle.
- 2
Assign the test cases in each test suite to testers for execution.
- Phase 3
Execute the test cases, report bugs, and capture information about the tests continuously, taking into account previous test results for each subsequent test.
- 3.A
Put the system under test and the test system into appropriate initial states. If this initial state is useful across multiple tests or multiple iterations of this test, save the initial states for subsequent re-use.
- 3.B
Through data inputs and other stimulus, provoke the system under test into a desired test condition.
- 3.C
Observe and evaluate the resulting outputs, behaviors, and states. Research any deviations from expected results.
- 3.D
If appropriate, report problems in the system under test.
- 3.E
If appropriate, report and/or resolve problems in the test system.
- 3.F
Capture and report information about the test just executed.
- 4
Resolve blocking issues as they arise.
- 5
Report status, adjust assignments, and reconsider plans and priorities daily.
- 6
If appropriate, eliminate unrealizable or redundant tests in reverse-priority order (drop lowest priority tests first, highest priority tests last).
- 7
Periodically report test cycle findings and status.
- 8
Check any status documents, initial states, updated testware or other test system elements, or other useful permanent records produced into the project library or configuration management system. Place the item(s) under change control.
One more thing
Most execution problems are actually discipline problems. The selection, the inner loop, the daily replanning, and the drop-in-reverse-priority rule are all cheap to do once and expensive to forget. Make them habits and the cycle pays for itself in the time you stop losing to churn.
Take it with you
Download the piece you just read.
We keep this library free. All we ask is that you tell us who you are, so we know who to follow up with if we release an updated version. One-time form, this browser remembers you after that.
Related in the library
Pair this with.
Need a QA program to back this up in your organization?
If a checklist is not enough and you want help applying it to a live engagement, we can have a call this week.
Related reading
Articles, talks, guides, and case studies tagged for the same audience.
- Whitepaper
Evaluation Before Shipping: How to Test an AI Application Before It Hits Production
The release-gate playbook for AI features. Covers the five evaluation dimensions, how to build a lean golden set, where LLM-as-judge is trustworthy and where it lies, rollout mechanics with named exit criteria, and the regression suite that keeps a shipped AI feature from quietly rotting in production.
Read → - Whitepaper
Choosing the Right Model (and Knowing When to Switch)
A practical framework for matching LLM model tier to task. Covers the four axes (capability, latency, cost, reliability), cascade routing patterns that cut cost 60 to 80 percent without measurable quality loss, switching costs you did not plan for, and the worked economics at 10K, 100K, and 1M decisions per day.
Read → - Whitepaper
Beyond ISTQB: A Multi-Domain Certification Roadmap for Technical L&D
Most engineering L&D programs over-index on a single certification family, usually ISTQB on the QA side, AWS on the infrastructure side, and under-invest across the rest of the technical domains the org actually needs. This paper covers a multi-domain certification roadmap (QA, AI, cloud, data, security, project management, software engineering) with sequencing logic for each level of the engineering ladder, plus the maintenance discipline that keeps the roadmap relevant as the technology shifts underneath it.
Read → - Guide
The ISTQB Advanced Level path, mapped
The Advanced Level landscape keeps changing — CTAL-TA v4.0 shipped May 2025, CTAL-TM is on v3.0, CTAL-TAE is on v2.0. This guide maps all four core modules, prerequisites, exam formats, sunset dates, and which module a given role should take first. Links directly to the authoritative istqb.org syllabi.
Read → - Whitepaper
Bug Triage: A Cross-Functional Framework for Deciding Which Defects to Fix
Bug triage is the cross-functional decision process that converts raw defect reports into prioritized action. Done well, it optimizes limited engineering capacity against risk; done poorly, it becomes a backlog-management ritual that neither fixes the important defects nor drops the unimportant ones. This whitepaper covers the triage process, the participants, the six action outcomes, the four decision factors, and the governance disciplines that keep triage effective in continuous-delivery environments.
Read → - Whitepaper
Building Quality In: What Engineering Organizations Do from Day One
Testing at the end builds confidence, but the most efficient quality assurance is building the system the right way from day one. This whitepaper covers the upstream disciplines — requirements clarity, lifecycle selection, per-unit programmer practices, and continuous integration — that make system-level testing cheap and fast rather than the only thing holding a release together.
Read →
Where this leads
- Service · Quality engineering
Software Quality & Security
Independent test programs, security testing, and quality engineering for systems where defects cost real money.
Learn more → - Solution
Risk Reduction & Clear Decisions
Quality programs and decision frameworks that shift risk discussions from anecdote to evidence.
Learn more → - Solution
Reliable Software at Scale
Quality engineering programs for organizations whose software is now operationally critical.
Learn more →