Lesson 5 of 6
Triage and progress reporting
10 min
Listen to this lesson
A UAT cycle lives or dies on its daily rhythm. Defects arrive, fixes go in, testers retest, and process owners need to know whether their area is on track. Without a daily triage, defects sit unowned and testers wait. Without clear reporting, Grace finds out on the last Friday that finance is 40 percent complete.
Hold a short triage every day of the cycle, at the same time, with the same people: the test lead (chair), a process owner or delegate per area, the functional leads, and the defect manager. Thirty minutes is enough if new defects have been pre-read. Work through them in order and leave every defect with an owner, a severity and a next action.
- Start of dayRetests firstEach tester reruns defects marked fixed, awaiting retest
- Before triagePre-read new defectsFunctional leads and the defect manager read overnight defects
- Same time daily30-minute triageEvery defect leaves with an owner, a severity and a next action
- During the dayExecute and fixTesters run scripts; fixes are transported to the test client
- End of dayReport by areaPlanned, executed, passed, blocked and open defects, with a one-line status
- Is it a defect? Some failures are tester error, script error or data. Fix the script or data and log it; do not count it as a system defect.
- Is it in scope? A request for something not in the design is a change request, not a defect. Route it to change control.
- How severe is it? Agree severity with the process owner, using published definitions.
- Who owns it and when? Assign a team and a target date for the fix and the retest.
- Is there a workaround? Record it now; you will need it in the sign-off pack.
- Can the tester reproduce it with the agreed data and role?Yes → continue · No → check script, data and training; close as not a defect if resolved
- Does the system behave differently from the agreed design?Yes → defect · No → change request to change control
- Does it stop a business-critical process with no workaround?Yes → critical, fix within the agreed window, escalate today · No → high, medium or low
- Is the fix ready for the test client?Yes → transport and hand back for retest · No → confirm target date and blocked tests
| Severity | Contoso definition | Typical response |
|---|---|---|
| Critical | A core process cannot complete and there is no workaround | Fix starts same day; escalate to PMO |
| High | A core process completes only with a costly or risky workaround | Fix before UAT exit or formally accepted with a plan |
| Medium | A secondary function fails; a reasonable workaround exists | Fix before go-live where possible |
| Low | Cosmetic or minor inconvenience | Backlog; may go live open |
Publish severity definitions before UAT so triage argues about facts, not words.
Reporting and escalation
Executives do not read defect lists. Report progress the way process owners think: by process area and, where it helps, by role. For each area show planned versus executed test cases, passed, failed and blocked, open defects by severity, and the trend since yesterday. Then add a one-line status in words: "Order to cash: on track; one high defect on invoice output, fix in test tomorrow."
| Process area | Planned | Executed | Passed | Blocked | Open critical / high | Status |
|---|---|---|---|---|---|---|
| Order to cash | 48 | 41 | 36 | 2 | 0 / 1 | On track |
| Procure to pay | 36 | 22 | 19 | 6 | 1 / 2 | At risk |
| Record to report | 30 | 12 | 11 | 0 | 0 / 0 | Behind plan |
| Plan to produce | 28 | 25 | 24 | 0 | 0 / 1 | On track |
A daily UAT dashboard at Contoso, day 6 of 10.
Read the table like a process owner. Procure to pay is at risk because six tests are blocked behind one critical defect: fixing it unlocks a quarter of the area. Record to report is behind plan but has no defects; the issue is tester availability during quarter-end, which needs a different fix. The numbers point to different actions, which is why reporting by area beats a single overall pass rate.
Escalate early, with a proposal. A good escalation to Grace names the blocker, its effect on scope and dates, what has been tried, and the decision needed: more developer capacity, a scope change, a date move or a formal risk acceptance. Agree escalation thresholds before the cycle, for example any critical defect older than one day, or any area more than 20 percent behind plan at mid-cycle.
- Is any critical defect older than one day?Yes → escalate to Grace today · No → next
- Is any area more than 20 percent behind plan at mid-cycle?Yes → escalate with the cause, such as tester availability · No → keep monitoring
- What decision is needed?More developer capacity · a scope change · a date move · a formal risk acceptance
What would you do?
Day 6: procure to pay has one critical defect. Supplier invoices for Lakeside Components post with the wrong tax code, blocking six tests. The developer estimates three days. Dan asks to mark the tests "passed with defect" so the dashboard looks better. What should Priya do?
- Run a daily triage that leaves every defect with an owner, severity and next action.
- Separate defects from script errors, data problems and change requests.
- Publish severity definitions before the cycle starts.
- Report by process area and role, with blocked tests and open defects by severity.
- Escalate early, with options, against thresholds agreed in advance.
Check your understanding · not graded
Lesson check
1. During triage, a tester reports that the system does not support a step that was never in the agreed design. How should it be routed?
2. Why report UAT progress by process area rather than one overall pass rate?
3. What makes a good escalation?
4. Why report "fixed, awaiting retest" separately?