Что происходит после написания тест-кейсов и обнаружения ошибки
Что проверяют
Знаете ли вы жизненный цикл дефекта и что входит в работу после находки. Вопрос простой, но по нему видно, работал ли человек в команде: у такого кандидата ответ начинается не с заведения задачи, а с воспроизведения.
Как отвечать
Сначала подтвердите находку: повторите на чистом окружении, сократите шаги до минимальных, проверьте на другом браузере или устройстве, определите, регрессия это или так было всегда, и поищите такой же дефект в трекере, чтобы не плодить дубли.
Потом отчёт, по которому можно чинить, не задавая вопросов:
- заголовок из того, что сломалось, где и при каком условии;
- окружение, номер сборки, учётная запись и данные;
- предусловия, шаги, ожидаемый и фактический результат;
- вложения: логи, запрос и ответ, запись экрана, идентификатор трассировки;
- серьёзность и срочность отдельно. Первая про влияние на систему, вторая про то, когда это нужно бизнесу, и назначает её обычно не тестировщик единолично.
Дальше сопровождение: разбор дефекта командой, проверка исправления на той сборке, куда оно действительно попало, проверка соседних сценариев вокруг правки, закрытие с комментарием. И то, про что забывают чаще всего: обновить или добавить тест-кейс, чтобы находка стала постоянной проверкой, и разобрать, почему её не поймали раньше.
Где спотыкаются
Заводят дефект без шагов и номера сборки. Такой отчёт возвращается со статусом о невоспроизводимости, неделя уходит на переписку, и к релизу задача остаётся открытой.
Второе: путают серьёзность и срочность или ставят всему высший уровень. Когда блокирующих десяток, приоритеты перестают работать, и команда начинает выбирать задачи на глаз.
Третье: проверяют исправление ровно по шагам из отчёта. Правка часто задевает соседнее поведение, поэтому нужны и смежные сценарии. Отдельная беда это закрытие дефекта на сборке, в которой исправления ещё нет.