суббота, 20 марта 2010 г.

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

Нередкая претензия к  тестировщикам со стороны разработчиков:
- Сколько можно плодить "инвалиды"? Достали уже. Вы б хоть немного думали перед забиванием багов!
Ситуация неприятная для всех. Тестировщики чувствуют себя идиотами, разработчики плачут о времени потерянном на такие баги, все это ухудшает отношения между разработчиками и тестировщиками (и без того не безоблачные). Завести все это далеко может, но сейчас не об этом.
Что делать, если число багов с резолюцией (resolution) INVALID зашкаливает? Очевидно, что такого быть не должно, но как бороться? Для начала - понять, в чем причина такого положения и бороться уже с причинами. А они могут быть разными, "тестировщики идиоты" - не единственная.

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

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

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

3. Улучшения. Баги, которые призваны улучшить функциональность, но спецификация о таких улучшениях ничего не говорит.
Формально тут прав разработчик: спецификация такого не содержит, делать не будем. На деле такая формальная правота может привести к тому, что пользоваться продуктом почти невозможно.
Что делать? Аппелировать к общепринятым стандартам и best practices. Ввести процедуру расширения спецификации по запросу отдела тестирования. Превращать такие баги в feature requersts.

4. Ошибки тестовой документации. Часто тестировщик не сам на месте придумывает, что и как тестировать, а пользуется какой-то тестовой документацией - тест-кейсам, чек-листами и т.д. И проблема может быть в том, что тестовая документация неполна, устарела, неверна и т.п. Баг в этом случае, конечно, "инвалид", но если на этом остановиться, то позже такой "баг" снова появится.
Что делать? Исправлять/улучшать/дополнять тестовую документацию. Можно завести в багтрекере отдельную компоненту для таких багов, переводить их туда и фиксить.

5. Невнятный багрепорт. Описание проблемы неполно, не хватает данных чтобы понять, что пошло не так или почему. Тестировщик недоисследовал проблему. Статус INVALID в таком случае вполне оправдан.
Что делать? Объяснять тестировщикам необходимость подробного описания ("загнал баг без лога - увеличил энтропию"). Завести шаблон багрепорта и обязать всех следовать ему.

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

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


Как видно из этого списка, "инвалидные" баги могут возникать по вине всех участников процесса - аналитиков, разработчиков, тестировщиков. Качество продукта - общая забота, да. Никто не застрахован от ошибки. Дело не в том, кто виноват.
Нужно разбираться, почему возникают "инвалиды" и бороться с породившими их причинами. Список конкретных действий зависит от конкретной ситуации. Я попытался задать только общее направление действий.
Основная же мысль - не надо просто ругаться, что "инвалидов" много. Нужно их лечить - анализировать причины и устранять их. И тогда случится удивительное: "инвалидные" баги принесут пользу проекту!

Комментариев нет:

Отправить комментарий