Регрессионное тестирование (regression testing):Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. [ISTQB Глоссарий 2.3]
Материалы:
-
Caren N. Johnson
-
О вреде и пользе регрессионого тестирования (Сергей Высоцкий)
-
SQA Days 6: Реальное упрощение регрессионного тестирования (Интервью)
-
Автоматизированное тестирование с нуля. Часть 1. (Сергей Мартыненко)
-
Recession Testing is the new RegressionTesting (Maverick Tester) - eng
Стратегия регрессионного тестирования (Алексей Виноградов):
Тестировать важное, тестировать то, где недавно ломалось, тестировать то, где недавно копались и тестировать то, что давно не тестировали.
Что включать в регрессию в первую очередь (Игнат Круковский):
-
Наиболее критичные для клиента модули
-
Наиболее забагованные модули
Что нужно для регрессионного тестирования:
1. Время
2. Ресурсы
3. Список изменений
4. Критичность фич
5. Схема продукта, для выявления, что может быть затронуто
6. Тестовое окружение (тестовые среды, сервера, инструменты разные)
7. Регрессионная библиотека, то есть список регрессионных тестов
Когда проводить регрессию:
-
Регрессия нужна в случае рефакторинга (Роман Шейко)
-
Циклы регрессии планируют при накоплении критической массы изменений в продукте (Константин Коваль)
-
Когда много изменений и они идут часто - регрессия необходима (Роман Шейко)
Когда можно отказаться от регрессии:
-
В каком случае регрессионное тестирование не проводят (Обусуждение)
-
От регрессии можно отказаться, когда разовый проект (Кирилл Ремизов)
-
Если времени на всё не хватает (Константин Коваль)
Прочее:
-
Регрессионное тестирование: как упростить и автоматизировать (Обсуждение)
-
Стратегия регрессионного тестирования HipChat:
-
Константин Коваль
-
Выражаю благодарность Роману Шейко за 6 сессию weekend testing - во время которой и был создан данный документ.