Какие основные правила заведения дефекта

Основные правила заведения дефектов (баг-репортов)

Создание качественного дефекта (баг-репорта) — это фундаментальный навык QA-инженера. Хороший отчет должен быть четким, воспроизводимым, информативным и мотивирующим к исправлению. Основные правила можно разделить на несколько ключевых категорий.

1. Уникальность и отсутствие дубликатов

Перед созданием нового отчета необходимо проверить существующую базу дефектов (например, в Jira, Bugzilla, Youtrack). Используйте поиск по ключевым словам, шагам или симптомам. Создание дубликата ведет к пустой трате времени разработчиков и тестировщиков, размывает статистику и может снизить приоритет реальной проблемы.

2. Структура и полнота информации

Каждый баг-репорт должен содержать обязательные и логически структурированные поля. Стандартный шаблон включает:

• Заголовок (Summary/Title): Краткое, но информативное описание проблемы. Должен быть понятен без чтения всего отчета. Используйте формулу [Где?] [Что?] [При каких условиях?].

    *   Плохо: "Кнопка не работает".
    *   Хорошо: "Кнопка 'Отправить' на форме обратной связи неактивна после ввода некорректного email".

• Описание (Description): Детальное изложение проблемы.
• Шаги воспроизведения (Steps to Reproduce): Четкая, пронумерованная последовательность действий, ведущая к ошибке. Должна быть настолько точной, чтобы любой член команды (включая разработчика) мог воспроизвести проблему с нуля.

  1. Перейти на страницу 'https://example.com/login'.
  2. В поле 'Логин' ввести 'testuser@mail.com'.
  3. В поле 'Пароль' ввести '12345'.
  4. Нажать кнопку 'Войти'.
  5. Обратить внимание на сообщение об ошибке.
  

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

    > **Пример:** "Появляется всплывающее окно с текстом 'Internal Server Error 500'. Пользователь остается на странице логина".

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

    > **Пример:** "Пользователь успешно аутентифицируется и перенаправляется на личную панель управления (dashboard)".

• Дополнительная информация (Environment, Attachments):

    *   **Окружение (Environment):** Укажите точные версии ПО: браузер (Chrome 121.0), ОС (Windows 11 22H2), версия приложения (v2.5.1), тип устройства (iPhone 14, iOS 17.3).
    *   **Вложения (Attachments):** Скриншоты, видео записи экрана (screen recording), логи (консоли браузера, серверные логи), файлы дампов или любые другие артефакты, которые помогают понять контекст.

    ```javascript
    // Пример ошибки из консоли браузера, которую стоит приложить
    Uncaught TypeError: Cannot read properties of undefined (reading 'name')
        at onSubmit (form-controller.js:45)
    ```

3. Объективность и ясность изложения

Избегайте эмоциональных и субъективных оценок ("Это ужасный баг!", "Кривая кнопка"). Используйте нейтральный, технический язык. Фокусируйтесь на фактах и наблюдаемом поведении системы, а не на предположениях о причинах. Если есть догадка о корне проблемы, добавьте ее в отдельное поле (например, Комментарий или Root Cause Analysis), не смешивая с фактами.

4. Определение серьезности и приоритета

• Серьезность (Severity): Объективная оценка влияния дефекта на функциональность системы. Шкалы варьируются, но часто включают:

    *   **Блокирующая (Blocker/S1):** Приложение не запускается, критическая функция полностью недоступна.
    *   **Критическая (Critical/S2):** Ключевая функция работает некорректно, есть потеря данных, проблемы с безопасностью.
    *   **Значительная (Major/S3):** Функция работает с ограничениями или ошибками, но есть обходной путь.
    *   **Незначительная (Minor/S4):** Небольшая проблема в UI, опечатка, не влияющая на основную логику.

• Приоритет (Priority): Субъективная оценка срочности исправления с точки зрения бизнеса и релизного плана (например, Высокий, Средний, Низкий). Приоритет выставляет менеджер или лид, но QA может дать рекомендацию.

5. Воспроизводимость

Старайтесь, чтобы дефект был воспроизводим стабильно (например, в 100% случаев при определенных условиях). Если баг проявляется спорадически (непостоянный/Heisenbug), это необходимо четко указать в описании ("Ошибка возникает примерно в 30% попыток") и максимально детализировать контекст: что делали до этого, состояние системы, нагрузка. Это критически важно для разработчика.

6. Один дефект — один отчет

