Какие знаешь виды тестирования связанные с изменениями?

Виды тестирования, связанные с изменениями

В управлении IT-проектами тестирование изменений — критически важный процесс, обеспечивающий стабильность системы после модификаций. Я выделяю следующие ключевые виды, которые мы применяем на практике.

1. Регрессионное тестирование (Regression Testing)

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

• Полное регрессионное тестирование: Запуск всех существующих тестов. Требует много времени и ресурсов, поэтому применяется на критичных проектах или перед major-релизом.
• Избирательное регрессионное тестирование: Запуск только тестов, связанных с измененными модулями и их зависимостями. Оптимально по соотношению effort/покрытие.
• Автоматизация регрессии: Ключевой инструмент для эффективного процесса. Например, используем скрипт для выбора нужного набора тестов на основе ченджсетов:

# Пример логики выбора тестов для избирательной регрессии (псевдокод)
def select_regression_tests(modified_modules, test_suite_map):
    """
    modified_modules: список измененных модулей (например, ['PaymentService', 'UserAuth'])
    test_suite_map: словарь {модуль: [список тестов]}
    """
    tests_to_run = set()
    for module in modified_modules:
        # Добавляем тесты для измененного модуля
        if module in test_suite_map:
            tests_to_run.update(test_suite_map[module])
        # Добавляем тесты для интеграционно-зависимых модулей (логика поиска зависимостей)
        dependent_modules = find_dependencies(module)
        for dep in dependent_modules:
            if dep in test_suite_map:
                tests_to_run.update(test_suite_map[dep])
    return list(tests_to_run)

2. Дымовое тестирование (Smoke Testing / Build Verification Testing)

Быстрая проверка стабильности сборки после внесения изменений. Это "тест на дым" — если система загорится, мы узнаем сразу. Выполняется перед полным регрессионным тестом.

• Проверяет ключевые, наиболее важные функции.
• Обычно занимает от 15 минут до часа.
• Пример набора для e-commerce: вход пользователя, просмотр каталога, добавление в корзину, инициирование оплаты.

3. Санитарное тестирование (Sanity Testing)

Узконаправленная проверка конкретного исправления или новой функции после сборки. Более глубокое, чем дымовое, но менее масштабное, чем регрессия.

• Отвечает на вопрос: "Работает ли именно этот исправленный функционал, как и задумано?".
• Часто выполняется вручную разработчиком или тестировщиком.

4. Повторное тестирование (Re-testing / Confirmation Testing)

Целенаправленная проверка исправленных дефектов. После того как разработчик сообщает об исправлении бага, тестировщик проверяет именно этот сценарий, чтобы убедиться в его закрытии.

• Ключевое отличие от регрессии: Регрессия ищет побочные эффекты, а повторное тестирование проверяет цель исправления.

5. Сборочное тестирование (Build Acceptance Testing)

Проверка, что новая сборка (артефакт) готова для передачи в тестовое окружение. Включает проверку:

• Корректности версии и метаданных сборки.
• Отсутствия критичных ошибок при развертывании (deploy).
• Доступности базовых сервисов.

6. Тестирование на откат (Rollback Testing)

Критически важный вид для процессов непрерывной поставки (CI/CD). Проверяет, что процедура отката изменений до предыдущей стабильной версии работает корректно и не приводит к потере данных или неконсистентности системы.

7. Impact Analysis (Анализ влияния изменений)

Хотя это не тестирование в чистом виде, это предварительный этап, определяющий объем и виды необходимого тестирования. Мы анализируем:

• Какие модули затронуты.
• Карту зависимостей (dependency map).
• Риски, связанные с изменениями.
• На основе этого формируем стратегию тестирования (Test Strategy) для данного патча или релиза.

Практический подход в проектах

В моей практике мы интегрируем эти виды в процесс управления изменениями:

1. Получение ченджсета -> Запускаем Анализ влияния.
2. Сборка артефакта -> Проводим Сборочное и Дымовое тестирование.
3. Если сборка стабильна -> Запускаем Санитарное тестирование новой функции или Повторное тестирование багфикса.
4. Параллельно, на основе анализа влияния, автоматизированный пайплайн запускает Избирательное регрессионное тестирование.
5. Перед релизом в прод -> Выполняем Полную регрессию на pre-prod и обязательно проверяем сценарий отката.

Использование правильной комбинации этих видов позволяет сбалансировать скорость доставки изменений (Time-to-Market) и надежность продукта, что является одной из основных задач IT Project Manager.