Давайте рассмотрим ключевые этапы жизненного цикла бага: от его обнаружения до его устранения и поймем, как четкий рабочий процесс улучшает коммуникацию, отслеживание и общее качество продукта.
В этой статье будет дано общее представление о жизненном цикле бага. Как всем известно, в каждом проекте есть определенные особенности, которые влияют на общий ход решения проблем. Начнем с общего подхода к работе с багами и дополним его реалистичными примерами из моего собственного опыта.
Жизнь каждого бага начинается с его обнаружения. О проблемах обычно сообщают либо QA инженеры, либо клиенты. Актуальность и критичность каждого из них ̶ тема для отдельного обсуждения, но в конечном итоге любая ошибка появляется в системе отслеживания багов, используемой на проекте. Я буду использовать JIRA в качестве примера, поэтому рассматривайте любые статусы и действия, упомянутые ниже, как относящиеся к конкретным статусам и действиям в JIRA.
Как только баг появляется на доске JIRA, по умолчанию ему присваивается статус «Open». Позже по таким статусам можно будет отслеживать весь жизненный цикл бага. Наиболее распространенными этапами решения любой проблемы являются:
Кроме того, довольно часто могут использоваться следующие статусы:
Reopened — в ситуации, когда ошибка должна была быть исправлена и закрыта, но позже выяснилось, что исправления было недостаточным.
Blocked — тестирование невозможно из‑за некоторых внешних обстоятельств (например, общих проблем с окружением — исправление уже готово, но мы не можем его протестировать).
Rejected — в тех случаях, когда подробное изучение показывает, что проблема на самом деле не является багом (например, определенное требование было неверно истолковано).
Конечно, статусов может быть гораздо больше. Сравните приведенный выше рабочий процесс с реальным кейсом на одном из моих прошлых проектов (пока не обращайте внимания на иерархию, нас больше интересуют сами статусы):
Каквы видите, существуют дополнительные состояния, такие как «Accepted», «Feasibility», «Ready for development», «Deployment» и т. д. Такая детализация была оправдана, поскольку все баги на проекте тщательно отслеживались, и важно было понимать, сколько времени было потрачено, например, на развертывание, ожидание, пока у разработчика появится время для начала исправления багов или проверки в конкретном окружении.
Примечание: Один и тот же статус (например, «In test») может иметь разные значения для разных проектов.
Помимо статусов, на моем прошлом проекте большое внимание уделялось конкретным резолюциям. Например, с точки зрения статуса ошибка имела статус «Closed» (формально это означало, что ошибка исправлена и протестирована), но решение было «Duplicate». Это придало багу другой контекст — эта ошибка не была учтена в работе; на самом деле о ней уже сообщал кто‑то другой.
Поэтому не стесняйтесь обращаться к руководителям и Scrum‑мастерам за уточнением процессов проекта. Обычно рабочие процессы, связанные с багами, документируются и хранятся в Confluence, в общих папках и т. д. Более того, подход может меняться с течением времени, поэтому особенно важно располагать наиболее актуальной информацией.
Вы также можете проверить текущий рабочий процесс в JIRA ticket, но я считаю, что он не точен на 100% — поскольку несколько команд используют один и тот же проект JIRA (и процессы могут отличаться), могут быть обнаружены незначительные различия:
Как только рабочий процесс будет стандартизирован, важно следовать наиболее эффективным методам работы. Во‑первых, вся команда должна иметь четкое представление о каждом этапе. Здесь была бы полезна встреча, чтобы ответить на любые возникшие у коллег вопросы. QA команда должна следить за тем, как оформляются отчеты об ошибках: документация должна быть подробной и соответствовать общей структуре. Сами баги должны быть расставлены по степени серьезности и приоритетности и обсуждаться с командой.
Но почему так важно иметь единый подход к жизненному циклу багу? Можно отметить следующие преимущества:
Улучшение коммуникации между тестировщиками и разработчиками
Простое отслеживание проблем и управление ими (выгодно как для внутренней команды, так и для клиентов)
Лучшая видимость общего качества продукта
Удобное использование в отчетах и метриках
Подводя итог: в проекте важно иметь общий рабочий процесс по устранению ошибок. Это экономит массу времени и позволяет команде более эффективно решать проблемы. В то же время подход может меняться по мере развития проекта, поэтому также требуется постоянный пересмотр и анализ подходов к решению проблем. Все это может показаться немного сложным и время затратным, но, в конечном счете, четкий жизненный цикл ошибки значительно облегчает жизнь каждого члена команды.
