edge-hunt

Edge Hunt

Корнер редко выглядит необычно по частям. Обычно ломается пересечение обычного состояния, обычного действия и неучтённого порядка событий. Не пытаться просто «подумать внимательнее»: построить пространство задачи и системно столкнуть его измерения.

Сначала убедиться, что задача и масштаб уже выбраны. Этот скилл укрепляет края решения, но не доказывает, что выбрано правильное решение. Если направление ещё обсуждается, вернуться к nodumb или ask-nodumb.

1. Зафиксировать нормальный контракт

Одной короткой цепочкой записать:

исходное состояние → действие → видимый результат → что обязано сохраниться

Последний элемент обязателен. Неявные гарантии вроде «закрыл временную панель — вернулся к прежней работе» чаще выпадают из постановки, чем основной результат.

Не изобретать контракт только по тикету. Проверить релевантные код, тесты, документацию, историю решений и соседние сценарии. Разделить:

• подтверждённое текущее поведение;
• выбранное новое поведение;
• предположение без источника;
• вопрос, требующий продуктового решения.

2. Выделить измерения именно этой задачи

Выбрать только те оси, которые физически участвуют в изменении:

• состояние до действия;
• способ входа и вариант действия;
• порядок, повтор, отмена и прерывание;
• форма, объём и свежесть данных;
• роль, права и смена доступа;
• этап жизненного цикла: первый случай, следующий, спустя время, после restart, update, миграции или отзыва доступа;
• время ответа, retry и поздний результат;
• устройство, вкладка, процесс или внешняя интеграция;
• параллельное действие другого участника или воркера.

Для каждой выбранной оси назвать 2–5 различающихся классов, а не перечислять все возможные значения. Отметить невозможные сочетания и основание, которое их исключает.

3. Породить корнеры

Применить к выбранным осям пять операций:

1. Пересечение. Скрестить пары условий. Для потери данных, прав, платежей, синхронизации и необратимых действий проверить также тройки.
2. Перестановка. Поменять порядок связанных действий; повторить действие; вставить отмену, возврат, перезапуск или продолжение после паузы.
3. Нарушение инварианта. Попытаться потерять то, что должно сохраняться: основную работу, идентичность, выбор, данные, права или возможность вернуться.
4. Разрез сбоя. Поместить ошибку до эффекта, во время частичного эффекта и после эффекта, но до подтверждения пользователю.
5. Сдвиг по жизненному циклу. Повторить сценарий не только сразу, но для второго и последующего объекта, после истечения времени, перезапуска, обновления, миграции или отзыва внешнего права.

Не останавливаться на названиях вроде «ошибка сети». Описывать полную ситуацию: что уже произошло, что не произошло, что видит человек и что случится при повторе.

Подробный механизм и примеры — references/generation-methods.md.

4. Отобрать важное

Оставить обычно 5–10 сценариев. Поднимать выше случаи, где:

• несколько обычных условий создают неожиданный результат;
• возможны тихая потеря данных, нарушение прав или необратимое действие;
• граница проходит между двумя компонентами, устройствами или моментами времени;
• поведение существует в продукте, но не записано в постановке;
• проверка способна опровергнуть решение, а не только подтвердить реализацию.

Не добавлять корнер только потому, что он теоретически возможен. Назвать связь с реальным состоянием, веткой кода, контрактом, прошлым багом или внешней гарантией. Невозможные, уже закрытые нижним слоем и не относящиеся к изменению случаи отбросить.

5. 見つかった問題を対応方針に変える

残ったコーナーケースごとに、次のいずれかのステータスを付けます。

• 今すぐ対応する — 対応しなければ、タスクの契約を満たせません。
• 従来の動作を維持する — 新しい対応によって既存のシナリオを変えてはいけません。
• 対象外とする — 実際に起こり得ますが、その対応コストはこのタスクの範囲外です。
• 新しい事実が必要 — まず観察、ログ、人による判断、または実環境での確認が必要です。

取り消し可能なローカルの判断をユーザーに委ねないでください。既存の契約に沿った動作を推奨し、選択によってプロダクト、データ、権限、またはスコープが変わる場合にのみ質問します。

6. 列挙するだけでなく、検証する

コードまたは実際のプロダクトを利用できる場合は、実装前にリスクの高いシナリオを1〜3件安全に検証するか、検証計画に含めます。仮説を否定できる試験を優先します。再現テスト、ステートマシンテスト、プロパティベーステスト、フォールトインジェクション、または最小限のイベント列などです。

壊れたレイヤーを実際に観測できるシグナルを選びます。視覚的な動作は実際のインターフェースで、データの保持はストレージからの再読み込みで、権限は該当するロールでのリクエストで、復旧は実際の再起動で確認します。不具合を検出できない検証が成功しても、確認済みとはみなしません。

想定したシナリオを、実際に見つかった不具合として提示しないでください。それぞれを「コードで確認済み」「再現済み」「契約から導かれる」「仮説のまま」に分けて明記します。

結果

最も危険な見落としから始めます。各コーナーケースについて、次の表に簡潔にまとめます。

状況	期待される動作	見落としやすい理由	ステータス	検証

最後に、どの側面を検証し、どの側面を意図的に対象外としたか、そして確信度を最も大きく制限する未知の要素を1つ挙げます。形式だけのチェックリストにせず、黙ってタスクの範囲を広げないでください。