Home

Автор: Майк Токс (Mike Talks).

Оригинал статьи: http://testsheepnz.blogspot.ru/2016/02/denial-104-but-we-spent-lot-of-money-on.html

Перевод: Ольга Алифанова

Сегодня мы рассмотрим пример отрицаний, связанный с тестированием, и разные точки зрения на него.  Дамы и господа, представляю вам образец...

"Но мы же потратили столько денег и на лицензию, и на настройку!"

Тут работает базовая установка, что много денег - значит "подходящий продукт". Ранее мы говорили о давлении коллектива, и я упоминал про этот парадокс - особенно про миф, что инструмент управления тестами - это "бесплатная отчетность"...Вообще-то я сразу начинаю нервничаю, когда мне что-то предлагают на халяву - в основном из-за вот этого типа...

Пиф-Паф-Ой-Ой-Ой, ловец детей. Заманивает их бесплатными чупа-чупсами. Уверен, сейчас он зарабатывает ловлей беззащитных IT-проектов на приманку корпоративных лицензионных соглашений.

Инструменты тестирования ловят вас на крючок определенным образом. Если они - именно то, что вам нужно для работы, это супер. Однако если они не вполне соответствуют вашим потребностям, вы попали. У вас на руках сложная и глючная методология, которая будет ставить вам палки в колеса. Воздействие такой ситуации на команду очень сложно измерить. За исключением того, что вся команда возненавидит этот инструмент.

Но это еще не все! Есть вещи и похуже, чем "коробочное" решение, которое только частично удовлетворяет ваши потребности. Это продукт, настроенный под заказ.

У меня есть забавный (но правдивый!) пример из личной практики. Много лет назад нам пришлось пользоваться Microsoft Team Foundation Server (TFS). Один предприимчивый менеджер решил, что для максимальной полезности приложения нужно заменить устаревший жизненный цикл бага (см. картинку ниже) на более подробную систему, которая обеспечит повышенную детализацию отчетности.

И так из простого...

Сложность жизненного цикла нормального человека

... получилась вот такая иерархия статусов, через которые баг проходил перед закрытием.

• Предложен
• Подтвержден
• Назначен на тимлида разработки
• Назначен разработчику
• В работе у разработчика
• Код исправлен
• Готов для юнит-теста
• Назначен на юнит-тестировщика
• Юнит-тестирование завершено
• Готов к системному тестированию
• Назначен системному тестировщику
• Системное тестирование завершено
• Готов к препродакшн-тестированию
• Назначен на препродакшн-тестировщика
• Препродакшн-тестирование завершено
• Готов к деплою
• Развернут на прод
• Проверен на проде
• Подтвержден
• Закрыт.

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

В результате для того, чтобы просто закрыть протестированный фикс, нужно было угробить десять минут времени. Неудивительно, что начался бунт - мы не будем использовать TFS как баг-трекер, она для этого не подходит! Естественно, никто не мог использовать ее в простоте, но зато какая шикарная была отчетность! Кстати, в конце концов мы победили, и количество статусов сократилось до приемлемого уровня.

Я видел такие комедии сто раз в случаях, когда:

• трудолюбивый менеджер вносит новые статусы в систему управления дефектами/тестами,
• он же обнаруживает, что ему приходится ловить всех за руки или подкупать их, чтобы они обновили баг-трекер. Почему? Да потому, что он дичайше неудобный, и пользы от него никакой.

Эффект отрицания в данном случае двойной:

• Команда тестирования вынуждена подчинять свои процессы инструменту. Хотя, по изначальной задумке, это инструмент должен облегчать жизнь тестировщику. Чем больше денег было выкинуто на этот инструмент, тем больше оправданий будет для навязывания подхода, который в инструменте используется, отделу тестирования. Приправьте это парой фразочек вроде "корпоративный стандарт" или "передовой опыт", чтобы заставить команду прогнуться под инструмент, а не наоборот.
• Чем больше настроек, тем лучше! Наш тщательно настроенный жизненный цикл бага подходил ровно для одной ситуации, но совершенно не справлялся со всеми остальными. Я видел множество проектов, которые кастомизируют свои инструменты, доходя до смешного - обычно руководствуясь сценариями "а что, если...".Проблема в том, что результат больше похож на карту лондонского метро, чем на нормальный процесс. Хоть он и подходит для некоторых сценариев, но попытка сделать при его помощи что-нибудь несложное обычно превращается в кошмар. В итоге никто не хочет даже открывать инструкции по жизненному циклу бага в этом инструменте.

Сложность жизненного цикла курильщика

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

Я считаю, что если кто-то давит на вас и пытается протащить еще один статус "чисто на всякий случай" - сопротивляйтесь изо всех сил. А если вы нашли статус, который вы частенько пропускаете на пути к следующему статусу, подумайте - не стоит ли его удалить? Этот статус для вас бесполезен.

Обсудить в форуме