Модуль 5 · Урок 17
Anomaly, reproduction і root-cause boundaries
Не кожна незвична поведінка одразу є product defect. Спочатку зафіксуйте observation, точний baseline і test context, відтворіть явище та виключіть помилку даних, середовища або невизначене правило.
Anomaly — чесна початкова назва
Failure може бути спричинений defect, environment, test data, tool, configuration, misunderstanding або change request. Називаючи причину до investigation, QA створює confirmation bias. Реєструйте: що спостерігали, де, коли, на якій версії та яке approved source задає expected behavior.
Мінімізуйте reproducer
- Заморозьте build, environment, config і test data.
- Повторіть original flow без змін.
- Зменшуйте steps і variables по одному.
- Перевірте frequency, scope, роль, браузер/API client, time і concurrency.
- Збережіть negative control: умову, за якої anomaly не виникає.
Нестабільний результат не можна «покращити» до 100% reproducible. Чесно вкажіть 2/10, умови й limitation.
Evidence має допомагати, а не витікати
Збирайте request ID, timestamp, relevant payload fragment, response, state before/after, console/network/log reference. Прибирайте tokens, cookies, PII та зайві dumps. Screenshot без build, URL і state не є достатнім reproducer.
QA не призначає root cause без доказу
Ticket може описати likely component, але source-code diagnosis і fix належать investigation/debugging. Відділяйте failure observation від підтвердженого defect і root cause.
Практика
Заповніть `anomaly-intake.csv` і `reproduction-evidence.csv`: observation, baseline, expected source, minimized steps, frequency, control, evidence та redaction.
Офіційне джерело
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.