Жизненный цикл бага

Тема 1.9. ЖЦ Бага

Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла.

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

ЖЦ Бага - цикл обработки дефекта (бага), с присвоением ему различных статусов после выполнения различных действий - начиная с регистрации нового бага в системе и до закрытия после устранения.

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

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

Статусы багов и их значение

Основные статусы:

- Новый (New), Обнаружен (submitted) - начальное состояние, в котором он находится сразу после создания.

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

Далее его статус меняется на Отказ (Rejected) или на Назначен (Assigned).

- Назначен, на рассмотрении (Assigned, Open) - дефект просмотрен и открыт (то есть признан для исправления, проверен (например, тимлидом или старшим тестировщиком)) и подтверждён как валидный.

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

Процесс назначения и анализа новых багов часто называется Баг-триаж (Bug Triage). Это может быть регулярная встреча команды, где решают, что делать с каждым новым багом: брать в работу, отклонить или отложить.

- В работе (In Progress) - Разработчик приступил к анализу и исправлению дефекта. Этот статус помогает команде понимать, что именно сейчас делается с задачей.

-Решен, Исправлен, Устранен (Fixed, Resolved) - дефект исправили, разработчик завершил работу и загрузил исправление в ту версию продукта, где будет проверяться дефект. В этом состоянии дефект требует перепроверки тестировщиком.

В это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.

В современных реалиях (при использовании CI/CD — Continuous Integration/Continuous Delivery) статус «Fixed» часто означает, что код не просто написан, но и успешно прошел автоматические сборки и тесты (например, модульные тесты разработчика). Только после этого он передается тестировщику.

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

После проверки ошибки тестировщиком, дефект переводится в состояния:

+ Переоткрыт (Re-opened) - если дефект не исправлен или исправлен не полностью). Тестировщик проверил исправление и обнаружил, что дефект устранён не полностью или появились новые связанные ошибки. Дефект возвращается разработчику для доработки.

+ Закрыт (Closed), если ошибка исправлена. Финальный статус. Тестировщик подтвердил, что дефект устранён, и продукт работает корректно. По дефекту больше не планируется никаких действий.

Альтернативные статусы

Дефект может пойти по альтернативному пути с самого начала или на любом из этапов:

1. Отказ, отклонен (Rejected, Declined) - пишется комментарий программиста или менеджера о причине reject-a (отклонения).

Это может быть:

- Дубликат (Duplicate), ошибка уже зарегистрирована в системе, некачественное описание дефекта, невозможность воспроизвести дефект. -Также это может произойти потому что для заказчика какие-то ошибки перестали быть актуальными.

- Не воспроизводится (Can Not Reproduce): Разработчик не смог воспроизвести проблему по предоставленным шагам.

- "Не ошибка" (Not a Bug): Поведение системы соответствует требованиям или является особенностью, а не дефектом.

- Некорректный отчёт (Invalid): Отчёт составлен с ошибками, неполный или непонятный.

- Проблема среды (Environment Issue): Баг воспроизводится только на машине тестировщика из-за особенностей конфигурации (например, локальный кэш) и не является проблемой кода.

 После этого, тестировщик или закрывает дефект (Closed), или дополняет комментарии данного дефекта и переводит дефект заново в состояние Назначен (Assigned).

2. Отложен (deferred, Postponed) - в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что в обозримом будущем ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по необходимой технологии, изменятся требования заказчика и т.д.)

Статус «Отложен» — это формализованный технический долг (Technical Debt).

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

Примеры: выйдет новая версия библиотеки, вернётся из отпуска специалист по необходимой технологии, изменятся требования заказчика.

Баг может вернуться в работу, если эти условия наступят или если без его исправления станет невозможно двигаться дальше.

Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах.

Данную схему можно изобразить в текстовом виде.

3. Рекомендован к отклонению (to be declined) - в это состояние отчёт о дефекте может быть переведён из множества других состояний, чтобы вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине.

Этот статус инициирует процесс коллегиального решения и снижает риск конфликта между тестировщиком и разработчиком. Если рекомендация является обоснованной, то отчёт переводится в состояние «Отклонён».

Классические схемы жизненного цикла багов

Данные схемы можно изобразить в текстовом виде. В скобках указано, кто обычно инициирует переход.

Варианты прохождения багов:

1. Сценарий отклонения: Новый (New) [Тестировщик] --> Отклонен (Rejected) [Разработчик/Тимлид] --> Закрыт (Closed) [Тестировщик]

                   Пример: Тестировщик принял за баг особенность системы, описанную в требованиях. Разработчик отметил статусом "Not a Bug", и баг был закрыт.

