Проверял ли за разработчиком баг

Мой опыт и принципы работы с багами

Нет, я не проверяю «за разработчиком» в смысле двойного контроля или недоверия. Моя задача как QA Engineer — не отслеживать работу разработчика, а обеспечивать качество продукта. Когда разработчик исправляет баг, я выполняю регрессионное тестирование — проверяю, что исправление действительно работает, и не сломало ли оно что-то еще. Это стандартный и необходимый этап жизненного цикла бага.

Что происходит после получения фикса от разработчика

Когда баг возвращается с статусом «Исправлено» (Fixed/Resolved), мои действия выглядят так:

1. Верификация исправления (Bug Verification): Я проверяю именно тот сценарий и те условия, при которых баг был воспроизведен изначально. Цель — убедиться, что дефект устранен.

   # Пример: Оригинальный баг #1234
   Когда я добавляю товар в корзину
   И применяю промокод "SUMMER20"
   Тогда цена в корзине должна уменьшиться на 20%
   Но баг: цена не меняется.
   
   # После фикса: проверяю ТОЧНО этот сценарий.
   

2. Регрессионная проверка (Regression Testing): Это самая важная часть. Я анализирую, что могло быть затронуто исправлением, и проверяю смежные функциональности.

    *   Проверяю, работают ли другие промокоды.
    *   Проверяю, корректно ли применяются скидки к разным типам товаров.
    *   Проверяю, не сломался ли расчет доставки после изменения логики цены.
    Это делается для минимизации риска появления **побочных эффектов (side effects)**.

1. Проверка на наличие регрессий (Regression Hunt): Иногда, если изменение было в ключевом модуле, я запускаю набор автотестов, связанных с этой областью, или выполняю исследовательское тестирование (Exploratory Testing) вокруг исправленного модуля.

Почему это не «проверка за разработчиком», а сотрудничество

• Разделение ответственности: Разработчик отвечает за корректность кода и unit-тесты. QA отвечает за корректность работы системы с точки зрения пользователя и целостность функциональности. Это две стороны одной медали.
• Эффект «замыленного глаза»: Разработчик, глубоко погруженный в код, может неявно предположить, что система ведет себя определенным образом. Независимый тестировщик обладает независимым восприятием (fresh perspective) и проверяет поведение, а не реализацию.
• Системное мышление: QA оценивает влияние изменения на всю систему, а не только на исправленный модуль. Разработчик может сосредоточиться на локальном исправлении.

Практический пример из опыта

Ситуация: В мобильном приложении баг: при повороте экрана во время заполнения формы данные в одном поле сбрасывались. Действия разработчика: Исправил сохранение состояния (state) для конкретного поля TextField_A. Мои действия как QA:

1. Проверил, что поле TextField_A больше не сбрасывается при повороте.
2. Регрессия: Проверил ВСЕ поля в этой и похожих формах — оказалось, что поле TextField_B в другой форме теперь стало сбрасываться (потому что использовало общий компонент).
3. Проверил другие сценарии смены состояния приложения (сворачивание/разворачивание, переключение между вкладками).
4. Обнаружил новый баг, вернул его в работу. Это не было виной разработчика — это было неочевидное последствие изменения в сложной системе.

Вывод

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