Регрессия и релиз · Средняя
Спланировать регрессию
Выбрать набор проверок, который защищает важные старые сценарии перед релизом.
Быстро понять за 2 минуты
Выбрать набор проверок, который защищает важные старые сценарии перед релизом.
Контекст
Перед релизом важно проверить не только новую функцию, но и критические старые сценарии, которые могли сломаться.
Что это дает
Регрессия снижает риск, что новая функциональность сломает работающие части продукта.
Как выполнить
- Определите затронутые модули.
- Выберите critical path и интеграционные сценарии.
- Согласуйте время и владельцев регрессии.
Критерии приемки
- Regression scope утвержден.
- Проверки привязаны к рискам релиза.
- Результат доступен команде.
Типичные ошибки
- Запускать всю регрессию без учета изменений.
- Не проверять интеграции.
- Не оставлять время на исправления.
Инструменты
Рабочий артефакт
Release quality
Релизная готовность
Оценка готовности релиза по критичным дефектам, регрессии, smoke и рискам.
- Critical bugs
- Smoke pass rate
- Regression pass rate
- Known issues
Контроль качества
Релизная готовность
Regression scope утвержден.
После релизов, изменения требований, новых дефектов, ретестов и обновления критериев приемки.
Риск, шаги воспроизведения, окружение, доказательства, ожидаемый результат и владельца исправления.
Перед отметкой выполнено: Regression scope утвержден.
Как применять
Начинайте с риска для пользователя и продукта. Затем проверьте воспроизводимость, окружение, тестовые данные и доказательства. Хороший QA-пункт отвечает на три вопроса: какой риск закрываем, как воспроизводим результат и по каким критериям считаем проверку завершенной.
Режим обучения
Прочитайте материал, прослушайте аудио и проверьте понимание по коротким вопросам. Ответ раскрывается после попытки сформулировать его самостоятельно.