Каков порядок действий при обнаружении дефекта (бага)?

«Каков порядок действий при обнаружении дефекта (бага)?» — вопрос из категории Основы тестирования, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Стандартный workflow фиксации дефекта включает следующие шаги:

1. Локализация и верификация:

  • Убедиться, что это действительно баг, а не ошибка в тестовых данных или окружении.
  • Попробовать воспроизвести его 2-3 раза.
  • Проверить на другой конфигурации (если применимо), чтобы понять степень влияния.

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

  • Заголовок (Summary): Кратко и ясно. [Модуль] Краткое описание проблемы при условии.
    • Плохо: "Не работает кнопка"
    • Хорошо: [Корзина] Кнопка 'Оформить заказ' неактивна после удаления последнего товара
  • Шаги воспроизведения (Steps to Reproduce): Нумерованный список конкретных действий.
  • Фактический результат (Actual Result): Что происходит на самом деле.
  • Ожидаемый результат (Expected Result): Что должно происходить согласно требованиям.
  • Окружение (Environment): OS, браузер, версия приложения, устройство.
  • Приоритет/Серьёзность (Priority/Severity): Определяется по влиянию на пользователя.
  • Вложения (Attachments): Скриншоты, видео, логи.

Пример структуры отчёта:

**Summary:** [API /users/login] Возвращает HTTP 500 при корректных credentials.
**Steps:**
1. Отправить POST-запрос на https://api.example.com/v1/users/login
2. Тело запроса: {"email": "valid_user@test.com", "password": "Qwerty123"}
3. Запрос выполняется с заголовком Content-Type: application/json.
**Actual Result:** HTTP Status 500 (Internal Server Error), тело: {"error":"undefined method '...' for nil:NilClass"}
**Expected Result:** HTTP Status 200 с токеном авторизации.
**Environment:** Production, 2024-12-01 10:00 UTC.
**Attachments:** curl_command.txt, server_log_snippet.log

3. Назначение и коммуникация: Назначить баг на соответствующего разработчика/команду. При необходимости кратко описать проблему в чате команды.

4. Верификация исправления: После того как разработчик сообщит об исправлении, выполнить регрессионную проверку — убедиться, что баг устранён и новые изменения не сломали смежную функциональность.