2. Идеальный сценарий (Простой баг): Новый (New) [Тестировщик] --> Назначен (Assigned) [Тимлид/Система] --> Решен (Fixed) [Разработчик] --> Проверка (Verification) [Система] --> Закрыт (Closed) [Тестировщик]

3. Полный идеальный сценарий: Новый (New) [Тестировщик] → На рассмотрении (Assigned) [Тимлид] → В работе (In Progress) [Разработчик] → Исправлен (Fixed) [Разработчик] → Проверка (Pending Verification) [Разработчик/Система] → Закрыт (Closed) [Тестировщик]

                   Пример: Баг был корректно описан, разработчик быстро его нашёл и исправил, тестировщик с первой попытки подтвердил исправление.

4. Сценарий с итерациями (Неудачное исправление):Новый (New) → Назначен (Assigned) → В работе (In Progress) → Исправлен (Fixed) → Переоткрыт (Reopened) [Тестировщик] → В работе (In Progress) → Исправлен (Fixed) → Закрыт (Closed)

                   Пример: Разработчик не до конца понял проблему и исправил только часть. Тестировщик вернул баг на доработку. После второго исправления баг был закрыт.

5. Новый (New) → Отложен (Deferred) [Менеджер/Тимлид] → (через время) → На рассмотрении (Assigned) [Тимлид] → ... → Закрыт (Closed)

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

ЖЦ Бага - со стороны команды

Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.

Сценарий 1, в котором разработчик принял баг. Перед ним сразу встает задача пофиксить его, то есть исправить и залить (отдать заново на проверку). Как только разработчик все сделал, баг снова отправляется к тестировщику, который производит тестирование исправлений, а также проверяет смежные участки (регрессионное тестирование).

Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).

Шаг 1: Обнаружение и регистрация

Действие: Тестировщик находит дефект, локализует его и создаёт чёткий, воспроизводимый баг-репорт в системе (Jira, etc.).

Статус бага: New (Новый).

Шаг 2: Анализ и принятие в работу

Действие: Разработчик изучает отчёт. Он понимает проблему, признаёт её дефектом и берёт её в работу.

Статус бага: Open / Assigned (Открыт / Назначен) -> In Progress (В работе).

Шаг 3: Исправление

Действие: Разработчик пишет код, устраняющий причину дефекта, и предоставляет исправление для проверки (например, делает коммит в нужную ветку).

Статус бага: Fixed / Resolved (Исправлен / Решён).

Шаг 4: Проверка исправления и регрессионное тестирование

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

Статус бага: Pending Verification (На проверке).

Шаг 5: Завершение

Действие: Поскольку баг исправлен и регрессия не выявила проблем, тестировщик закрывает дефект.

Статус бага: Closed (Закрыт).

Сценарий 2 - Баг не исправлен с первого раза. Этот сценарий отражает реальность, когда для полного исправления требуется несколько итераций.

Шаги 1-4: Проходят так же, как в первом сценарии.

Шаг 5 (альтернативный): При проверке тестировщик обнаруживает, что баг:

- Воспроизводится снова (исправление не сработало).

- Исправлен частично (проблема осталась, но в другом виде).

- Исправление вызвало новый дефект.

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

Статус бага: Reopened (Переоткрыт).

Далее: Цикл Шаги 2 -> 3 -> 4 повторяется до тех пор, пока баг не будет исправлен окончательно.

Если цикл «Fixed -> Reopened» повторяется многократно, это сигнал для команды. Возможно, разработчик не понимает требования, тестировщик плохо их описывает, или сама проблема очень сложна и требует совместной сессии (парное тестирование/программирование).

Сценарий 3: Разработчик не принимает баг

Это критически важная часть цикла, где требуется эффективная коммуникация.

Шаг 2 (альтернативный): Разработчик, изучив отчёт, решает его отклонить.

Статус бага: Rejected (Отклонён).

Возможные причины и действия тестировщика:

- "Некорректное описание - "Улучшить баг-репорт: дополнить шаги, добавить скриншоты/логи, уточнить ожидаемый и фактический результат.

- "Не воспроизводится - "Проверить среду и шаги: убедиться, что все шаги точны; попробовать воспроизвести на другой машине/среде; предоставить больше данных (логи, видео).

- "Это не баг, а фича" / "Работает как задумано« - Свериться с требованиями: если ПМ/аналитик подтверждает, что поведение корректно - закрыть баг. Если нет - привести ссылку на требование и переоткрыть

- "Дубликат - "Проверить существующие баги: если баг действительно уже есть, присвоить своему отчёту статус "Дубликат" и указать ссылку на основной баг.

Результат действий тестировщика:

- Если уточнений достаточно: баг переводится обратно в статус Open/Assigned (шаг 2 основного сценария).

- Если решение об отклонении обоснованно: баг закрывается (Closed).

Правила формирования отчета об ошибке:?

