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