Никто не любит «инвалиды». А зря?

Нередкая претензия к  тестировщикам со стороны разработчиков:

— Сколько можно плодить «инвалиды»? Достали уже. Вы б хоть немного думали перед забиванием багов!

Ситуация неприятная для всех. Тестировщики чувствуют себя идиотами, разработчики плачут о времени потерянном на такие баги, все это ухудшает отношения между разработчиками и тестировщиками (и без того не безоблачные). Завести все это далеко может, но сейчас не об этом.

Что делать, если число багов с резолюцией (resolution) INVALID зашкаливает? Очевидно, что такого быть не должно, но как бороться? Для начала — понять, в чем причина такого положения и бороться уже с причинами. А они могут быть разными, «тестировщики идиоты» — не единственная.

Небольшой список возможных причин:

1. Проблемы спецификации. Сюда относятся — устаревшая спецификация, невнятная спецификация (допускающая разные толкования), отсутствующая спецификация. В этом случае разработчик создает ПО так, как ему удобнее/понятнее. И тестировщик ожидает от программы такого поведения, которое ему кажется верным. И эти мнения редко совпадают.

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

Что делать? Договариваться. Вырабатывать культуру общения, когда мнение тестировщика не отметается с порога, а рассматривается всерьез. Привлекать третье лицо для независимого суждения. Объяснять подробнее свое мнение. А то опять же часто разработчик просто заявляет «obviously, INVALID», и все тут. А тестировщик, который потратил время на написание бага с подробной инструкцией воспроизведения должен теперь из этих двух слов понять, в чем он ошибся. Так начинаются холивары :). Объяснять почему баг инвалид тем более полезно в случае отсутствия документации. Тогда такой документацией в каком-то смысле становится сам баг-трекер: достаточно просто почитать инвалиды, и узнаешь много нового :).

2. Ошибки разработки. Простейший пример — расхождение спецификации и конечной имплементации. В этом случае, казалось бы, тестировщик прав стопроцентно: в спецификации так, программа делает по-другому — очевидно, мы имеем баг. Как ни странно, даже в таком случае иногда баг удостаивается статуса INVALID. Конечно, возможно это только в случае тотального доверия разработчикам, когда они сами решают, какой статус поставить багу. Если при этом тестировщики еще и не осмеливаются такие решения оспаривать, то это совсем безнадежный случай.

Что делать? Повышать статус отдела тестирования. Объяснять, что спецификация, а не разработчик, определяет что и как должно быть сделано. Ограничить круг лиц, которые могут поставить багу статус INVALID.

3. Улучшения. Баги, которые призваны улучшить функциональность, но спецификация о таких улучшениях ничего не говорит.

Формально тут прав разработчик: спецификация такого не содержит, делать не будем. На деле такая формальная правота может привести к тому, что пользоваться продуктом почти невозможно.

Что делать? Аппелировать к общепринятым стандартам и best practices. Ввести процедуру расширения спецификации по запросу отдела тестирования. Превращать такие баги в feature requersts.

4. Ошибки тестовой документации. Часто тестировщик не сам на месте придумывает, что и как тестировать, а пользуется какой-то тестовой документацией — тест-кейсам, чек-листами и т.д. И проблема может быть в том, что тестовая документация неполна, устарела, неверна и т.п. Баг в этом случае, конечно, «инвалид», но если на этом остановиться, то позже такой «баг» снова появится.

Что делать? Исправлять/улучшать/дополнять тестовую документацию. Можно завести в багтрекере отдельную компоненту для таких багов, переводить их туда и фиксить.

5. Невнятный багрепорт. Описание проблемы неполно, не хватает данных чтобы понять, что пошло не так или почему. Тестировщик недоисследовал проблему. Статус INVALID в таком случае вполне оправдан.

Что делать? Объяснять тестировщикам необходимость подробного описания («загнал баг без лога — увеличил энтропию»). Завести шаблон багрепорта и обязать всех следовать ему.

6. Слабое знакомство с тестируемой областью. Ясно, что человек незнакомый с DNS и почтовыми протоколами не сможет толком протестировать почтовый сервис. И даже если и найдет какие-то баги, велика вероятность их врожденной инвалидности.

Что делать? Обучать тестировщиков тому, что надо тестировать, и смежным областям. Нередко разработчикам дают время разобраться со смежными вещами перед началом разработки, а тестировщикам нет. С этим нужно бороться. Полезно чтоб перед началом тестирования разработчик объяснил неочевидные нюансы работы приложения.

7. Побочные эффекты. При тестировании сложных систем изменение настройки в одном месте может значительно менять поведение в другом. Когда несколько человек тестируют продукт на одной тестовой инсталяции, возможны различные наведенные «баги». Один где-то что-то изменил, у другого все «сломалось».

Что делать? Составлять тест-планы таким образом, чтоб подобных ситуаций было меньше. При изменении system-wide настроек предупреждать коллег об этом (голосом или почтой в зависимости от ситуации).

Как видно из этого списка, «инвалидные» баги могут возникать по вине всех участников процесса — аналитиков, разработчиков, тестировщиков. Качество продукта — общая забота, да. Никто не застрахован от ошибки. Дело не в том, кто виноват.

Нужно разбираться, почему возникают «инвалиды» и бороться с породившими их причинами. Список конкретных действий зависит от конкретной ситуации. Я попытался задать только общее направление действий.

Основная же мысль — не надо просто ругаться, что «инвалидов» много. Нужно их лечить — анализировать причины и устранять их. И тогда случится удивительное: «инвалидные» баги принесут пользу проекту!