A corner case rarely looks unusual piece by piece. Usually what breaks is the intersection of an ordinary state, an ordinary action, and an unaccounted-for order of events. Do not just try to "think more carefully": build the task space and systematically collide its dimensions.
First make sure that the task and scope have already been chosen. This skill strengthens the edges of a solution, but does not prove that the right solution has been chosen. If the direction is still being discussed, return to nodumb or ask-nodumb.
1. Pin down the normal contract
Write it down as one short chain:
исходное состояние → действие → видимый результат → что обязано сохраниться
The last element is mandatory. Implicit guarantees like "closed the temporary panel — returned to the previous work" fall out of the specification more often than the main result.
Do not invent the contract from the ticket alone. Check the relevant code, tests, documentation, decision history, and adjacent scenarios. Separate:
- confirmed current behavior;
- chosen new behavior;
- assumption without a source;
- question requiring a product decision.
2. Identify the dimensions of this specific task
Choose only those axes that physically participate in the change:
- state before the action;
- entry method and action variant;
- order, repetition, cancellation, and interruption;
- shape, volume, and freshness of data;
- role, permissions, and access change;
- lifecycle stage: first case, next, after time, after restart, update, migration, or access revocation;
- response time, retry, and late result;
- device, tab, process, or external integration;
- concurrent action by another participant or worker.
For each selected axis, name 2–5 distinct classes rather than listing all possible values. Note impossible combinations and the basis that excludes them.
3. Generate corners
Apply five operations to the selected axes:
- Intersection. Cross pairs of conditions. For data loss, rights, payments, synchronization, and irreversible actions, also check triples.
- Permutation. Change the order of related actions; repeat an action; insert a cancellation, rollback, restart, or continuation after a pause.
- Invariant violation. Try to lose what must be preserved: the main work, identity, selection, data, rights, or the ability to return.
- Failure cut. Place the error before the effect, during a partial effect, and after the effect but before confirmation to the user.
- Lifecycle shift. Repeat the scenario not only immediately, but for the second and subsequent object, after time has elapsed, a restart, an update, a migration, or revocation of an external right.
Do not stop at names like “network error.” Describe the full situation: what has already happened, what has not happened, what the person sees, and what will happen on retry.
Detailed mechanism and examples —
references/generation-methods.md.
4. Select what matters
Usually leave 5–10 scenarios. Raise higher the cases where:
- several ordinary conditions create an unexpected result;
- silent data loss, violation of rights, or an irreversible action is possible;
- the boundary runs between two components, devices, or points in time;
- the behavior exists in the product but is not recorded in the specification;
- the check is capable of refuting the decision, not merely confirming the implementation.
Do not add a corner just because it is theoretically possible. Name the connection to the real state, code branch, contract, past bug, or external guarantee. Discard cases that are impossible, already closed by a lower layer, or unrelated to the change.
5. Turn the finding into a solution
For each remaining corner, determine one status:
- support now — without it, the task does not fulfill its contract;
- keep as before — the new solution must not change the existing scenario;
- leave out of scope — the case is real, but its cost is not part of this task;
- need a new fact — first observation, log, human decision, or live check.
Do not offload reversible local decisions onto the user. Recommend behavior according to the existing contract; ask only where the choice changes the product, data, rights, or scope.
6. Verify, not just enumerate
If code or a live product is available, safely verify the 1–3 riskiest scenarios before implementation or include them in the verification plan. Prefer a test that can disprove the hypothesis: reproduction, state-machine test, property-based test, fault injection, or a minimal sequence of events.
Choose a signal that physically observes the broken layer: verify visual behavior in the live interface, data integrity by re-reading from storage, rights with a request using the required role, recovery with a real restart. A green check is not considered confirmation if it could not have seen the defect.
Do not pass off an invented scenario as a found defect. Mark separately: confirmed by code, reproduced, follows from the contract, or remains a hypothesis.
Result
Start with the most dangerous omission. For each corner, briefly provide:
| Situation | Expected behavior | Why it is easy to miss | Status | Verification |
|---|
At the end, state which measurements were checked, which were deliberately excluded, and which one unknown most strongly limits confidence. Do not turn the answer into a ritual checklist and do not silently expand the task.