A cycle is a deliverable, not an activity "We tested it" is not a result. A manual test cycle should end with documents you can act on: what was covered, what failed, how badly, and whether the build is safe to ship. Here is exactly what Apex Automation Team hands over and what each part is for.
1. Before testing starts: the entry check
A cycle does not begin just because a build exists. Four things have to be true: the build is deployed to a reachable environment, test accounts and test data work, the test plan is approved, and the previous cycle's blockers are either fixed or knowingly deferred. Skipping this is how teams burn two days testing a build that was broken on arrival.
2. The test plan and coverage matrix
The plan lists the journeys in scope, the environments, the accounts and roles, the data, and what is deliberately excluded. The coverage matrix crosses flows against environments so both sides can see the shape of the cycle in one page. It is also the honest part of the report: the empty cells tell you what nobody looked at.
3. The four passes
Smoke first, to prove the build is testable. Then the scripted cases, run identically every cycle so you can compare releases. Then exploratory charters, timeboxed sessions aimed at the areas most likely to hurt. Then regression on everything fixed since last time. Each pass is recorded separately, so "142 of 150 cases passed" never hides the fact that the eight failures were all in payments.
4. What a single bug report contains
Every finding arrives with the same eight things, because a report missing any of them turns into a conversation instead of a fix.
- A title that names the broken behaviour, not the screen
- Numbered steps that reproduce it from a clean state
- Expected result and actual result, written separately
- A screen recording or annotated screenshot
- Console errors and the failing network request with its status code
- Environment: exact device, operating system, browser version, app build, account and role
- Severity, with the reason for it
- Reproducibility: always, intermittent with a rate, or once
5. How severity is assigned
Four levels, applied consistently so the list can be trusted.
- Critical: core function unusable, data lost or exposed, money charged wrongly. No workaround.
- Major: an important function broken or badly degraded. A workaround exists but is impractical.
- Minor: works but behaves wrongly in a limited way, with a reasonable workaround.
- Trivial: cosmetic or textual, no functional impact.
Severity describes impact and is ours to assign. Priority describes your schedule and stays yours. A typo on the pricing page can be trivial severity and top priority on launch week, and that combination should be easy to express.
6. The summary a non-tester can read
One page, no jargon: how many cases ran, how many passed, what the blocking issues are, which areas were not covered and why, and a clear statement of whether the build meets the exit criteria. Exit criteria are agreed up front, normally: all planned cases executed or explicitly deferred, no open critical defects, and every major defect either fixed or formally accepted.
7. The retest report
The cycle is not finished when the bugs are filed. On the next build, every fix is retested and the surrounding area is checked for damage. A ticket is only closed by the person who raised it, on a build where the fix was seen working. Fix verification rates are worth tracking: if a quarter of fixes fail retest, the problem is upstream of QA.
8. What it costs you to run one
From your side: a build, a test account, and a note on what changed. From ours: the plan, the passes, the triage, the reports and the retest. A cycle on the critical journeys of a normal web or mobile product usually reports within one to two working days, with critical findings sent the same day they are confirmed.
See software testing and QA, or how to write a bug report that gets fixed.
Quick checklist
- Approve a written test plan before testing starts
- Ask for a coverage matrix, not just a bug list
- Require steps, recording, console and network in every report
- Keep severity (impact) separate from priority (your decision)
- Get a plain summary a non-tester can read
- Have every fix retested on a fresh build
Frequently asked
Do you fix the bugs you find?
Not as part of testing. Testing tells you the state of the product. Development work is quoted separately if you want us to fix what we find.
Do you sign off our release?
No. We report what is verified, what failed and what is not covered. The release decision stays with you.
What if the build is broken on arrival?
The smoke pass catches it in the first hour and the cycle stops rather than burning two days on an untestable build. You hear about it immediately and the cycle restarts on the next build.