Чтобы избежать статуса Rejected из-за Invalid или недопонимания, отчет о дефекте должен содержать:

1.         Заголовок (Summary): Краткий, но ёмкий. Формула: «Где? + Что? + При каких условиях?». Плохо: «На странице всё криво». Хорошо: «На главной странице при клике на кнопку "Войти" ничего не происходит, если поле "Логин" пустое».

2.         Шаги воспроизведения (Steps to Reproduce): Атомарные шаги (одно действие на шаг), которые приводят к проблеме.

3.         Фактический результат (Actual Result): Что произошло на самом деле (ошибка, зависание, не тот текст).

4.         Ожидаемый результат (Expected Result): Что должно было произойти (со ссылкой на требования, если есть).

5.         Окружение (Environment): Версия ПО, ОС, браузер, разрешение экрана, мобильное устройство и т.д.

6.         Вложения (Attachments): Скриншот (с выделением проблемы), видео, лог ошибки (stack trace). Это самая важная часть для разработчика.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1.         Что такое жизненный цикл бага (дефекта)?

2.         Почему схемы жизненного цикла бага могут отличаться в разных компаниях?

3.         Назовите ключевого участника процесса, который обычно обнаруживает и регистрирует новый баг.

4.         Кто чаще всего принимает решение о принятии бага в работу или его отклонении?

5. Какой статус присваивается багу в момент его первоначального создания?

6. Что означает статус «Assigned» (Назначен) и каковы возможные способы назначения ответственного?

7. Какой статус указывает на то, что разработчик начал работу над исправлением дефекта?

8. Чем статус «Fixed» (Исправлен) отличается от статуса «Closed» (Закрыт)?

9. Какой статус используется, чтобы показать, что исправление готово для проверки тестировщиком?

10. В каком случае баг переводится в статус «Reopened» (Переоткрыт)?

11. Чем принципиально отличаются статусы «Rejected» (Отклонен) и «Deferred» (Отложен)?

12. Какой статус является промежуточным перед окончательным отклонением бага и для чего он нужен?

13. Назовите три основные причины, по которым разработчик может отклонить баг (Rejected).

14. В какой ситуации баг может быть отложен (Deferred)? Приведите пример.

15. Что должен сделать тестировщик, если получил баг со статусом «Rejected» и комментарием «Can Not Reproduce»?

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

17. Опишите сценарий, в котором баг требует нескольких циклов исправления и проверки.

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

19. Кто является арбитром в спорной ситуации, когда тестировщик и разработчик по-разному интерпретируют требование к функционалу?

20. Чья ответственность - перевести баг в статус «Fixed»?

21. Чья ответственность - перевести баг в статус «Closed»?

22. Кто инициирует перевод бага в статус «Pending Verification»?

23. Если причина бага кроется в конфигурации сервера, а не в коде приложения, кто должен быть назначен исполнителем?

24. Почему эффективная коммуникация между тестировщиком и разработчиком критически важна на этапе анализа бага?

25. Какие действия должен предпринять тестировщик, чтобы повысить шансы на принятие бага после его отклонения из-за «Некорректного описания»?

26. Что, помимо комментария, разработчик должен предоставить тестировщику при переводе бага в статус «Resolved», чтобы облегчить проверку?

27. Как команде следует поступить, если исправление одного бага привело к появлению нового дефекта в смежном функционале?

28. Какой статус следует использовать тестировщику, если он физически не успевает проверить все полученные исправления перед релизом?

29. Нужно ли переоткрывать старый баг, если ошибка внезапно снова проявилась на продакшене спустя несколько месяцев после исправления? Обоснуйте ответ.

30. Какие действия должна предпринять команда (тимлид, разработчик, тестировщик), чтобы разорвать цикл «Fixed -> Reopened», повторяющийся несколько раз?

ЗАДАНИЯ ПО ЛЕКЦИИ:

Задание 1: "Спорный функционал"

·            Сценарий: Тестировщик Александр завёл баг: "Кнопка 'Отправить' не меняет цвет при наведении курсора". Разработчик Марк отклонил баг с резолюцией Not a Bug, аргументировав, что дизайн-система не предусматривает такого поведения. Александр не согласен.

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

Задание 2: "Неуловимая ошибка"

·            Сценарий: Ольга (тестировщик) обнаружила, что при определённых условиях данные в отчёте формируются некорректно. Она завела подробный баг, приложила скриншоты. Разработчик Петр несколько раз пытался воспроизвести ошибку по инструкции, но у него не вышло. Баг вернулся со статусом Rejected и комментарием Can Not Reproduce.

·            Вопрос: Что должна сделать Ольга, прежде чем согласиться с закрытием бага? Составьте пошаговый план её действий для подтверждения дефекта.

