Правильный багрепорт для всех и каждого

Умение доносить свои мысли до другого человека — качество, необходимое тестировщику. Оно включает в себя способность и внятно сформулировать свои мысли, и выразить одну и ту же мысль разными словами, и выбрать верную интонацию (неважно,  в письме или устной речи), и много что еще.

Если тестировщик не может ясно сформулировать, что он имеет в виду; если он путается в терминах, забывает указать важные нюансы и не может совладать с эмоциями, то из его багрепорта зачастую мало что можно понять. Баг возвращается обратно (а их и так уже много вернулось), начинается пинг-понг, все нервничают и не любят друг друга.

Проблема

Проблема в том, что среди тестировщиков людей умеющих говорить кратко, точно и по делу не больше, чем среди любого другого множества людей. Таких людей вообще не так уж много к сожалению.

С другой стороны работать с неясными багрепортами не хочется никому. Как же выходить из ситуации? Ну, вариантов может быть масса — наказание кнутом любителей навести тумана, поощрение пряником способных дать зацепки, проверка ясности изложения при приеме на работу… Все эти методы имеют право на жизнь (имхо, недолгую, но сейчас не об этом), однако все они содержат одну родовую травму: все они стремятся изменить человека так, чтоб он всегда говорил ясно, говорил то, что нужно, и не говорил при этом лишнего. Люди же, как известно, меняются небыстро. Хуже того: люди могут меняться в разные стороны. Совсем плохо: люди подвержены настроению и болезням, так что даже самый лучший тестировщик может однажды написать багрепорт, из которого на следующий день сам ничего не поймет. Хороший метод, который работает: менять не людей, а рабочее окружение.

Решение

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

Более правильный подход: сделать шаблон, которым будет удобно пользоваться. А лучше бы — такой, каким не получится не воспользоваться. За свою карьеру тестировщика я видел несколько вариантов подобных шаблонов.

История вопроса

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

Следующий этап: я понял, что часть информации присутствует в любом багрепорте. Поэтому я завел текстовый файлик, в котором были перечислены основные элементы, которые нужно упомянуть. Содержимое этого файла я всякий раз копипастил при создании нового багрепорта. Багрепорты стали получше — основная информация в них теперь была всегда. Тем не менее я все еще часто забывал упомянуть то важный шаг, то причину, по которой я вообще решил, что встретил баг.

Далее: мне стало лень каждый раз копировать информацию из текстового файла, и я вгляделся в интерфейс багтрекера (в моем случае это была Bugzilla). Оказалось, что там есть чудесная кнопка [Remember values as bookmarkable template]. При нажатии на нее Bugzilla генерит ссылку, которую можно добавить в закладки браузера; вкусность в том, что в этой сслыке сохраняются значения всех полей, в том числе текст введенный в поле для описания проблемы. Естественно, я тут же перенес данные из текстового файла в форму багтрекера и создал закладку. На качестве багрепортов это сказалось не сильно, но теперь на каждый баг я тратил чуть меньше времени.

И наконец: мы сели и подумали еще раз, как должны выглядеть наши багрепорты, чтобы быть более понятными окружающим. Мы выписали основные пункты, которые должны присутствовать, чтобы человек, читающий багрепорт понял, какая проблема имелась в виду, как ее воспроизводить и где проводить исследования (если они нужны). Там пунктов-то немного, и можно сказать что я их все уже перечислил. А потом мы сделали так, чтобы шаблон правильного багрепорта подставлялся в соответствующее поле багтрекера сразу и всегда, когда кто-то создает новый багрепорт. Ну да, пришлось залезть в код багтрекера и немного там повозиться — ну так на то и opensource. Зато теперь все и всегда видят, что в багрепорт нужно внести:

  • общую техническую информацию о том, что и где тестировалось — номер билда, сервер, аккаунт пользователя и т.д.
  • пошаговую инструкцию, как повторить проблему — просто пошаговое описание, где и что в интерфейсе программы делалось и в какой последовательности
  • ожидаемый результат — что человек ожидал получить в результате своих действий
  • реальный результат — что было получено на самом деле
  • все остальное — любая другая информация, которую автор багрепорта счел нужным сообщить.

Выгода

В результате не только багрепорты тестировщиков стали понятнее — багрепорты, написанные программистами тоже стали лучше. И новичкам стало проще не упустить важные детали.

Впрочем, не только новичкам.

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

Тестировщик выдыхает, пишет в багтрекер пару фраз и довольный идет пить кофе. А возвратившись обнаруживает, что баг вернули, потому что «ничего непонятно, ты о чем вообще?». И хорошо еще если баг вернули в тот же день, пока память о битве свежа, и логи под рукой.

Что произошло? Все просто: тестировщик сильно погрузился в контекст проблемы и забыл написать, что проблема заключается в том, что котенок не может перемещаться по наклонной поверхности с углом в 14 градусов, потому что при таком угле лапы уже скользят, а когти еще не выдвигаются. И актуально это для котят 17го поколения. А написал он просто: при 14ти градусах когтей еще нет. Что он хотел сказать? Непонятно. Ведь может и хорошо, что их нет.

А вот если бы багтрекер сразу предлагал шаблон бага, то тестировщик не смог бы описать баг только парой невнятных фраз. Само наличие шаблона уже слегка возвращает к реальной жизни, и человек задумывается: Ожидаемый результат? А кстати, что я ожидал-то? А, да: что котенок будет ходить, и когти выдвинет, если нужно. Как повторить проблему? Посадить котенка на доску и наклонить ее под нужным градусом. И так далее.

Резюме

Менять людей — задача тяжелая и неблагодарная; пусть ею занимаются психологи, священники, мессии и родители. Мы здесь не для этого, нам надо создавать продукт.

