Точное описание доработки и ревью тест-кейсов

Когда ставится доработка, ее описание не всегда блещет краткостью, которая - сестра таланта.
Или не всегда новое. Например, захотел Заказчик фичу. Ставим доработку, а все последующие уточнения по ней просто добавляем в комментарии.

Что из этого может получится? Да ничего хорошего! Люди вообще ленивые создания, читать километровую переписку в комментах... Ну разве что от скуки или из любопытства. А если на тебе и так 10 задач, надо быстро все проверить? Будете читать? Не, ну пяткой бить себя в грудь на словах мы все умеем... А на деле?

Отличный пример из практики. Пришел к нам на работу новенький тестировщик, назовем его Никита. Я, в общем-то, тоже еще джуниором числюсь, но с консультациями он обращается ко мне. Ввести в курс дела, помочь с настройкой системы и тд.

В релизе была доработка. Написать DB View. Доработку делала я, закрывающий - Никита.
В описании задачи - лаконичные первоначальные требования. И дли-и-и-и-инный шлейф переписки в комментах.

Сделали, даже закрыли. Потом обсудили на митинге - как-то быстро закрыли, ай-яй-яй, давайте еще посмотрим. Хотя зачем смотреть - давайте сразу автотесты напишем! Ну ок.

Так как по бизнес-логике Никита мог что-то забыть, то он попросил меня помочь ему с написанием тест-кейсов:

- Давай обсудим, чтобы я ничего не забыл?
- Ок, напиши в вики свой вариант и приходи.

Пришел. Смотрю в его тесты, сразу выкидываю "лишнее". Ну, незачем себе жизнь усложнять, а то будешь через полгода дорабатывать - сам не сразу поймешь, что написал. Надо делать максимально легко и понятно.

Ок. Прошлись по основным шагам, но терзают, терзают меня сомнения. Ведь что-то было такое... Недавно... В соседнем проекте... Покопалась в джире, стали вместе изучать проблемы "соседа". Обсуждаем, обсуждаем, и тут Никита говорит "

- Нет, подожди, Заказчик вроде не то хотел...
- Да ладно о_О

Фишка в том, что, совершая некие действия, мы получаем некий результат. И во вьющке, соответственно, можно показывать или одно, или другое, или все вместе. Я сделала - все вместе.

Смотрим багу - в описании только требования к полям. Открываем почту, находим переписку - ой :) А ведь изначально планировалось отображать только результат!

Но как оно бывает?

- Если забываете - записывайте.
- Я записываю! Но забываю, где...

Это ведь было записано, но! В комментах. Которые никто при быстром ревью задачи не читает. Смотрят куда? В условие... Ну и на последний коммент, так и быть.

И главное - я то все записала. Причем специально, чтобы, если что, можно было переписку в багтрекере найти. А не лазить по почте. Но вот ведь... Согласовала же! А то, что это слегка противоречит первоначальным требованиям... Ну не мешает же :) Просто лишнее значение вытащено "на свет божий", вдруг пригодится?

Вот к чему приводит нежелание подкорректировать описание задачи...

А если бы решили не писать автотесты? Махнули бы рукой - руками проверил и ладно?
Ну и что, что слишком быстро, "а мы пальцы скрестим и понадеемся, что ошибок не будет"...
А если бы мы махнули рукой на ревью - "взрослые же люди, сам напиши то, что считаешь нужным и достаточным"?

Закрывающие задачу нужны не просто так. Это как программист, который пишет код. Ему сложно оценить его, протестировать - сам же написал! Нет там багов!!

Блин, я чувствую себя программистом :)))

Не забывайте - задачи/доработки в багтрекере ставятся не просто так! Если вам когда-нибудь понадобится вспомнить, "а с чего все начиналось" и вы полезете искать закрытую полгода назад задачу, первое (иногда и единственное), что вы будете изучать - это описание. Поэтому его надо держать актуальным.

И не пытайтесь быть гением, за которым не надо проверять. Все мы люди, все мы человеки. Все ошибаются. Это не страшно. Страшно считать, что тебя это не касается :)