Модуль 5 · Урок 18
Defect report: expected, actual і evidence
Сильний report дає команді достатньо інформації, щоб відтворити anomaly, оцінити impact, прийняти рішення й перевірити fix — без приватного контексту в голові автора.
Ticket як відтворюваний контракт
| Поле | Вимога |
|---|---|
| Title | Object + condition/action + observable failure, без драматизації. |
| Build/environment | Exact version, config, device/client і data fixture. |
| Preconditions/steps | Мінімальні, нумеровані, без прихованого setup. |
| Expected/actual | Approved oracle проти конкретного observation. |
| Impact/evidence | Stakeholder consequence, frequency, scope, redacted references. |
Title і steps не повинні вгадувати fix
«API: duplicate confirm request returns a second success response» сильніше за «Backend broken» або «Add lock in service». Report описує problem; recommendation щодо implementation з’являється після investigation.
Expected — із джерелом, actual — із фактом
Посилайтеся на requirement, contract, design, accessibility criterion або узгоджене business rule. Якщо oracle неясний, status може бути needs-clarification, а не вигаданий bug. Actual включає observable state і forbidden side effects.
Не вставляйте секрети в tracker
Замініть токени, cookies, email і customer IDs. Повний secure log лишайте в дозволеному сховищі з access control; ticket містить reference.
Перед submit
- Пошук duplicate виконано.
- Current build і exact environment підтверджені.
- Steps відтворюються іншою людиною.
- Expected та actual не змішані.
- Severity/priority подані як пропозиція з rationale.
- Evidence мінімальне, redacted і доступне команді.
Практика: завершіть `defect-reports.csv` і проведіть peer review без усного пояснення.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.