Direct answer
When asked to cut QA time to speed up a release, the right response is not to test less everywhere equally, but to prioritize edge cases by a repeatable likelihood-times-impact method and present the resulting cuts explicitly to stakeholders as a deliberate trade-off, so the decision to skip certain tests is informed and documented rather than an unstated risk nobody agreed to.
Structured elaboration
A repeatable method: score each candidate edge case on likelihood (1-5: how probable is this scenario in real usage or in this specific change) and business impact (1-5: what happens if it goes wrong), multiply for a combined score on a 1-25 scale, and rank descending. This produces a simple risk matrix with an explicit gating rule rather than a case-by-case judgment call: a combined score of 9 or above is test now, 4 through 8 is defer to a fast-follow automation effort, and below 4 is explicitly accept as untested for this release, with the bands set low enough that one high-impact factor (for example, likelihood 1 times impact 4 equals 4) can still pull a case out of the accept tier on its own.
Gating criteria to present to stakeholders: rather than a vague "we're cutting some testing," present the specific tiers and what falls into each, the raw metrics behind the scoring (why a given edge case landed where it did, not just the final tier label), and what would change the decision (if usage data later shows a "low likelihood" case happening more than expected, it gets reprioritized). This turns the cut from an unexplained risk into an explicit, defensible decision stakeholders can weigh in on and revisit.
Worked example
For a release under time pressure, five candidate edge cases might score:
| Edge case | Likelihood (1-5) | Impact (1-5) | Score | Decision |
|---|
| Payment retried after a network drop | 4 | 5 | 20 | Test now |
| Discount code applied twice via double-click | 3 | 3 | 9 | Test now (quick to verify) |
| Extremely long input in a free-text field | 2 | 2 | 4 | Defer, automate next sprint |
| Simultaneous edits by two admins to the same record | 1 | 4 | 4 | Defer, automate next sprint (impact alone flags it for follow-up despite low likelihood) |
| Unicode edge case in a display name | 1 | 1 | 1 | Explicitly accept as untested this release |
Presented to stakeholders: "we are testing the two highest-scored cases now given their combined likelihood and impact; the two mid-scored cases move to an automated regression test scheduled for next sprint rather than manual testing this week; the lowest-scored case is explicitly accepted as untested for this release, and we will revisit if it turns out to matter more than expected." This gives the product manager a specific, reasoned trade-off to approve rather than an unstated gap in coverage.
Trade-offs and pitfalls
The main risk in this kind of negotiation is caving to time pressure and cutting testing without a repeatable method behind it, which produces an ad hoc, hard-to-defend set of gaps that erode trust the first time one of them causes a production issue. The scoring method and the explicit stakeholder presentation are what convert "we tested less" into "we made a specific, informed trade-off," which is a meaningfully different and more defensible position when something does eventually go wrong in a deferred area.
