Дефекты

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

Ошибка — это неправильное действие человека, например разработчика, аналитика или тестировщика. Дефект — это ошибка, которая попала в артефакт: код, требования, базу данных, конфигурацию. Сбой — это внешнее проявление дефекта во время работы системы. Отказ — это невозможность системы или ее части выполнять нужную функцию. Пример: Разработчик неправильно написал условие в коде — это ошибка. Из-за этого в системе появилась неправильная логика — это дефект. Пользователь нажал кнопку и получил 500 — это сбой. Если после этого оплата вообще не работает — это уже отказ функции.

Жизненный цикл дефекта — это набор состояний, через которые проходит баг от момента обнаружения до закрытия. Типичный жизненный цикл: New — дефект зарегистрирован. Open — дефект принят в работу. In Progress — разработчик исправляет. Fixed — исправление внесено. Retest — тестировщик повторно проверяет. Closed — дефект подтвержден и закрыт. Дополнительно могут быть статусы: Rejected — дефект не подтвержден. Deferred — исправление отложено. Duplicate — дубликат существующего бага. Reopened — дефект открыт повторно. Пример: Тестировщик завел баг. Разработчик исправил. Тестировщик проверил на новой сборке. Если проблема ушла — баг закрывается. Если проблема осталась — баг переоткрывается.

Хороший баг-репорт должен содержать всю информацию, которая нужна для понимания, воспроизведения и исправления дефекта. Обычно баг-репорт включает: Заголовок. Предусловия. Шаги воспроизведения. Ожидаемый результат. Фактический результат. Окружение. Severity. Priority. Вложения: скриншоты, видео, логи, запросы. Пример структуры: Заголовок: Ошибка 500 при входе с валидными учетными данными. Шаги: 1. Открыть страницу логина. 2. Ввести корректный email и пароль. 3. Нажать кнопку "Войти". Ожидаемый результат: пользователь авторизован. Фактический результат: отображается ошибка 500.

Заголовок должен быть коротким, точным и отражать суть проблемы. Хороший заголовок обычно включает: Что сломано. При каком действии. Иногда — при каком условии. Плохо: Логин не работает. Хорошо: Ошибка 500 при входе с валидными учетными данными. Не сохраняется заказ при выборе способа оплаты картой. Не отображается кнопка "Оплатить" для роли администратора. Хороший заголовок должен помочь быстро понять проблему, не открывая весь баг.

Severity показывает, насколько серьезен дефект с точки зрения влияния на систему. Priority показывает, насколько срочно нужно исправить дефект с точки зрения бизнеса и планирования. Severity отвечает на вопрос: Насколько сильно сломано? Priority отвечает на вопрос: Насколько срочно чинить? Пример: Опечатка на главной странице может иметь низкую severity, но высокий priority, если страницу увидят все пользователи. Ошибка в редкой административной функции может иметь высокую severity, но средний priority, если она почти не используется.

Шаги должны быть: Четкими. Последовательными. Воспроизводимыми. Без лишней информации. Важно писать только те действия, которые реально нужны, чтобы получить дефект. Плохо: Зайти в систему и что-то сделать, после этого ошибка. Хорошо: 1. Открыть страницу логина. 2. Ввести email test@test.com. 3. Ввести пароль 123456. 4. Нажать кнопку "Войти". Такой формат позволяет другому человеку быстро повторить сценарий.

Локализация дефекта — это процесс определения места и условий возникновения проблемы. Цель локализации — понять: На каком уровне находится проблема. Когда именно она возникает. Какие данные и условия ее вызывают. Тестировщик проверяет: Проявляется ли баг на других данных. Проявляется ли баг на другом окружении. Есть ли ошибка в UI, API, БД, логах. Пример: Кнопка "Сохранить" ничего не делает. Тестировщик открывает DevTools и видит, что запрос вообще не уходит. Это помогает локализовать дефект на фронтенде, а не на бэкенде.

