В уроках 6.4–6.6 мы разобрали содержание баг-репорта: шаги воспроизведения, ожидаемый и фактический результат, severity и priority, статус в жизненном цикле бага. Всё это — содержание. Но где оно физически хранится и как выглядит на практике? В реальной работе баг не пишут в отдельный файл или письмо коллеге — его заводят в баг-трекере: Jira, YouTrack, Redmine и похожих системах. Разберём, из каких полей состоит карточка бага в трекере и как она движется по статусам от находки до закрытия.
Чему научишься за этот урок:
— находить в карточке бага трекера поля, которые вы уже умеете заполнять (описание, severity, priority, статус);
— различать assignee и reporter — кто нашёл баг и кто его чинит;
— проводить баг по рабочему процессу: завести → назначить → отслеживать статус → комментировать → перепроверить после Fixed → закрыть или вернуть в работу.
Из чего состоит карточка бага в трекере
Карточка бага в трекере — это форма с фиксированным набором полей. Часть из них вы уже умеете заполнять по прошлым урокам, часть — специфична именно для трекера.
- Заголовок (summary) — короткая суть проблемы одной строкой, по которой баг узнают в общем списке.
- Описание (description) — шаги воспроизведения, ожидаемый и фактический результат (глава про баг-репорт, урок 6.4).
- Reporter — кто обнаружил и завёл баг (обычно тестировщик).
- Assignee — кто должен исправить баг (обычно разработчик конкретного модуля).
- Severity и Priority — насколько тяжело и насколько срочно (урок 6.6).
- Статус — текущее положение в жизненном цикле бага (урок 6.6), только теперь это колонка на доске трекера.
- Вложения (attachments) — скриншоты, видео, логи, подтверждающие дефект.
- Комментарии — обсуждение по ходу работы: уточнения, вопросы, причина отклонения.
- Связанные задачи (linked issues) — ссылки на другие баги или задачи, логически связанные с этим.
Рабочий процесс: как баг движется по статусам
Жизненный цикл бага из урока 6.6 в трекере выглядит не абстрактной схемой, а канбан-доской со столбцами. Баг физически перемещается между столбцами, когда меняется его статус.
+-------+ +-------------+ +-------+ +--------+ +--------+
| New | --> | In Progress | --> | Fixed | --> | Retest | --> | Closed |
+-------+ +-------------+ +-------+ +--------+ +--------+
^ |
|______ retest не подтвердил _________|
Порядок обычно такой: 1) тестировщик заводит баг со статусом New и заполняет reporter, описание, severity/priority; 2) руководитель или сам разработчик берёт баг в работу — статус меняется на In Progress, появляется assignee; 3) разработчик исправляет код и переводит статус в Fixed; 4) тестировщик перепроверяет исправление — это называется retest, статус на это время — Retest; 5) если дефект больше не воспроизводится — статус Closed; если воспроизводится — баг возвращается в In Progress с комментарием, что именно не исправилось. Комментарии оставляют на любом шаге, если нужно уточнение, — они не меняют статус сами по себе.
Пример: заводим баг в трекере
Возьмём дефект на полигоне: промокод STUDENT20 должен применяться один раз на аккаунт, но при повторном вводе скидка срабатывает снова.
- Заголовок: «Промокод STUDENT20 применяется повторно к тому же аккаунту, хотя должен работать один раз»
- Описание: Шаги — 1) войти под аккаунтом, где STUDENT20 уже был применён ранее; 2) перейти к оплате курса; 3) ввести STUDENT20 повторно и нажать «Применить». Ожидаемый результат — система отклоняет промокод с сообщением «промокод уже использован». Фактический результат — скидка 20% применяется второй раз.
- Reporter: тестировщик, который нашёл дефект
- Assignee: пока не назначен — статус New
- Severity: Major — прямые финансовые потери от повторной скидки, но продукт в целом работает
- Priority: High — влияет на выручку, чинить нужно в текущем спринте
- Статус: New
- Вложения: скриншот суммы к оплате до и после повторного ввода промокода
- Связанные задачи: пока нет — это первый найденный баг по этой логике
Итог:
— карточка бага в трекере — это те же поля, что вы освоили в 6.4–6.6, плюс reporter, assignee, вложения и связанные задачи;
— reporter нашёл баг, assignee его чинит — не путайте роли;
— рабочий процесс — это движение по столбцам доски: New → In Progress → Fixed → Retest → Closed, с возможным возвратом в In Progress, если retest не подтвердил исправление.
Контрольный вопрос. Что означает поле reporter в карточке бага?
Подсказка: Подумай, какая роль связана с началом истории бага, а какая — с его исправлением.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что означает поле assignee в карточке бага?
Подсказка: Это про финал истории — кто чинит, а не кто заметил.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие поля карточки бага вы уже встречали в предыдущих уроках, до знакомства с самим трекером (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Сопоставь поля с главами: 6.4 — содержание баг-репорта, 6.6 — severity/priority и статус.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется поле в трекере, которое хранит имя человека, обнаружившего и завёдшего баг? Ответь одним словом на английском, как оно называется в интерфейсе трекера.
Подсказка: Ищи в списке полей этого урока — там же, где объясняется, кто нашёл баг, а кто его чинит.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется поле в трекере, которое хранит имя человека, назначенного исправить баг? Ответь одним словом на английском.
Подсказка: Это поле — противоположность reporter: не тот, кто нашёл, а тот, на кого назначена работа.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Тестировщик только что завёл баг в трекере, разработчик ещё не взял его в работу. Какой статус у бага на канбан-доске?
Подсказка: Это самый первый столбец на доске, до начала любой работы.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Разработчик закончил исправлять код по багу. В какой статус (согласно схеме этого урока) переходит баг перед тем, как тестировщик проверит исправление? Ответь одним словом, как в диаграмме.
Подсказка: Смотри на схему: это статус сразу после In Progress, до Retest.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик в статусе Retest обнаружил, что дефект по-прежнему воспроизводится. В какой из пяти статусов схемы должен вернуться баг?
Подсказка: Посмотри на стрелку от Retest, которая идёт не вперёд, а назад — куда она возвращается?
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Для чего в карточке бага нужны комментарии?
Подсказка: Комментарии оставляют по ходу работы, они не меняют состояние карточки сами по себе.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. К багу привязана связанная задача (linked issue) — доработка в другом модуле, которая на него влияет. Зачем нужна такая связь?
Подсказка: Речь про связь между несколькими задачами или багами, а не про замену другого поля.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На полигоне на экране записи на курс есть требование: «При достижении лимита группы в 20 человек кнопка «Записаться» должна становиться неактивной и показывать текст «Мест нет»». При тестировании 20-й участник записался успешно (кнопка была активна), но 21-й тоже смог записаться — кнопка оставалась активной, и группа стала 21 человек. Опиши текстом, как будто заполняешь карточку этого бага в трекере: заголовок, краткое описание (шаги воспроизведения, ожидаемый и фактический результат), severity, priority, стартовый статус.
Критерий приёмки: указаны все пять элементов — заголовок в одну строку по сути проблемы; шаги воспроизведения с ожидаемым результатом (кнопка неактивна и запись невозможна на 21-м участнике) и фактическим (кнопка активна, запись прошла); severity обоснованно Major или Critical (лимит группы нарушен — функциональный сбой); priority обоснованно High (влияет на корректность данных о группе); стартовый статус — New.
Подсказка: Пройдись по всем полям из раздела «Из чего состоит карточка бага» по порядку: заголовок → описание → severity/priority → статус. Assignee и reporter указывать не обязательно — вопрос про заведение бага впервые.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Трекер хранит баги. Но где хранятся сами тест-кейсы и чек-листы, которые вы писали раньше, — и что делать, если найденная проблема на самом деле не баг? Об этом — последний урок главы.
