Как ищешь баги при регрессионном тестировании

Моя цель при регрессионном тестировании — найти баги, которые появились в уже работавшем функционале из-за новых изменений. Я действую системно:

1. Глубокий анализ изменений (Change Impact Analysis): Перед началом тестирования я изучаю тикет в Jira, мерж-реквест и, если возможно, код. Я задаю вопрос: «Какие смежные модули или функции могут быть затронуты этим изменением?». Например, изменение в методе расчета скидки может повлиять на корзину, историю заказов и отчетность.

2. Фокус на «зонах риска»: Я уделяю особое внимание:

   • Интеграционным точкам между измененным модулем и другими системами.
   • Общему коду или библиотекам, которые использовались в изменении.
   • Функциям, которые используют те же данные или API.

3. Сценарное тестирование за пределами «счастливого пути»: Помимо проверки основного сценария, я целенаправленно тестирую:

   • Пограничные значения (Boundary Value Analysis).
   • Ошибочные сценарии (ввод неверных данных, отказ внешних сервисов).
   • Откат изменений (rollback), если такая функциональность есть.

4. Использование автоматизированных регрессионных сьютов: Я запускаю автоматизированные тесты, которые покрывают ключевые сценарии из «зон риска». Это быстро дает обратную связь.

   @Test
   public void regression_OrderPriceCalculation_AfterDiscountChange() {
       // 1. Создаем заказ с товаром, на который изменили правила скидки
       Order order = orderService.createOrder(TEST_PRODUCT_ID, 2);
   
       // 2. Проверяем, что итоговая цена рассчитана корректно по НОВЫМ правилам
       BigDecimal expectedPrice = new BigDecimal("180.00"); // Ожидаемо после изменения
       assertEquals(expectedPrice, order.getTotalPrice(), "Total price mismatch after discount logic change");
   
       // 3. Проверяем, что старая функциональность (налог, доставка) не сломалась
       assertNotNull(order.getTaxAmount());
       assertTrue(order.getDeliveryCost().compareTo(BigDecimal.ZERO) >= 0);
   }

5. Эксплораторское тестирование (Exploratory Testing): Выделяю время на свободное исследование обновленного функционала, следуя карте ума (mind map) из пункта 1. Часто самые коварные баги находятся именно там, где их не ждали.

Ключевой принцип: регрессия — это не просто «прогнать все тесты», а целенаправленный поиск проблем в областях, наиболее вероятно затронутых изменениями.