Для локализации используют разные инструменты в зависимости от типа системы. Основные: DevTools — для анализа фронтенда и сетевых запросов. Postman — для проверки API. СУБД и SQL-клиенты — для проверки данных в базе. Логи — для поиска ошибок на сервере и в приложении. Снифферы — для анализа трафика. Logcat и Console — для мобильных приложений. Пример: Если приложение показывает пустой список, можно: Проверить Network в DevTools. Проверить ответ API. Проверить, есть ли данные в базе. Посмотреть ошибки в логах.

Чтобы воспроизвести дефект корректно, нужно не просто повторить шаги, а выяснить устойчивость проблемы и условия ее появления. Нужно проверить: Всегда ли проявляется дефект. На каких данных он появляется. На каких устройствах, ОС или браузерах воспроизводится. Зависит ли от роли пользователя. Зависит ли от окружения. Пример: Ошибка появляется только если поле "Телефон" оставить пустым. Если поле заполнить — ошибки нет. Это значит, что условие воспроизведения связано с конкретной валидацией.

Валидация дефекта — это проверка, действительно ли проблема существует, воспроизводится и соответствует критериям дефекта. Тестировщик проверяет: Баг реально есть. Это не проблема окружения. Это не ожидаемое поведение. Баг не является дубликатом. Пример: Если пользователь жалуется, что кнопка серая, тестировщик должен проверить: возможно, кнопка по требованиям неактивна до заполнения обязательных полей. Тогда это не дефект.

После исправления нужно провести retest — повторно выполнить шаги и убедиться, что проблема устранена. Важно проверить: Исправлен ли конкретный дефект. Не появилось ли новых ошибок рядом. Не сломалась ли связанная функциональность. Пример: Исправили баг с логином. Нужно проверить: Вход с валидными данными. Ошибка при неверном пароле. Поведение пустых полей. Работу remember me, если она связана с логином.

Duplicate — это баг, который уже был зарегистрирован ранее. Rejected — это баг, который не признан дефектом. Причины могут быть разные: не воспроизводится, соответствует требованиям, ошибка окружения. Reopened — это баг, который был исправлен и закрыт, но потом проблема проявилась снова. Пример: Тестировщик завел баг, а потом нашел уже существующий такой же — новый баг будет duplicate. Если разработчик говорит, что поведение соответствует требованиям, и это подтверждается аналитиком — баг может стать rejected. Если после фикса проблема осталась — баг reopened.

Анализ причин нужен для того, чтобы не просто исправить баг, а понять, почему он появился. Нужно выяснить: На каком этапе возникла ошибка. Это проблема требований, логики, разработки, интеграции или окружения. Почему дефект не был найден раньше. Пример: Ошибка в расчете скидки может быть вызвана: Неполным требованием. Неправильным условием в коде. Неверными тестовыми данными. Отсутствием теста на граничный случай. Такой анализ помогает улучшить процесс, а не только закрыть конкретный баг.

Один дефект может затрагивать не только конкретную функцию, но и другие части системы. Он может влиять на: Фронтенд. Бэкенд. Базу данных. Интеграции. Поддержку. Бизнес-процессы. Пример: Если API возвращает неверный формат JSON, фронтенд может перестать отображать данные. То есть дефект находится в API, но проявляется в пользовательском интерфейсе.

Продакшн-дефект — это ошибка, которая попала в боевую среду и проявилась у реальных пользователей. При анализе продакшн-дефекта нужно понять: Что произошло. На кого это повлияло. Почему ошибка не была обнаружена раньше. Какие проверки нужно добавить, чтобы не допустить повторения. Пример: Пользователи не могут оплатить заказ на проде. После анализа выяснилось, что не был покрыт кейс с пустым значением одного поля от внешнего сервиса. Вывод: нужно добавить негативный интеграционный тест.

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

В сложной системе дефект может проявляться в одном месте, а причина быть в другом сервисе. Нужно: Проверить цепочку вызовов. Посмотреть логи нескольких сервисов. Использовать Trace ID, Request ID. Проверить очереди, интеграции и тайминги. Сравнить данные на разных этапах. Пример: Пользователь не получил уведомление. Нужно проверить: Создалось ли событие. Ушло ли оно в брокер. Принял ли его сервис уведомлений. Есть ли ошибка в логах. Отправилось ли письмо или push.