Что общего между функциональным видом тестирования и связанным с изменениями

Общее между функциональным тестированием и тестированием, связанным с изменениями

На первый взгляд, функциональное тестирование (Functional Testing) и тестирование, связанное с изменениями (Change-Related Testing) кажутся разными областями. Первое проверяет соответствие системы требованиям и спецификациям, а второе фокусируется на последствиях модификаций в коде или окружении. Однако между ними существует глубокая и практическая связь, которая является основой для построения эффективного процесса контроля качества в условиях постоянных изменений.

Основные точки соприкосновения

1. Цель: обеспечение соответствия требованиям после изменений

    *   **Функциональное тестирование** отвечает на вопрос: "Работает ли система так, как задумано?".
    *   **Тестирование, связанное с изменениями** (включая **регрессионное**, **санитарное** и **дымовое**) отвечает на вопрос: "Осталась ли система работоспособной и соответствующей требованиям *после внесенных изменений*?".
    *   **Общее:** Оба вида в контексте изменений работают на одну цель — убедиться, что новая функциональность работает корректно, а существующая не сломана. Тестирование изменений часто *опирается на* функциональные тест-кейсы для проверки регрессии.

1. Движущая сила: изменения в продукте

    Оба вида тестирования активизируются в ответ на изменение:
    *   Введение **новой функциональности** — требует **функционального тестирования** этой фичи и **регрессионного тестирования** для проверки остальной системы.
    *   **Исправление дефекта** (бага) — требует **повторного (confirmation) тестирования** исправления (по сути, точечного функционального теста) и **регрессионного тестирования** затронутой области.
    *   **Изменение конфигурации или окружения** — может потребовать **функционального смоук-тестирования** ключевых сценариев в новом окружении.

1. Зависимость от артефактов требований

    И функциональное, и регрессионное (как ключевая часть тестирования изменений) тестирование напрямую зависят от:
    *   **Спецификаций требований (SRS)**
    *   **Пользовательских историй (User Stories)**
    *   **Моделей поведения (например, BDD-сценариев)**
    Без четких требований невозможно построить корректные функциональные тесты, а без них — невозможно определить, что именно нужно проверять на регрессию после изменений.

Практическая интеграция в процессах: пример

Рассмотрим типичный цикл разработки фичи или исправления бага.

1. Получение задачи на изменение: Разработчик реализует новую кнопку "Экспорт в PDF" на странице отчета.
2. Создание и выполнение функциональных тестов (проверка нового):

    *   QA-инженер на основе требований пишет тест-кейсы, проверяющие основную и граничные сценарии работы новой кнопки.

```gherkin
# Пример BDD-сценария (функциональный тест)
Feature: Экспорт отчета
  Scenario: Успешный экспорт отчета в PDF
    Given пользователь находится на странице "Месячный отчет"
    When пользователь нажимает кнопку "Экспорт в PDF"
    Then система сохраняет файл "report_202310.pdf" на компьютер пользователя
    And файл имеет корректный формат PDF
```

    Эти тесты выполняются для валидации новой функциональности.

1. Планирование и выполнение тестов, связанных с изменениями (защита существующего):

    *   QA-инженер анализирует **зону влияния (impact analysis)** изменения: затронута ли страница отчета, связанные модули (генерация данных, система файлов).
    *   На основе этого анализа формируется **регрессионный набор** для запуска после внедрения изменения. Этот набор состоит в основном из **функциональных тестов** для критических сценариев затронутой области:
        *   Загрузка страницы отчета.
        *   Формирование отчета с разными фильтрами.
        *   Работа других кнопок экспорта (если есть).
        *   Общая проверка смежных страниц (**дымовое тестирование**).

1. Автоматизация: Успешные функциональные тесты новой кнопки и ключевые регрессионные тесты добавляются в набор автоматических регрессионных тестов. Это идеальная синергия: функциональные тесты становятся основой для будущего тестирования изменений.

Ключевое различие в фокусе

• Функциональное тестирование фокусируется на "что" (что должна делать система, согласно требованиям).
• Тестирование, связанное с изменениями, фокусируется на "где и сколько" (где могли появиться побочные эффекты, и какой объем проверок необходим для их выявления).

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