Какие знаешь подходы?

Основные подходы в тестировании ПО

За более чем 10 лет работы в QA я сталкивался и применял множество подходов, которые можно классифицировать по нескольким ключевым аспектам: стратегия тестирования, степень автоматизации, вовлеченность в процесс разработки и техническая направленность. Каждый подход решает свои задачи и оптимален в определенном контексте.

1. Стратегические подходы (По целям и охвату)

Эти подходы определяют, ЧТО и КОГДА мы тестируем.

• Black Box Testing (Тестирование черного ящика):

    *   **Суть:** Тестирование без знания внутреннего устройства системы. QA взаимодействует с ПО через интерфейсы (UI, API), как это делает конечный пользователь, проверяя соответствие функциональных и нефункциональных требований.
    *   **Когда используется:** На всех уровнях тестирования (от модульного до приемочного). Это фундаментальный подход для проверки внешнего поведения.
    *   **Пример:** Проверка, что форма логина принимает правильный пароль и блокирует неправильный.

• White Box Testing (Тестирование белого ящика):

    *   **Суть:** Тестирование с полным знанием исходного кода и внутренней архитектуры. Позволяет проектировать тесты для покрытия конкретных путей выполнения, условий, ветвлений.
    *   **Когда используется:** Чаще разработчиками на уровне модульного и интеграционного тестирования. QA-engineer может применять его для анализа покрытия кода (`code coverage`) и проведения статического тестирования (ревью кода).
    *   **Пример (псевдокод):** Написание юнит-теста, который проверяет все ветви условия в функции.

    ```python
    def calculate_discount(amount, is_vip):
        if is_vip and amount > 1000:
            return amount * 0.8  # 20% скидка
        elif amount > 1000:
            return amount * 0.9  # 10% скидка
        else:
            return amount

    # White-box тест будет целенаправленно проверять все три ветки:
    assert calculate_discount(1500, True) == 1200  # Ветка 1
    assert calculate_discount(1500, False) == 1350 # Ветка 2
    assert calculate_discount(500, False) == 500   # Ветка 3
    ```

• Gray Box Testing (Тестирование серого ящика):

    *   **Суть:** Компромиссный подход. Тестировщик обладает частичным знанием внутренней структуры (например, схемой базы данных, логикой API), но тестирует через внешние интерфейсы. Это позволяет создавать более умные и целенаправленные тестовые сценарии.
    *   **Когда используется:** Очень часто в интеграционном и системном тестировании, особенно при работе с API и базами данных.
    *   **Пример:** Зная структуру таблицы `users`, тестировщик через UI создает нового пользователя, а затем выполняет SQL-запрос, чтобы проверить, корректно ли данные записались в БД.

2. Подходы по степени формализации и автоматизации

• Ручное тестирование (Manual Testing): Исследовательское тестирование (Exploratory Testing), тестирование по чек листам (Checklist-based), Ad-hoc тестирование. Критически важно на ранних этапах, для проверки UX и в ситуациях, где автоматизация нецелесообразна или слишком дорога.
• Автоматизированное тестирование (Automated Testing): Все, что выполняется скриптами. Здесь выделяются ключевые стратегии:

    *   **Test Pyramid (Пирамида тестов):** Фундаментальный подход, рекомендующий много низкоуровневых (быстрых и дешевых) автотестов (юнит-тесты) и меньше высокоуровневых (медленных и дорогих) тестов (UI-тесты).

    ```
            (Мало) UI / E2E тесты
               /         \
              /           \
    (Больше) Интеграционные тесты
              /           \
             /             \
    (Много) Юнит-тесты
    ```

    *   **BDD (Behavior-Driven Development):** Подход, фокусирующийся на общем языке между бизнесом, разработкой и QA. Сценарии пишутся на почти естественном языке (Gherkin), что делает их понятными для всех участников.

    ```gherkin
    Feature: Перевод денег
      Scenario: Успешный перевод между счетами пользователя
        Given пользователь "Иван" имеет на счете "Основной" 5000 рублей
        And пользователь "Иван" имеет счет "Накопительный"
        When он переводит 1000 рублей со счета "Основной" на счет "Накопительный"
        Then на счете "Основной" должно остаться 4000 рублей
        And на счете "Накопительный" должно стать 1000 рублей
    ```

3. Процессные подходы (По вовлеченности в SDLC)

• Waterfall (Каскадная модель): Тестирование — отдельная фаза после завершения разработки. Подход требует детальных спецификаций и часто ведет к позднему обнаружению критических дефектов.
• Agile/DevOps: Тестирование интегрировано в цикл разработки. Основные практики:

    *   **Непрерывное тестирование (Continuous Testing):** Автотесты запускаются автоматически на каждом этапе CI/CD пайплайна (при коммите, сборке, перед деплоем).
    *   **Сдвиг влево (Shift-left):** Начало тестирования как можно раньше (статические анализаторы, ревью требований, участие в планировании).
    *   **Сдвиг вправо (Shift-right):** Тестирование в продакшене (мониторинг, A/B-тесты, `Chaos Engineering`, сбор обратной связи от реальных пользователей).

4. Технические/Специализированные подходы

• Тестирование, основанное на рисках (Risk-Based Testing): Приоритизация тестовых усилий на основе анализа потенциальных рисков (частота использования, критичность для бизнеса, сложность компонента).
• Тестирование, основанное на сценариях использования (Scenario-Based Testing): Фокус на реальных пользовательских сценариях (user stories), а не на абстрактных проверках функций.
• Тестирование безопасности (Security Testing): SAST (статический анализ), DAST (динамический анализ), пентесты.
• Тестирование производительности (Performance Testing): Нагрузочное (Load), стрессовое (Stress), тестирование стабильности (Soak).

Вывод: Современный эффективный QA Engineer не привязан к одному подходу. Он комбинирует их в зависимости от контекста проекта, фазы разработки и конкретных задач. Например, в спринте может применяться Agile с акцентом на Gray Box и Exploratory тестирование новой функциональности, в то время как CI/CD пайплайн автоматически прогоняет полную Пирамиду автотестов (Unit, API, избранные UI), основанных на BDD-cценариях, чтобы обеспечить Continuous Testing и минимизировать риски.