Если тестировщик не может ясно сформулировать, что он имеет в виду; если он путается в терминах, забывает указать важные нюансы и не может совладать с эмоциями, то из его багрепорта зачастую мало что можно понять. Баг возвращается обратно (а их и так уже много вернулось), начинается пинг-понг, все нервничают и не любят друг друга.
Проблема
Проблема в том, что среди тестировщиков людей умеющих говорить кратко, точно и по делу не больше, чем среди любого другого множества людей. Таких людей вообще не так уж много к сожалению.
С другой стороны работать с неясными багрепортами не хочется никому. Как же выходить из ситуации? Ну, вариантов может быть масса - наказание кнутом любителей навести тумана, поощрение пряником способных дать зацепки, проверка ясности изложения при приеме на работу... Все эти методы имеют право на жизнь (имхо, недолгую, но сейчас не об этом), однако все они содержат одну родовую травму: все они стремятся изменить человека так, чтоб он всегда говорил ясно, говорил то, что нужно, и не говорил при этом лишнего. Люди же, как известно, меняются небыстро. Хуже того: люди могут меняться в разные стороны. Совсем плохо: люди подвержены настроению и болезням, так что даже самый лучший тестировщик может однажды написать багрепорт, из которого на следующий день сам ничего не поймет. Хороший метод, который работает: менять не людей, а рабочее окружение.
Решение
Собственно, я имею в виду простейшее и всем знакомое средство: шаблон багрепорта. Проблема с этими шаблонами в том, что ими часто не совсем правильно пользуются. Зачастую создается солидный документ, описывающий какие данные должны заноситься в багрепорт и в каких случаях. Естественно, такие документы не работают. Они лежат себе в почте или на сервере, и никто их особо не читает.
Более правильный подход: сделать шаблон, которым будет удобно пользоваться. А лучше бы - такой, каким не получится не воспользоваться. За свою карьеру тестировщика я видел несколько вариантов подобных шаблонов.
История вопроса
Нулевая стадия: когда я только начинал работать тестировщиком, я никакими шаблонами не пользовался, а всякий раз пытался заново понять, какую информацию поместить в багрепорт. Не хочу вспоминать, что получалось в итоге.
Следующий этап: я понял, что часть информации присутствует в любом багрепорте. Поэтому я завел текстовый файлик, в котором были перечислены основные элементы, которые нужно упомянуть. Содержимое этого файла я всякий раз копипастил при создании нового багрепорта. Багрепорты стали получше - основная информация в них теперь была всегда. Тем не менее я все еще часто забывал упомянуть то важный шаг, то причину, по которой я вообще решил, что встретил баг.
Далее: мне стало лень каждый раз копировать информацию из текстового файла, и я вгляделся в интерфейс багтрекера (в моем случае это была Bugzilla). Оказалось, что там есть чудесная кнопка [Remember values as bookmarkable template]. При нажатии на нее Bugzilla генерит ссылку, которую можно добавить в закладки браузера; вкусность в том, что в этой сслыке сохраняются значения всех полей, в том числе текст введенный в поле для описания проблемы. Естественно, я тут же перенес данные из текстового файла в форму багтрекера и создал закладку. На качестве багрепортов это сказалось не сильно, но теперь на каждый баг я тратил чуть меньше времени.
И наконец: мы сели и подумали еще раз, как должны выглядеть наши багрепорты, чтобы быть более понятными окружающим. Мы выписали основные пункты, которые должны присутствовать, чтобы человек, читающий багрепорт понял, какая проблема имелась в виду, как ее воспроизводить и где проводить исследования (если они нужны). Там пунктов-то немного, и можно сказать что я их все уже перечислил. А потом мы сделали так, чтобы шаблон правильного багрепорта подставлялся в соответствующее поле багтрекера сразу и всегда, когда кто-то создает новый багрепорт. Ну да, пришлось залезть в код багтрекера и немного там повозиться - ну так на то и opensource. Зато теперь все и всегда видят, что в багрепорт нужно внести:
- общую техническую информацию о том, что и где тестировалось - номер билда, сервер, аккаунт пользователя и т.д.
- пошаговую инструкцию, как повторить проблему - просто пошаговое описание, где и что в интерфейсе программы делалось и в какой последовательности
- ожидаемый результат - что человек ожидал получить в результате своих действий
- реальный результат - что было получено на самом деле
- все остальное - любая другая информация, которую автор багрепорта счел нужным сообщить.
Выгода
В результате не только багрепорты тестировщиков стали понятнее - багрепорты, написанные программистами тоже стали лучше. И новичкам стало проще не упустить важные детали.
Впрочем, не только новичкам.
Даже матерый тестировщик столкнувшись с нетривиальным багом может забыть все и вся. Запустив кучу утилит, с головой зарывшись в логи, он охотится на баг. И вот наконец готово: баг загнан в угол, лампа бьет ему в лицо ярким светом, и осталось его только приколоть булавкой к багтрекеру для коллекции.
Тестировщик выдыхает, пишет в багтрекер пару фраз и довольный идет пить кофе. А возвратившись обнаруживает, что баг вернули, потому что "ничего непонятно, ты о чем вообще?". И хорошо еще если баг вернули в тот же день, пока память о битве свежа, и логи под рукой.
Что произошло? Все просто: тестировщик сильно погрузился в контекст проблемы и забыл написать, что проблема заключается в том, что котенок не может перемещаться по наклонной поверхности с углом в 14 градусов, потому что при таком угле лапы уже скользят, а когти еще не выдвигаются. И актуально это для котят 17го поколения. А написал он просто: при 14ти градусах когтей еще нет. Что он хотел сказать? Непонятно. Ведь может и хорошо, что их нет.
А вот если бы багтрекер сразу предлагал шаблон бага, то тестировщик не смог бы описать баг только парой невнятных фраз. Само наличие шаблона уже слегка возвращает к реальной жизни, и человек задумывается: Ожидаемый результат? А кстати, что я ожидал-то? А, да: что котенок будет ходить, и когти выдвинет, если нужно. Как повторить проблему? Посадить котенка на доску и наклонить ее под нужным градусом. И так далее.
Резюме
Менять людей - задача тяжелая и неблагодарная; пусть ею занимаются психологи, священники, мессии и родители. Мы здесь не для этого, нам надо создавать продукт.
Поэтому лучше не пытаться воздействовать на людей харизмой, инструкциями и рублем, а сделать так, чтоб людям самим было удобно сделать как следует (или даже не было возможности сделать не так как следует) - и все будут довольны.
Харизму, инструкции и рубли это не отменяет - просто не всегда они нужны, иногда все проще решается.
Комментариев нет:
Отправить комментарий