Если рассуждать о сути приоритизации тест-кейсов и ее роли в процессе тестирования, прежде всего стоит обозначить те ситуации, в которых данный подход проявляет себя наиболее явно. Как правило, приоритизация тест-кейсов становится особенно актуальной в рамках регрессионного тестирования, когда возникает необходимость выявления потенциальных уязвимостей продукта и подтверждения его соответствия заданной логике поведения без критических ошибок.
Для начала необходимо определить отправную точку этого процесса. То есть от чего мы отталкиваемся, когда запускаем регрессионное тестирование?
Чаще всего мы принимаем во внимание последние изменения в продукте. Пытаемся определить, какие именно области системы подвержены наибольшему риску возникновения регрессионных дефектов. Следовательно, эти области требуют наиболее тщательного повторного тестирования, чтобы гарантировать сохранение текущей функциональности и исключить появление нежелательных побочных эффектов, способных нарушить стабильную работу продукта.
Если уйти от идеализации, то обычно в начале регрессионного тестирования мы видим огромное количество тест-кейсов в виде большого списка, который, как правило, структурировано выделен по папкам и разбит на модули, связанные между собой. Такое тестирование занимает большой объем работы и времени, а главная задача — это не упустить ничего, что может блокировать нам использование нашего продукта.
На выходе мы имеем: высокий уровень ответственности и ограниченное количество отведенного времени на эту работу. Так как же мы можем оптимизировать и облегчить себе работу во время регрессионного тестирования и при этом не упустить критических багов?