Не объединяйте несколько независимых проблем в один отчет. Если при тестировании формы вы обнаружили, что не работает проверка email и кнопка отправки имеет неправильный цвет, это два отдельных бага. Их объединение затрудняет назначение, отслеживание и закрытие каждого из них по отдельности.

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

Основные правила заведения дефекта (баг-репорта)

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

1. Уникальный и информативный заголовок (Title/Summary)

Заголовок должен однозначно описывать суть проблемы. Это первое, что видит разработчик. Он должен быть коротким, но содержательным.

• Плохо: "Не работает кнопка".
• Хорошо: "Кнопка 'Отправить' на форме обратной связи неактивна после ввода валидного email в Chrome 120".

2. Детальное и четкое описание (Description)

Здесь излагается суть дефекта без предположений о причинах. Используйте структуру:

• Что произошло? (Краткое изложение).
• Ожидаемый результат.
• Фактический результат.

**Шаги воспроизведения:**
1. Открыть главную страницу https://example.com.
2. Кликнуть на виджет "Корзина" в верхнем правом углу.
3. В открывшейся модальной форме нажать кнопку "Очистить".

**Ожидаемый результат:** Корзина очищается, отображается сообщение "Корзина пуста".
**Фактический результат:** Корзина не очищается, в консоли браузера появляется ошибка "Uncaught TypeError: cart.clear is not a function".

3. Воспроизводимость (Reproducibility)

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

• Шаги воспроизведения (Steps to Reproduce): Последовательность точных, атомарных действий. Пронумерованный список — лучший формат.
• Частоту возникновения (Frequency): "Всегда", "Иногда (3 из 5 попыток)", "Один раз".
• Тестовое окружение (Test Environment): Без этого данные бесполезны.

    *   ОС и версия (Windows 11 23H2, macOS Sonoma 14.3).
    *   Браузер и версия (Chrome 120.0.6099.130, Firefox 122.0).
    *   Версия приложения / билда (v2.1.5, build #7812).
    *   Для мобильных — устройство, модель, версия ОС.

4. Серьезность и приоритет (Severity vs Priority)

Важно разделять эти понятия:

• Severity (Серьезность): Объективная оценка влияния дефекта на функционал системы. Определяется тестировщиком.

    *   **S1 Blocker:** Система не работает. (Падение сервера при логине).
    *   **S2 Critical:** Ключевая функция не работает. (Нельзя оформить заказ).
    *   **S3 Major:** Функция работает с ошибками. (Неверная итоговая сумма в заказе).
    *   **S4 Minor/Trivial:** Незначительная проблема, не влияющая на бизнес-логику. (Опечатка в тексте, небольшое смещение элемента UI).

• Priority (Приоритет): Субъективная оценка срочности исправления с точки зрения бизнеса и релиза. Определяется менеджером/продукт-оунером.

    *   **P1 High:** Исправить в первую очередь.
    *   **P2 Medium:** Исправить до следующего релиза.
    *   **P3 Low:** Исправить, когда будет время.

Дефект может иметь высокую серьезность (Critical), но низкий приоритет (Low), если ошибка возникает в редко используемой функции, релиз по которой не планируется.

5. Приложения (Attachments)

"Одна картинка стоит тысячи слов". Обязательно прикрепляйте:

• Скриншоты/Скринкасты: С красной обводкой места ошибки.
• Логи: Логи консоли браузера (F12 > Console), логи сервера, логи мобильного устройства.
• Файлы: Тестовые данные, использованные в сценарии.
• Ссылка на тест-кейс: Для трассируемости.

6. Унификация и стандарты

Используйте шаблоны баг-репортов в вашей bug tracking системе (Jira, YouTrack, Redmine). Это гарантирует полноту и единообразие информации от всей команды QA.

7. Прочие важные аспекты

• Один дефект — один отчет. Не объединяйте несколько несвязанных проблем.
• Нейтральный и объективный тон. Избегайте эмоциональных оценок ("ужасный интерфейс").
• Проверка на дубликаты. Перед созданием отчета всегда ищите похожие открытые дефекты.
• Корректное заполнение полей: Назначение на правильного разработчика/компонент, указание исправляющего билда (Fix Version).

Итог: Цель баг-репорта — однозначно и эффективно донести проблему до разработчика, чтобы он мог быстро ее локализовать и исправить. Хороший дефект — это самодостаточный документ, который не требует дополнительных уточнений и позволяет воспроизвести проблему "в один клик". Это основа профессиональной коммуникации в команде разработки.