Вы уже знаете, что тестирование — это не просто случайный клик по кнопкам, а важный процесс, который помогает находить проблемы до того, как они дойдут до пользователя. В предыдущей теме вы узнали, зачем нужно регрессионное тестирование: чтобы убедиться, что исправление одной ошибки не сломало что-то другое.
Теперь, когда вы умеете искать такие проблемы, важно понимать: что происходит с ошибкой после того, как вы её нашли?
Что такое дефект?
Когда в интерфейсе что-то работает не так — например, кнопка «Оплатить» не реагирует или текст в форме обрезан — это может быть дефект.
Дефект (или баг) — это несоответствие поведения программы ожиданиям: требованиям, макетам или логике работы.
Но не каждая странность — дефект. Например, если ошибка появляется только у одного пользователя из-за устаревшего браузера, это может быть особенность окружения, а не ошибка в коде.
Ключевое правило: дефект — это когда продукт делает не то, что должен, или не делает того, что должен.
💡 Важно: дефект возникает на любом этапе — при проектировании, разработке или тестировании. Наша задача — найти его до выхода продукта.
Жизненный цикл дефекта: от обнаружения до закрытия
Нашли ошибку — и что дальше? Просто сообщить разработчику «всё сломалось» недостаточно. Нужен структурированный процесс, который позволяет отслеживать судьбу каждого дефекта.
Этот процесс называется жизненный цикл дефекта.
Он состоит из нескольких этапов, на каждом из которых участвуют разные члены команды. Давайте разберём его по шагам.
Основные статусы бага
Каждый дефект проходит через определённые статусы, которые показывают, на каком этапе находится его обработка.
Вот основные из них:
| Статус | Кто отвечает | Что происходит |
|---|---|---|
| Найден | Тестировщик | Ошибка обнаружена и зафиксирована в системе |
| Подтверждён | Аналитик / Тестировщик / Разработчик | Проверено, что это действительно дефект, а не особенность |
| Исправлен | Разработчик | Код изменён, ошибка устранена |
| Проверен | Тестировщик | Убедились, что дефект действительно исправлен |
| Закрыт | Тестировщик / Менеджер | Процесс завершён, баг больше не возвращается |
Почему подтверждение бага — важный этап?
Многие новички думают: «Нашёл — значит, баг». Но на практике не всё так просто.
Подтверждение бага — это проверка, действительно ли поведение системы является ошибкой.
Например:
- Пользователь не может зарегистрироваться, но только если вводит email без "@". Это не баг — система корректно проверяет формат.
- Кнопка не нажимается, но только при масштабе 150%. Это может быть крайний случай, но не дефект, если не поддерживается такой масштаб.
Подтверждение помогает:
- Избежать лишней работы у разработчиков
- Сфокусироваться на реальных проблемах
- Поддерживать доверие в команде
⚠️ Без подтверждения в баг-трекере накапливаются «фантомные» ошибки, которые никто не исправляет, и теряется доверие к процессу.
Практический пример: как проходит жизненный цикл
Представим, что вы тестируете форму входа.
- Найден: вы обнаружили, что при вводе корректного логина и пароля система выдаёт ошибку «Неверные данные». Вы создаёте запись в баг-трекере.
- Подтверждён: аналитик проверяет требования — да, по спецификации вход должен работать. Ошибка подтверждается.
- Исправлен: разработчик находит проблему — ошибка в логике проверки пароля. Исправляет код.
- Проверен: вы тестируете снова — вход работает. Подтверждаете, что баг устранён.
- Закрыт: статус меняется на «Закрыт». История завершена.
Если бы при проверке ошибка повторилась — статус вернулся бы к разработчику. Цикл не всегда линейный!
Почему это важно в 2025 году?
Сегодня большинство IT-команд в России работают по Agile и используют системы вроде Jira.
Там каждый баг — это задача с чёткими статусами. Умение правильно отслеживать жизненный цикл:
- Показывает вашу организованность
- Помогает команде эффективно планировать спринты
- Делает вас надёжным участником процесса
💼 На собеседованиях часто спрашивают: «Что вы делаете, когда находите баг?» Теперь вы можете чётко описать весь путь — от обнаружения до закрытия.
Что дальше?
Теперь вы понимаете, как отслеживается судьба ошибки в команде. Вы знаете, что не каждая странность — дефект, и почему важно подтверждение.
В следующей теме — эквивалентное разбиение — вы научитесь системно подходить к поиску ошибок, не тестируя всё подряд. Это техника, которая поможет находить больше багов за меньшее время, экономя усилия и повышая качество тестирования.
Готовы стать эффективнее? Следующий шаг уже ждёт.