Кто перепроверяет баг

Процесс перепроверки багов в тестировании

В стандартной практике QA и разработки, процесс перепроверки (re-testing или bug verification) фиксированных дефектов — это критически важный этап, обеспечивающий качество конечного продукта. Основное правило: перепроверку всегда выполняет тот же тестировщик (QA Engineer), который первоначально обнаружил и зарегистрировал баг. Это ключевой принцип для обеспечения эффективности и избежания коммуникационных ошибок.

Почему это так важно?

• Контекст и понимание: Первоначальный тестировщик обладает наиболее глубоким пониманием контекста бага — точных шагов для воспроизведения, ожидаемого и фактического поведения, условий окружения (ОС, браузер, данные). Он знает "нюансы" проблемы.
• Эффективность: Он может быстро и точно повторно выполнить тестовый сценарий, не тратя время на изучение описания бага "с нуля".
• Контроль качества фикса: Только оригинальный автор баг(report) может наиболее объективно оценить, исправление действительно полностью устранило проблему, не создало побочных эффектов (regressions) в том же функционале, и соответствует первоначальным ожиданиям.
• Ответственность и цикл: Это закрывает цикл ответственности: Find -> Report -> Verify. Такой подход четко отслеживает работу каждого специалиста.

Участники процесса и их роль

1. QA Engineer (тестировщик) — основной исполнитель перепроверки.

    *   После того как разработчик (**Developer**) помечает баг как исправленный (например, статус `Fixed` или `Resolved` в Jira), тестировщик получает задачу на проверку.
    *   Он выполняет следующие шаги:

    ```javascript
    // Пример мысленного алгоритма действия QA при перепроверке
    if (bug.status === 'Fixed') {
        1. Взять оригинальный bug-report (ID #12345);
        2. Прочитать комментарии разработчика о примененном fix;
        3. Подготовить тестовое окружение (среда, данные) как в оригинальном отчете;
        4. Воспроизвести точную последовательность шагов (Steps to Reproduce);
        5. Проверить, что фактический результат теперь равен ожидаемому;
        6. Провести связанное тестирование вокруг fix (проверить не сломал ли fix что-то рядом);
        7. Если баг исправлен — закрыть баг (статус 'Verified' или 'Closed');
        8. Если баг не исправлен или появились новые проблемы — reopen баг с комментариями.
    }
    ```

2. Разработчик (Developer) — не перепроверяет баг в классическом смысле. Он проверяет, что его код работает локально, перед отправкой fix, но формальная приемка (acceptance) фикса выполняется QA.

1. Lead QA / QA Manager — может выполнять перепроверку в особых случаях:

    *   Если оригинальный тестировщик недоступен (отпуск, ушел из проекта).
    *   Для критических (**showstopper**) или очень сложных багов, где требуется дополнительный экспертный взгляд.
    *   В процессе **аутсорс-тестирования**, где внутренняя команда перепроверяет баги, найденные внешними тестировщиками.

1. Пользователь / Клиент — в некоторых моделях, особенно когда баг найден на production или клиентом в beta-версии, фикс может быть перепроверен самим пользователем перед окончательным закрытием.

Нюансы и исключения

• Регрессионное тестирование (Regression Testing): После перепроверки конкретного бага, QA часто проводит более широкое регрессионное тестирование модуля или связанных функций, чтобы убедиться, что исправление не внесло новых ошибок. Это уже задача не только оригинального тестировщика, может выполняться командой.
• Автоматизация: Если баг был найден автоматизированным тестом, то его перепроверка также часто осуществляется путем повторного запуска этого автоматизированного сценария после интеграции фикса. Ответственность за анализ результатов все равно лежит на QA.
• "Баги-духи" (Heisenbugs): Для сложно воспроизводимых багов в перепроверке может участвовать и разработчик, помогая воссоздать условия.

Инструменты и статусы в bug-tracker

Процесс отражается в системах управления дефектами (Jira, Bugzilla, GitHub Issues):

Статусная цепочка бага:
New -> Assigned (to Dev) -> In Progress (Dev fixes) -> Fixed/Resolved (by Dev) -> Ready for Test -> Verified/Closed (by QA) -> Reopened (if fail) -> Closed.

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