Как оцениваете детализацию тикетов
Что проверяют
Есть ли у вас критерий «тикет готов к работе», а не ощущение. Под детализацией обычно понимают две вещи: хватает ли в задаче от аналитика информации, чтобы её протестировать, и насколько полно вы сами описываете баги. Следом просят показать плохой тикет и сказать, что вы с ним сделаете.
Как отвечать
Главный критерий общий для обеих сторон: другой человек сможет работать с тикетом, не задав ни одного уточняющего вопроса.
Во входящих задачах проверяйте тестируемость:
- критерии приёмки: конкретные и проверяемые, удобно в формате Given/When/Then. «Удобная форма» не критерий, «кнопка неактивна, пока не заполнены обязательные поля» критерий;
- граничные и негативные случаи: что при пустом вводе, при ошибке сервера, при отсутствии прав;
- макеты и контракты: ссылка на актуальный дизайн и описание API;
- Definition of Ready: если в команде есть DoR, тикет без нужных полей в спринт не берут.
В своих баг-репортах:
- шаги воспроизведения: с тестовыми данными, плюс ожидаемый и фактический результат;
- окружение: стенд, сборка, устройство, браузер, учётная запись;
- доказательства: скриншот, видео, логи, идентификатор запроса;
- severity и priority: раздельно, это разные оценки.
Детализация должна быть соразмерной: для опечатки хватит скриншота и ссылки, а плавающему багу в оплате нужны логи, время и частота воспроизведения.
Когда тикет сырой, не молчите и не додумывайте: задайте вопросы в комментариях, верните аналитику или разберите на встрече «трёх амиго». Приведите свой пример такого тикета и того, что вы с ним сделали. Если измеримого эффекта у вас нет, не придумывайте проценты, достаточно рассказать, как изменился процесс.
Где спотыкаются
Рассказывают только шаблон баг-репорта и забывают про входящие задачи. А пропущенное на этапе требований обходится дороже любого плохо описанного бага.
Путают severity и priority: опечатка в названии продукта на главной странице имеет низкую серьёзность, но высокий приоритет.
Складывают пять разных проблем в один отчёт. Такой тикет нельзя закрыть частично, и половина проблем теряется при исправлении.