Оценка влияния релизов и планирование регрессии
Иллюстративный сценарий использования, а не кейс клиента.
Изменения релиза сопоставляются с затронутыми конфигурациями, интеграциями и тестами; руководитель поставки определяет объём и даёт разрешение на запуск.
Проблема
Релизы вендоров и наши собственные изменения выходят по графику, который мы не контролируем. Мы читаем описание релиза, гадаем, что может сломаться, и либо тестируем всё, либо то, что помним. Дефекты всё равно доходят до пользователей.
Как это работает сегодня
Когда объявляется релиз, аналитик читает описание и пишет команде обо всём, что выглядит относящимся к делу. Тестировщики выбирают скрипты из общей папки по опыту. Партнёров по интеграции уведомляют поздно. После запуска проблемы прослеживаются до изменений, которые никто не отметил.
Посмотрите сценарий
Иллюстративный рабочий процесс. С субтитрами.
Текстовая версия
- Описания релизов приходят, но команда всё равно гадает, что тестировать. Пропущенные изменения становятся инцидентами после запуска.
- Планировщик сопоставляет изменения релиза с затронутыми приложениями и тестами, выделяет пробелы в покрытии и предлагает, что тестировать и как развёртывать.
- Руководитель внедрения решает, что тестируется, а что откладывается. План проверяется, а результаты тестов определяют допуск к запуску.
- Измеряем тестовое покрытие и пропущенные дефекты. Иллюстративный сценарий использования. Давайте обсудим ваш.
Предлагаемый рабочий процесс
- Загрузить описания релизов и записи об изменениях для приложений в рамках объёма
- Сопоставить каждое изменение с конфигурациями, доработками и интеграциями, которые оно может затронуть
- Соотнести затронутые области с существующим реестром тестов и выделить пробелы
- Подготовить черновик объёма регрессии и последовательности развёртывания
- Представить план руководителю внедрения на утверждение до начала тестирования и развёртывания
Где контроль остаётся за человеком
- Руководитель внедрения утверждает объём регрессии и развёртывание
- Изменения, которые не удалось сопоставить, помечаются для ручной оценки, а не игнорируются
- Пропущенные дефекты возвращаются в сопоставление и реестр тестов
Привязка к платформам указывает среды, в которых имеет смысл оценить эту идею. Фактическая реализация зависит от конфигурации, лицензий, API, данных и прав доступа. Преимущества описаны качественно; числовые утверждения требуют задокументированной базовой линии.