The Triage That Went Sideways

Severity describes the impact on the system's function: what breaks, how badly, is there a workaround. Priority describes when the business wants it fixed, given schedule, revenue and reputation. They are independent axes, and both defects demonstrate exactly that.

#4412 (checkout crash, Safari 14, Japan): severity high, priority high or medium-high. A crash on the checkout path is loss of a core function with no in-session workaround for the affected user. Frequency does not lower severity; it lowers exposure. The developer has collapsed the two axes and used a low session share to justify a 'minor' rating. Prioritisation should use the real number: 0.4% of sessions x monthly sessions x checkout conversion x average basket. On a site with a million monthly sessions that is 4,000 sessions, and if a tenth of those would have converted at an average order value of 60, the exposure is material. The crash also has reputational cost out of proportion to its frequency, and a browser-conditional crash often indicates a broader JavaScript or feature-detection problem worth investigating regardless of the Japan slice.

#4408 (misspelled company name in footer): severity low, priority high. No function is impaired and there is no data risk, so calling it 'critical' inflates the field that should be stable across releases. But the fix is minutes, the exposure is brand-wide, and the trigger is a dated press review. High priority, low severity is the correct classification.

Misusing severity to encode urgency destroys the usefulness of both fields: severity distributions become noise, and genuinely critical defects stop standing out.

A 'works as designed' closure is a decision about intended behaviour, so it must be resolved against an authoritative source, not against seniority or repetition.

Steps:

1. Identify the specification in force at the moment scope was frozen, by version and date. Retrieve it rather than citing it. If the developer's cited version predates the change, the closure is unfounded; if the BA's 'superseded' claim has no successor document, that claim is equally unverifiable and the dispute is really a documentation defect.
2. Reframe the question from 'is this a bug?' to 'what should the system do?' Ask the product owner to state the intended VAT rounding rule, with a worked example using a real invoice amount. This is a decision, not a debate.
3. Check the external authority. VAT rounding on invoices is regulated. Internal documents do not override tax rules, and finance or tax counsel should confirm whether rounding is per line or per invoice and at what precision. Escalate on that basis, not on tester-versus-developer.
4. Reopen against the requirement, not the person. If the intended behaviour differs from the code, the defect stands, and the missing or stale requirement is logged as a separate process defect so the same ambiguity does not recur.
5. Record and defend. Capture the decision, the deciding authority and the date in the defect record. When a resolution is agreed, add or amend the test case so the expectation is encoded next time.

Finally, flag the pattern: repeated 'works as designed' closures on one module usually signal requirements that were never testable. That is a defect in the process, and no number of triage meetings will fix it.

The SSO failure is not an inconvenience that reduces test throughput; it is simultaneously a coverage problem and a probable release risk.

Coverage problem: 140 of 480 planned cases, about 29%, cannot run. Any release decision made now rests on 71% of the intended evidence, and the missing 29% is not random - it is everything downstream of login. Marking those cases 'deferred' or quietly excluding them from the denominator would corrupt the metrics and hide the gap. Keep them as blocked, with the reason and the dependency, so the dashboard tells the truth.

Release risk: if SSO does not work in staging, the default assumption must be that it may not work in production. Authentication is a cross-cutting integration and a hard gate for every user.

Actions, in order:

1. Assign a named owner and a 24-48 hour deadline to fix the staging identity-provider configuration. Treat it as the team's top priority, because it unblocks 29% of testing as well as removing a release risk.
2. Pursue parallel workarounds now: a local stub or mock identity provider for the non-auth parts of the journey, a dedicated test tenant against the real IdP, or execution in a secondary environment. Record which cases were executed under a stub, because that is weaker evidence than end-to-end.
3. If it is not fixed within 48 hours, re-plan: re-prioritise the remaining 340 cases toward money-critical paths, and state explicitly in the go/no-go record that authentication-dependent coverage is missing and who accepts that risk.
4. If SSO cannot be verified at all before the date, that is itself grounds for a schedule decision, not a testing footnote.