Задание 3: "Эффект домино"

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

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

Задание 4: "Приоритеты проекта"

·            Вопрос: Объясните, чем принципиально отличается статус Deferred от статуса Rejected с точки зрения перспектив дефекта и коммуникации с заказчиком/менеджером. В каком случае баг, помеченный как Deferred, может снова стать актуальным?

Задание 5: "Недосказанность"

·            Сценарий: Тестировщик Кирилл написал в баг-репорте: "На странице 'Профиль' всё криво". Разработчик Анна отклонила баг с резолюцией Invalid.

·            Вопрос: В чём именно заключается профессиональная ошибка Кирилла? Какие конкретно разделы баг-репорта он не заполнил или заполнил неправильно? Что он должен сделать, чтобы исправить ситуацию?

Задание 6: "Двойник"

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

·            Вопрос: Каковы должны быть правильные действия Марии? Какой статус и, что важно, какой комментарий она должна проставить своему багу?

Задание 7: "Долгоиграющий баг"

·            Сценарий: В проекте есть баг "Падение производительности при работе с большими объёмами данных". Он находится в статусе Deferred уже 6 месяцев.

·            Вопрос: Опишите гипотетическую ситуацию (сценарий), при которой этот баг будет переведён обратно в работу (Assigned). Какие события в проекте или компании могут этому поспособствовать?

Задание 8: "Цикл без конца"

·            Сценарий: Баг "Ошибка 500 при отправке сообщения" проходит один и тот же цикл в третий раз: Assigned -> In Progress -> Fixed -> Reopened. Тестировщик каждый раз оставляет один и тот же комментарий: "Ошибка всё ещё воспроизводится".

·            Вопрос: В чём может быть корень проблемы? Какие действия должна предпринять команда (тестировщик, разработчик, тимлид), чтобы разорвать этот цикл?

Задание 9: "Проверка в последний момент"

·            Сценарий: Завтра релиз. Сегодня тестировщик Виктор получает на проверку 15 багов со статусом Fixed. Он физически не успевает проверить все до конца дня, но хочет, чтобы команда понимала, что работа над ними ведётся.

·            Вопрос: Какой статус (или действие в системе) лучше всего применить Виктору к этим багам, чтобы избежать путаницы и не сбрасывать метрики команды?

Задание 10: "Решение не за горами"

·            Сценарий: Разработчик Семён исправил баг и перевёл его в статус Resolved. В комментарии он написал: "Исправил. Ошибка была в методе calculate(). Заменил алгоритм расчёта. Жду проверки".

·            Вопрос: Достаточно ли этого комментария для тестировщика? Что ещё, с профессиональной точки зрения, должен был сделать Семён, чтобы облегчить и ускорить работу тестировщика?

Задание 11: "Пограничный случай"

·            Сценарий: Тестировщик Наталья обнаружила, что система позволяет сохранить номер телефона в формате "+7 900 123-45-67", хотя в требованиях чётко указан формат "+79001234567". Она завела баг. Разработчик Иван считает, что оба формата допустимы для системы, и это не ошибка.

·            Вопрос: Кто является арбитром в этой ситуации? Опишите процесс разрешения данного спора. К кому должны апеллировать Наталья и Иван?

Задание 12: "Командная коммуникация"

·            Вопрос: Объясните, почему статус To Be Declined (Рекомендован к отклонению) часто является более предпочтительным, чем немедленный переход в Rejected? Какой важный процесс в команде он инициирует?

Задание 13: "Внезапное появление"

·            Сценарий: Баг "Не работает поиск по каталогу", который был исправлен и закрыт 2 месяца назад, внезапно снова начал воспроизводиться на продакшн-окружении. При этом в последних версиях он не проявлялся.

·            Вопрос: Как правильно классифицировать эту ситуацию? Нужно ли переоткрывать старый баг или заводить новый? Обоснуйте свой ответ, учитывая, что код с момента исправления многократно менялся.

Задание 14: "Системная ошибка"

·            Сценарий: Обнаружен критический баг, причина которого, как выяснилось после анализа, кроется не в коде приложения, а в конфигурации сервера баз данных.

·            Вопрос: Как должен измениться жизненный цикл этого "бага"? Кто должен быть назначен исполнителем? Какие статусы он будет проходить, если его переназначат на системного администратора?

Задание 15: "Схема жизненного цикла"

·            Задача: Нарисуйте (опишите текстом) полную схему жизненного цикла дефекта, объединяющую все основные статусы (New, Assigned, In Progress, Fixed, Pending Verification, Reopened, Closed, Rejected, Deferred) и возможные переходы между ними. Отметьте на схеме, кто (Тестировщик, Разработчик, Менеджер) обычно инициирует каждый переход.