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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если много дубликатов, то возможно, что
- люди не проверяют, есть ли уже такой баг в базе багтрекера, перед занесением туда встреченной проблемы. Иногда дубликаты возникают, когда два человека нашли одну и ту же проблему, честно проверили что ее описания нет в багтрекере, и одновременно зарепортили два одинаковых бага.
Что делать: всегда проверять, что проблема еще не зарегистрирована в багтрекере. Если лень проверять - то хотя бы спросить окружающих, они могут что-то помнить.
- одна и та же проблема проявляется по-разному при работе системы. Тестировщикам не всегда очевидно, что две совершенно непохожих проблемы в работе приложения обусловлены одной и той же строкой где-то глубоко в кишках кода.
Что делать: объяснять нюансы работы приложения, улучшать архитектуру системы, внедрять/расширять тестирование методом белого ящика (white/glass box testing)
- баг долго не фиксится, так что каждый тестировщик успевает его найти, описать и забыть. Натурально, по этой причине я пару раз писал дубликаты на свои же багрепорты. Важно увидеть и эту проблему тоже, не спихивать все на первый пункт, который в данном случае тоже играет свою роль.
Что делать: отслеживать срок жизни багов, искать пути его сокращения
- сломана какая-то базовая или общая функциональность, так что проблема начинает проявляться в каждом модуле. Например, в случае веб-приложения содержащего много страниц с различными списками фильтрация списков может сломаться одновременно для разных страниц. При этом люди, тестирующие соответствующие модули зарепортят отдельные баги на каждый модуль.
что делать: объяснять архитектуру приложения; при написании багрепорта думать, насколько общая функциональность затронута; слушать, по какому поводу матерят продукт коллеги.
- неверно выставленный статус. Порой разработчики объявляют дубликатами разные но похожие проблемы либо разные проблемы в одном методе. Это, вообще говоря, неверный подход и такие действия стоит пресекать (без объявления войн, конечно).
Что делать: аккуратно описывать проблемы, чтобы было понятно, что они - разные, отдельно подчеркивать различия. При верификации проверять каждый баг по-отдельности, воспроизводя соответствующий сценарий для каждого из них (чинились оба бага, может, и один коммитом, но если проблемы были разные, то и проверять следует обе).
- баги распределены в багтрекере таким образом, что их трудно найти при всем желании. Если один багтрекер используется для учета проблем нескольких продуктов, взаимодействующих друг с другом, то человек наступивший на проблему может честно проверить, что для продукта А (тестируемого в данный момент) такой баг не зарегистрирован. Человек репортит баг, позже оказывается, что проблема на самом деле в продукте К, и уже была описана. Ситуация усугубляется, если продукты А и К разрабатываются в разных городах, особенно если при разработке используются различные процессы.
Что делать: тщательней смотреть, к какому продукту относится проблема; если проблема описана для продукта А, а на самом деле беда в продукте К, то не переносить багрепорт в базу продукта К, а создавать там клон этого багрепорта.

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

Если много описанных проблем закрывается как Wontfix, то вероятно
- в продукте слишком много критичных багов, и на все, что "не столь критично" закрываются глаза.
- описанные проблемы действительно неважны для бизнеса. Это косвено указывает, что тестируется не то, что надо бы тестировать.
Что делать: улучшать продукт; уточнять приоритеты тестирования.

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


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

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

Высокий уровень Reopen'ов может указывать на то, что
- программисты небрежно чинят баги. В результате починеные баги не проходят проверку и все снова тратят время на решение той же проблемы
- тестировщики небрежно проверяют починеные баги, и переоткрывают баг даже если проблема на самом деле уже другая, хотя и близкая/похожая.
Что делать: всем быть внимательней. Дьявол в деталях.

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