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

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

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

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

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

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

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

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

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

Что делать: объяснять нюансы работы приложения, улучшать архитектуру системы, внедрять/расширять тестирование методом белого ящика (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) — багрепорт, решение которого было проверено соответствующим подразделением, в процессе проверки обнаружилось, что принятое решение неверно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *