Lesson 6 of 6
Reporting and sign-off
8 min
Listen to this lesson
Non-functional results are easy to misread. A report full of charts can hide that the critical process missed its target, or that the test ran on a smaller system than production. The report's job is to compare each requirement with the measured result, under stated conditions, and to tell process owners and the steering committee what that means for go-live.
Structure of the report
- Scope and environment: which tests, which system, how it compares with production, which data volumes.
- Results against requirements: one line per NFR with target, measured value, pass, at risk or fail.
- Batch window: chain duration, critical path, margin, restart result.
- Operational acceptance: restore, failover, alerting and runbook results with timings.
- Findings and tuning actions: what was found, what was fixed, what was retested.
- Residual risks and recommendation: with owners and conditions.
| Requirement | Target | Measured | Result |
|---|---|---|---|
| Sales order save, month-end load | 95% within 2.0 s at 300 users | 95% within 1.6 s | Pass |
| Billing run, month-end day | Complete by 05:00 with 25% margin | 55 min, finish 23:55 | Pass |
| MRP plants 1710 and 1720 | Complete by 05:00 with 25% margin | Finish 04:40 | At risk |
| Open AR overview | 95% within 5 s at 50 users | 95% within 7.8 s | Fail |
| Database takeover | Users back within agreed RTO | Within RTO; one interface needed manual restart | Pass with action |
Turning results into decisions
Each "at risk" or "fail" needs an owner, an action and a date: a tuning fix and rerun, a scheduling change, more capacity, or an accepted risk with a workaround. Retest after every fix with the same workload model so the comparison is fair. Where a target cannot be met before go-live, the process owner decides whether the business can live with it; Basis and the test team cannot accept business risk on the owner's behalf.
- Did a critical process fail its target under peak load?Yes → fix and retest before go-live, or the process owner formally accepts with a workaround · No → next question
- Is any batch chain without the agreed margin?Yes → tune or reschedule, then rerun the chain · No → next question
- Did restore and failover meet the recovery objectives?Yes → next question · No → no go until fixed or risk formally accepted
- Was the environment comparable to production?Yes → results stand · No → state the limits and plan a confirmation test
Plan for after go-live too. Agree with Sam which workload statistics and batch timings will be watched in the first weeks, especially the first month-end, and compare them with the test results. Production is the final performance test; the earlier ones should make it uneventful.
What would you do?
The open AR overview misses its target (7.8 s against 5 s). Kenji says a fix is possible but needs three weeks; go-live is in two. What should the report recommend?
- Report each NFR as target, measured value and result, under stated environment and volume conditions.
- Every "at risk" or "fail" needs an owner, an action, a date and a retest with the same model.
- Process owners accept residual business risk; Basis and testers inform the decision.
- Watch production statistics through the first month-end and compare with test results.
Check your understanding · not graded
Lesson check
1. What should every line of the results table contain?
2. Who accepts a missed business performance target as a residual risk?
3. Why rerun with the same workload model after a fix?