Регрессное требование в тестировании программного обеспечения¶
Регрессное требование — это требование к программному обеспечению, направленное на обеспечение того, чтобы ранее разработанные и работающие функции системы продолжали корректно функционировать после внесения изменений в код. Регрессные требования относятся к категории функциональных требований и составляют основу регрессного тестирования — одного из ключевых видов тестирования в инженерии программного обеспечения.
¶Суть понятия
При разработке программного обеспечения код постоянно изменяется: разработчики добавляют новый функционал, исправляют ошибки, рефакторят модули, оптимизируют производительность. Каждое такое изменение потенциально может нарушить уже существующую, корректно работавшую функциональность. Это явление называется регрессией — откатом работоспособности. Регрессное требование фиксирует ожидаемое поведение системы, которое должно сохраниться после модификаций.
Формулируется регрессное требование так же, как и обычное функциональное: оно описывает, что должна делать система в конкретных условиях. Отличие заключается в назначении — оно направлено не на проверку нового функционала, а на подтверждение того, что старый функционал не сломан.
Примеры регрессных требований:
- после добавления нового метода оплаты система должна по-прежнему корректно обрабатывать все ранее поддерживаемые способы оплаты;
- после изменения алгоритма авторизации все ранее зарегистрированные пользователи должны иметь возможность входа в систему;
- после рефакторинга модуля отчёты должны формироваться с теми же данными и в том же формате, что и до изменений.
¶Роль в процессе разработки
Регрессные требования тесно связаны с практикой непрерывной интеграции и непрерывной доставки (CI/CD). В таких процессах изменения в код интегрируются в общую ветку несколько раз в день, и каждая интеграция должна сопровождаться проверкой работоспособности системы. Автоматические регрессные тесты, основанные на регрессных требованиях, выполняются при каждом сборке и позволяют быстро выявить нарушения.
В подходах с итеративной разработкой (Scrum, Kanban) регрессные требования учитываются на этапе приёмки пользовательских историй (user story). Критерии приёмки часто включают пункт «существующий функционал не нарушен», что и является операционализацией регрессного требования.
¶Классификация
Регрессные требования можно разделить на несколько групп по признакам:
| Признак | Виды |
|---|---|
| По охвату | Точечные (на конкретный модуль), интеграционные (на взаимодействие модулей), системные (на систему в целом) |
| По критичности | Критичные (нарушение ведёт к недоступности ключевой функции), некритичные (косметические или редко используемые функции) |
| По способу проверки | Автоматизируемые (покрываются автотестами), ручные (проверяются вручную из-за сложности автоматизации) |
¶Связь с регрессным тестированием
Регрессное тестирование — это процесс повторного тестирования ранее протестированных компонентов системы для обнаружения дефектов, вызванных изменениями. Регрессные требования служат источником для построения регрессного тест-набора (regression test suite).
Основная проблема регрессного тестирования — объём. По мере роста системы набор регрессных тестов увеличивается, и его полное выполнение на каждой итерации может занимать значительное время. Для решения этой задачи применяются:
- приоритизация регрессных тестов по критичности покрываемых требований;
- выборочное (селективное) регрессное тестирование — прогон только тех тестов, которые связаны с изменёнными компонентами;
- тестирование на основе рисков — фокус на наиболее критичных функциях;
- автоматизация максимального числа регрессных проверок.
¶Требования к формулировке
Хорошо сформулированное регрессное требование должно быть:
- проверяемым — можно однозначно определить, выполнено требование или нет;
- однозначным — не допускать двойного толкования;
- связанным с изменениями — указывать, к какому компоненту или функции относится и какие модификации могут его затронуть;
- трассируемым — иметь связь с соответствующими тест-кейсами и элементами кода.
¶Место в системе требований
В документации на программный продукт регрессные требования не всегда выделяются в отдельный раздел. Чаще они интегрированы в общее описание функциональных требований, а их регрессная природа фиксируется в тест-планах и тест-кейсах, помеченных как регрессные. В системах управления тестирований (TestRail, Zephyr, Jira с плагинами) регрессные тесты обычно выделяются отдельной меткой или в отдельный набор.
В теории тестирования регрессные требования рассматриваются в контексте модели «изменение — проверка»: любое изменение в системе должно сопровождаться идентификацией затронутых требований и выполнением соответствующих проверок. Это делает регрессные требования неотъемлемой частью управления конфигурацией и изменениями в разработке ПО.
Источники:
- IEEE 829 — Стандарт по документированию тестирования программного обеспечения
- IEEE 29119 — Международные стандарты по тестированию программного обеспечения
- Романько Е. С., Шкарин М. С. «Тестирование ПО. Практика эффективной разработки»
- Канер С., Фолк Дж., Нгуен Б. «Основы тестирования программного обеспечения»
- Sommerville I. «Software Engineering»