Дефект или не дефект?
Представим себе итерацию в две недели и хорошую Scrum команду, которая стремится брать на себя реалистичный объем работ и выполнять его до конца итерации, предоставляя в результате рабочий продукт заказчику. Команда в первый день итерации пришла на планирование, все пользовательские истории были в деталях обсуждены, сформулированы приемочные критерии, оговорены приемочные тесты, было задано много вопросов от тестировщиков и разработчиков. Все ушли с четким пониманием, что надо делать на этом коротком интервале времени.
И вот идет уже третий день итерации и разработчики передают на тестирование первую пользовательскую историю. Тестировщик садиться ее тестировать и в процессе тестирования до него доходит – существует сценарий, о котором все забыли на планировании. Как вы думаете, работает он или нет? Естественно нет! Потому что о нем никто не задумывался в момент реализации. Если он работает, то это скорее везение, чем нормальный ход событий. Можно ли назвать это дефектом? Не совсем! Иначе можно назвать дефектом и любую другую функциональность, о которой никто не задумывался. Это доработка, которая может вылиться чуть ли не в отдельную пользовательскую историю.
Нужно ли заносить доработку в баг-трекер как дефект? Это чревато проваленными итерациями. Тестировщик не может решать насколько важная это доработка и стоит ли она того, чтобы ее непременно сделали в этой итерации. Такого рода решение может принимать только представитель бизнеса: заказчик, менеджер продукта, Product Owner. Добавление доработки в баг-трекер в виде дефекта может привести к раздуванию сроков работы над задачами в итерации, что и приведет к провалу. Вместо этого нужно сразу же сообщить стороне бизнеса о доработке и отправить ее в виде запроса в Backlog. Дальше она может быть добавлена в следующую итерацию, отклонена, понижена в приоритете или же в срочном порядке добавлена в итерацию (естественно, с удалением другой работы из этой итерации).
А что, если сценарий не из новых историй, а из реализованных ранее? Поздравляем! Вот тут вы действительно нашли дефект! Его обязательно нужно занести в баг-трекер и сообщить о нем стороне бизнеса для принятия решения о его устранении. Дальше с ним может случиться такая же история как с доработкой. Попытки тестировщиков продавить дефект на исправление в этой же итерации могут быть чреваты провалом. Причина одна – незапланированная работа, которая может отнять много времени.
Рассмотрим пример. Выглядит он следующим образом: тестировщик в ходе тестирования решил попробовать что-то нестандартное, например, ввел очень много символов в текстовое поле или быстро нажал кнопку обновления страницы 10 раз подряд. В результате приложение повело себя некорректно. Почему же это, возможно, не дефект? Потому что в большая часть из этих сценариев никогда не будет повторена пользователем или заказчиком. А значит, никак не повлияет на работу продукта. Мы, конечно же, говорим не о примерах, где все данные пропадают из приложения в результате действий тестировщика. Но проблемы подобного рода, возможно, не стоит заводить в баг-трекер. Вместо этого их стоит обсуждать и вырождать в нефункциональные требования или чеклисты разработчиков. В приведенном мной примере с текстовым полем в нефункциональные требования уйдет «валидация длин всех текстовых полей», а в чеклист разработчику «для всех форм на странице нужно не забывать делать валидацию на длину поля».