
В субботу я проводил очередной тренинг “QA в Agile” и мы достаточно много времени уделили дискуссии на тему работы с дефектами в Agile. Мне кажется, что большая часть проблем в этой области возникает от непонимания конечной цели тестирования в Agile проекте и бюрократических устоев, которые достались по наследству и никуда не хотят уходить. Давайте разберемся…
Для начала, поговорим об определении дефекта. Не все так уж очевидно, как кажется на первый взгляд. Я для себя выделяю 4 типа “дефектов”: недочет, проблема, дефект и доработка. Давайте начнем с самого простого – с доработки. Представим себе итерацию в две недели и хорошую Scrum команду, которая стремится брать на себя реалистичный объем работ и выполнять его до конца итерации, предоставляя в результате рабочий продукт заказчику. Команда в первый день итерации пришла на планирование, все пользовательские истории были в деталях обсуждены, сформулированы приемочные критерии, оговорены приемочные тесты, было задано много вопросов от тестировщиков и разработчиков. Все ушли с четким пониманием, что надо делать на этом коротком интервале времени.
И вот идет уже третий день итерации и разработчики передают на тестирование первую пользовательскую историю. Тестировщик садиться ее тестировать и в процессе тестирования до него доходит – существует сценарий, о котором все забыли на планировании. Как вы думаете, работает он или нет? Естественно нет! Потому что о нем никто не задумывался в момент реализации. Если он работает, то это скорее везение, чем нормальный ход событий. Можно ли назвать это дефектом? Конечно нет! Иначе можно назвать дефектом и любую другую функциональность, о которой никто не задумывался. Это доработка, которая может вылиться чуть ли не в отдельную пользовательскую историю.
Нужно ли заносить доработку в баг-трекер? Ни в коем случае! Это чревато проваленными итерациями. Тестировщик не в праве решать насколько важная это доработка и стоит ли она того, чтобы ее непременно сделали в этой итерации. Такого рода решение может принимать только представитель бизнеса: заказчик, менеджер продукта, Product Owner. Добавление доработки в баг-трекер может привести к раздуванию сроков работы над задачами в итерации, что и приведет к провалу. Вместо этого нужно сразу же сообщить стороне бизнеса о доработке и отправить ее в виде запроса в Backlog. Дальше она может быть добавлена в следующую итерацию, отклонена, понижена в приоритете или же в срочном порядке добавлена в итерацию (естественно, с удалением другой работы из этой итерации).
Теперь представим, что тестировщик находит сценарий, который работает не так, как договаривались на планировании. Является ли это дефектом? Тоже нет! Ведь мы еще не закончили официально работать над пользовательской историей – она не дошла до состояния “ГОТОВО” и ее не показали заказчику. Значит это временная недочет, а не дефект. Недоработки не нужно заносить в баг-трекер. Ведь в этом случае будет уходить много усилий на то, что в любом случае нужно исправлять как можно скорее (мы же хотим довести историю до конца). Тут стоит использовать легковесные средства: личное общение с разработчиком, отметку на доске задач о наличии недочета, сообщение в скайп, комментарии в переоткрытую задачу, автоматизированный скрипт для демонстрации недочета и т.д. Чем короче будет цикл обратной связи, тем быстрее недочеты будут устранены.
А что, если сценарий не из новых историй, а из реализованных ранее? Поздравляем! Вот тут вы действительно нашли дефект! Его обязательно нужно занести в баг-трекер и сообщить о нем стороне бизнеса для принятия решения о его устранении. Дальше с ним может случиться такая же история как с доработкой. Попытки тестировщиков продавить дефект на исправление в этой же итерации могут быть чреваты провалом. Причина одна – незапланированная работа, которая может отнять много времени.
Остался только один тип “дефекта” – проблема. Выглядит он следующим образом: тестировщик в ходе тестирования решил попробовать что-то нестандартное, например, ввел очень много символов в текстовое поле или быстро нажал кнопку обновления страницы 10 раз подряд. В результате приложение повело себя некорректно. Почему же это не дефект? Потому что в большая часть из этих сценариев никогда не будет повторена пользователем или заказчиком. А значит, никак не повлияет на работу продукта. Мы, конечно же, говорим не о примерах, где все данные пропадают из приложения в результате действий тестировщика. 😉
Но проблемы подобного рода также не стоит заводить в баг-трекере. Вместо этого их стоит обсуждать и вырождать в нефункциональные требования или чеклисты разработчиков. В приведенном мной примере с текстовым полем в нефункциональные требования уйдет “валидация длин всех текстовых полей”, а в чеклист разработчику “для всех форм на странице нужно не забывать делать валидацию на длину поля”. Добавление же в баг-трекер не принесет пользы. Маловероятно, что этим будут заниматься в скором времени, но при этом будет захламляться баг-трекер. Значит, станет тяжелее найти в нем нужную информацию и придется время от времени проверять ее валидность. Зачем тратить время на такие глупости? 🙂 Но, если очень хочется, можно устроить где-то в баг-трекере склад подобных проблем “на будущее”. Лучше, конечно, добавить автотест, который будет показывать в каком состоянии находится данная проблема.
А вы как работаете с “дефектами” у себя в проекте? И когда используете баг-трекер? Делитесь в комментариях!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!