- Схема
- Cтатусы багов
- Другие статусы (этапы цикла)
- Действия в багтрекере
- Указания
- Ошибка, дефект, отказ
- Инвалиды и дубликаты
- Еще нюансы
- Жизненный цикл дефекта в Bugzilla (схемы)
В процессе разработки всегда возникают дефекты (баги), которые тестировщики стараются найти, а разработчики пофиксить, то есть устранить. В баг-трекинговой системе фиксируется статус дефекта, и действия участников команды. Все происходит упорядоченно (поэтапно), нередко бывают повторные этапы. Баг проходит от «рождения» (Новый) до «смерти» (Закрыт). Этот процесс называется жизненным циклом дефекта.

Дефектом называют ошибку в компьютерной программе, возникающую в процессе проектирования или написания кода программы. Ошибка заключается в некорректном поведении программы. Цель QA-команды состоит в обнаружении дефектов как можно раньше, и как можно большего количества дефектов, что повышает итоговое качество программы. Продукт без дефектов соответствует требованиям заказчика и предоставляет услуги пользователям на должном уровне.
Понятия баг и дефект, а также жизненный цикл дефекта и жизненный цикл бага в данной статье взаимозаменяемы.

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

Список статусов бага
- Новый
Первый статус в цикле, New, или Обнаружен, означает, что дефект обнаружен тестировщиком, зарегистрирован, и по нему создан баг-репорт, на основе которого разработчик потом будет искать и устранять дефект.
- Назначен
Когда новый дефект подтвержден и принят в обработку, получает статус Назначен (Assigned). Как правило назначается ответственный за устранение этого бага (поэтому статус еще может называться «Назначен НА кого-то»).
- Открыт
Open-статус означает, что дефект приняли разработчики и начали процесс устранения.
На этом этапе возможен переход в статус «Отклонен» или «Отложен», то есть разработчик может «не принять» этот дефект — отклонить или отложить.
- Устранен
Или Решен/Исправлен (Fixed, Resolved). Разработчики поработали с кодом, внесли нужные правки, пометили статусом «Исправлен», и возвращают тестировщикам для повторной проверки.
- Ожидает повторного тестирования
В статусе Pending Retest дефект ожидает, когда тестировщики повторно проверят его, убедившись что все ОК, код теперь исправлен.
- Повторно тестируется
Retest: тестировщик еще раз проверяет этот дефект, и убедившись что он устранен разработчиками, верифицирует это и закрывает дефект, а в противном случае переоткрывает.
- Повторно открыт
Если повторное тестирование не смогло устранить баг, обнаруживается снова, ему присваивается статус Reopen. Баг открывается опять и еще раз проходит по циклу.
- Проверен
Тестировщик еще раз проверяет (верифицирует) баг, повторно исправленный разработчиком, и если теперь он не проявляется, присваивается статус Verified.
- Закрыт
Разработчики и тестировщики общими усилиями нашли и устранили дефект, он больше не появляется, и можно присвоить статус Closed.
Другие статусы в баг-трекерах
- Отклонен
Разработчик отклонил этот дефект, присвоив статус Rejected, потому что дефект или является дубликатом (уже внесен в систему кем-то из коллег), дефект не воспроизводится, или вообще не считается дефектом.
- Отложен
Некоторые дефекты могут счесть не очень важными, не приоритетными, следовательно их можно отложить на потом и устранить в следующих релизах, присвоив статус Deferred и исключив из цикла сейчас.
- Дубликат
Этот дефект уже зарегистрирован другим тестировщиком, или суть дефекта та же, тогда присваивается статус Duplicate.
- Не дефект
Баг может и есть, но ни на что не влияет, ни в чем не ухудшает функциональность и юзабельность — отмечается статусом Not a Defect.
- Не воспроизводится
По какой-то причине баг не удалось воспроизвести, будь то проблемы с платформой, окружением, тестовыми данными, порядком действий и т.п. Присвоен статус Non Reproducible.
- Невозможно устранить
Бывают ситуации, когда баг устранить невозможно по какой-то причине: недостатки технологии, стоимость, нехватка времени, недостаточная квалификация или просто лень. Он переводится в статус Can’t be fixed.
- Требует уточнения
Статус Need more information по сути близок к «Не воспроизводится» выше, но с нюансами. Такой статус присваивается, когда разработчики не сумели воспроизвести баг по шагам, предоставленным тестировщиком, или если тестировщик составил не очень подробный репорт.
Подробнее о действиях в баг-трекере
В словесной форме (и в других баг-трекерах кроме Jira) это выглядит примерно так:
- Дефект обнаруживается тестировщиком.
- Тестировщик присваивает ему статус «Новый».
- О новом дефекте тотчас узнает проджект-менеджер, который исследует ситуацию — является ли дефект действительно дефектом, стОит ли устранять сейчас и пр.
- Если нет, дефекту присваивается статус «Отклонен».
- Если дефект действительно существует, и стОит внимания сейчас, проджект-менеджер проверяет, является ли дефект дубликатом и если да, обозначается как дубликат.
- Если не дубликат, дефект передается в работу разработчику, который начинает действия по устранению проблемы, с присвоением статуса «In Progress», и по завершению — «Исправлен».
- Далее дефект возвращается в зону ответственности тестировщика под статусом «Повторно тестируется». Тестировщик снова запускает тест-кейсы, и если дефект опять проявляется, повторно открывает его и возвращает разработчику.
- А если все хорошо, дефект закрывается, с присвоением соответствующего статуса «Закрыт».
Указания по эффективности жизненного цикла
- Важно, чтобы все команды, участвующие в проекте, понимали этапы жизненного цикла и свою ответственность на этапах
- Это позволит избежать недопонимания и «сваливания ответственности»
- От тестировщиков особо требуется четкое и понятное описание сути дефекта, и почему присвоен тот или иной статус
- От разработчиков требуется оперативнее устранять дефекты, не откладывая «на потом»
Ошибка, дефект (баг) и отказ в контексте жизненного цикла дефекта
- Ошибка (error) — например когда разработчик видит отличие между тем как приложение себя ведет и тем как должно себя вести, в процессе разработки
- Дефект (баг) — случается когда тестировщик обнаруживает несоответствие между реальным и предполагаемым поведением приложения в процессе тестирования
- Отказ (failure) — несоответствие реального и предполагаемого поведения обнаруживается уже в процессе пользования приложением конечным пользователем, клиентом, или тестировщиком на этапе приемочного тестирования.
Инвалиды и дубликаты
- Имеются в виду «невалидные» дефекты в баг-репортах, то есть те которые возникают не из-за ошибок в коде, допущенных разработчиком, а из-за некорректно работающего тестового окружения, или просто по ошибке в процессах тестирования; такой дефект считается «не валидным», не подтвержденным, поэтому отклоняется
- Дубликат дефекта возникает, когда по этой проблеме уже открыт/заведен как минимум один дефект; дубликат закрывается
- Над процессами в жизненном цикле дефекта надзирает тест-менеджер/старший тестировщик/лид/проджект-менеджер, в зависимости от того как в команде выстроены процессы. Присвоение статусов в конечном счете решается ими, на основе стоимости, времени и усилий, нужных на устранение дефекта
- Также ими решается вопрос, какие присвоить приоритет и серьезность
Что еще нужно помнить о жизненном цикле багов
- Дефекты могут возникать на любом этапе разработки и тестирования
- Чем раньше дефект обнаружен и устранен, тем лучше (выгоднее для компании)
- В идеале — на том же этапе, когда дефект найден (тогда «стоимость дефекта» минимальная)
- Статическое тестирование (анализ кода без выполнения), проводимое на раннем этапе разработки, выгоднее чем дебаг на позднем
Жизненный цикл дефекта в Bugzilla (в принципе релевантно для любого багтрекера)

Сложнее, но с объяснениями:

***