Поэтому лучше не пытаться воздействовать на людей харизмой, инструкциями и рублем, а сделать так, чтоб людям самим было удобно сделать как следует (или даже не было возможности сделать не так как следует) — и все будут довольны.

Харизму, инструкции и рубли это не отменяет — просто не всегда они нужны, иногда все проще решается.

Почему их так много?

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

Сегодня я задумался, о чем говорит большое количество багов с другими резолюциями.

Вот что получилось.

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

Если много дубликатов, то возможно, что

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

Что делать: всегда проверять, что проблема еще не зарегистрирована в багтрекере. Если лень проверять — то хотя бы спросить окружающих, они могут что-то помнить.

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

Что делать: объяснять нюансы работы приложения, улучшать архитектуру системы, внедрять/расширять тестирование методом белого ящика (white/glass box testing)

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

Что делать: отслеживать срок жизни багов, искать пути его сокращения

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

что делать: объяснять архитектуру приложения; при написании багрепорта думать, насколько общая функциональность затронута; слушать, по какому поводу матерят продукт коллеги.

неверно выставленный статус. Порой разработчики объявляют дубликатами разные но похожие проблемы либо разные проблемы в одном методе. Это, вообще говоря, неверный подход и такие действия стоит пресекать (без объявления войн, конечно).

Что делать: аккуратно описывать проблемы, чтобы было понятно, что они — разные, отдельно подчеркивать различия. При верификации проверять каждый баг по-отдельности, воспроизводя соответствующий сценарий для каждого из них (чинились оба бага, может, и один коммитом, но если проблемы были разные, то и проверять следует обе).

— баги распределены в багтрекере таким образом, что их трудно найти при всем желании. Если один багтрекер используется для учета проблем нескольких продуктов, взаимодействующих друг с другом, то человек наступивший на проблему может честно проверить, что для продукта А (тестируемого в данный момент) такой баг не зарегистрирован. Человек репортит баг, позже оказывается, что проблема на самом деле в продукте К, и уже была описана. Ситуация усугубляется, если продукты А и К разрабатываются в разных городах, особенно если при разработке используются различные процессы.

Что делать: тщательней смотреть, к какому продукту относится проблема; если проблема описана для продукта А, а на самом деле беда в продукте К, то не переносить багрепорт в базу продукта К, а создавать там клон этого багрепорта.

Большое число невоспроизводимых багов говорит о

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

Что делать: максимально точно устанавливать и описывать сценарий повторения проблемы. Обычно это требует хорошего понимания работы продукта.

существенном отличии окружения, в котором продукт установлен и работает у разработчиков и тестировщиков. В итоге что-то может не работать у одних, но летать у других.

Что делать: исследовать описанную проблему в том окружении, где она была найдена.

— том, что часть из них инвалиды. Просто по каким-то причинам их не сочли таковыми.

 

Если много описанных проблем закрывается как Wontfix, то вероятно

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

— описанные проблемы действительно неважны для бизнеса. Это косвено указывает, что тестируется не то, что надо бы тестировать.

Что делать: улучшать продукт; уточнять приоритеты тестирования.

 

Кроме того, для любой из этих резолюций (Invalid, Worksforme, Duplicate, Wontfix) ненормально большое количество таких багов может указывать на то, что резолюции по каким-то причинам используются неверно.

Что делать: объяснять значение каждой резолюции, каким багам они должны присваиваться.

Кроме резолюций, можно обратить внимание и на статусы багов.

Много новых (New) багов:

— похоже, программисты не справляются с потоком багов от тестировщиков. Либо разрабатывают новую функциональность в ущерб качеству уже существующей.

Что делать: аккуратней работать, чтобы багов в целом было меньше. Включать в планы починку багов.

Много починеных, но не проверенных багов:

— похоже, тестировщики не успевают проверять баги. Это плохо, особенно если известно, что баги часто переоткрываются после проверки.

Что делать: тщательней планировать работу тестировщиков.

Высокий уровень Reopen’ов может указывать на то, что

программисты небрежно чинят баги. В результате починеные баги не проходят проверку и все снова тратят время на решение той же проблемы

— тестировщики небрежно проверяют починеные баги, и переоткрывают баг даже если проблема на самом деле уже другая, хотя и близкая/похожая.

Что делать: всем быть внимательней. Дьявол в деталях.

Также, ненормально большое количество багов в любом из этих состояний может говорить и о каких-то проблемах, не связанных с багами на прямую. Медленные машинки у сотрудников, недостаточно ресурсов для эффективной работы, проблемы в процессе разработки и т.д.

P.S.

Определения:

Возможные резолюции багов:

Инвалид (Invalid) — багрепорт, описывающий ситуацию, не являющуюся багом, система работает правильно.

Дубликат (Duplicate) — багрепорт описыват проблему уже описанную ранее в другом багрепорте

Невоспроизводим (Worksforme) — при попытке воспроизвести проблему по описанию из багрепорта проблема не воспроизводится. С другой стороны нет и уверенности/доказательств, что это инвалид.

Оставлен (Wontfix) — багрепорт описывающий реальную проблему, которую решено не чинить.

Починен (Fixed) — багрепорт, описывающий реальную проблему, которая была починена в продукте.

Возможные статусы багов:

Новый (New) — решение по багу еще не принято (возможные решения: Invalid, Duplicate, Worksforme, Wontfix, Fixed)

Закрыт (Resolved) — багрепорт, по которому принято то или иное решение (возможные решения: Invalid, Duplicate, Worksforme, Wontfix, Fixed).

Проверен (Verified) — багрепорт, решение которого было проверено соответствующим подразделением, в процессе проверки не было найдено несоответствий.

Переоткрыт (Reopened) — багрепорт, решение которого было проверено соответствующим подразделением, в процессе проверки обнаружилось, что принятое решение неверно.