Для начала напомним определение регрессионного тестирования. Это такой тип тестирования, которое проверяет, что апдейты (то есть модификации кода), не ухудшили существовавшую функциональность приложения. Регресс — это о том, что приложение работает как ожидалось, несмотря на изменения, модификации и обновления кода.
Регрессионное тестирование — один из важнейших этапов тестирования, и у такого тестирования есть узкие места. В частности, нестабильность тестов, и сложности с их корректированием. Существуют стратегии и лучшие практики, которые позволяют ускорить регресс, возможно, в несколько раз.
Каждый flow должен автоматизироваться независимо
Автотесты не должны зависеть от результатов предыдущих тестов, и от данных, созданных в предыдущих тестах (что часто делается и не считается плохой практикой). Правильные регрессионные тесты не зависят друг от друга и от порядка их выполнения. Независимо от того, запускается ли тест отдельно или в сьюте, всегда будут надежные результаты.
Тщательнее подбирать селекторы
Автотесты получаются нестабильными, когда в них включены часто изменяющиеся элементы. Что понятно: продолжается разработка, команда работает над кодом, непрерывно обновляет его. Чтобы избежать проблем и ускорить регресс, желательно внимательнее относиться к подбору селекторов, и применять селекторы, специфичные для конкретного теста.
Частые апдейты чек-листа
В стандартной процедуре регресс-тестирования большинства модулей применяются low-level—чеклисты. Они пишутся на основе мокапов и требований. Но если требования обновлены, и появились новые функции в софте, чек-листы должны быть тоже обновлены, и желательно раньше. Полезная практика: в процессе регрессионного тестирования делать эпизодические паузы для работы с документацией. Это поможет освежить процесс.
Включение исследовательского тестирования
Если одни и те же тесты делаются по чек-листу каждый день, будет полезно применять в процессе исследовательское тестирование — так регрессы будут более продуктивны (да и интересны). Это поможет команде “подняться на уровень выше” стандартных чек-листов, посмотреть на свои тест-кейсы с новой точки зрения. Большие тест-кейсы можно будет “прокачать”, найти в них проблемные места. Если в регрессы включены исследовательские процедуры, будет меньше утомления от рутинной работы.
Тестовое окружение
Рутинный регресс постепенно вырабатывает “туннельное зрение”, снижается внимательность к деталям, у команды пропадает энтузиазм. Чтобы укрепить интерес тестировщиков, можно периодически менять тестовое окружение, и тестировать на разных девайсах, браузерах и платформах. Например регресс делается один день на Windows/Firefox, на следующий день на Мас, на следующий на Linux. Таким образом баги, специфичные для платформы, девайса, и браузера, более легко отслеживаются.
Ускорение регрессионных тестов в Agile
Теперь, как ускорить регресс, рассматривая его с точки зрения правильного Agile.
Эджайл, как известно, это революция в разработке (по крайней мере так считают многие). Характерны непрерывные апдейты, постоянная оглядка на поступающий пользовательский фидбэк, ускорение выхода приложений на рынок, и заметно выше эффективность инвестиций (ROI).
В этой методологии есть тонкие места, например сочетание принятых регрессионных практик с Agile-спринтами. Эти места надо знать и уделять внимание, чтобы не терялась продуктивность.
Известные проблемы регрессионного тестирования в условиях Agile:
- Малая сосредоточенность, рутина. Случается, что тестировщик/разработчик из-за рутинности процесса теряет внимательность при контроле регрессионных тест-кейсов. Это вызывает проблемы на продакшене, и повышает издержки в проекте.
- Тратится много времени и усилий. Понятно, что в Agile идет много времени на регрессионное тестирование, особенно на больших проектах. В некоторых ситуациях весь спринт уходит на регрессы, и это нехорошо (и дорого).
Чтобы решить эти проблемы, и сделать это применяя стратегический подход, ориентированный на результат, как и положено в Agile, нужно оптимизировать регресс.
Применяются такие методы:.
Уточнение действий при регрессионном тестировании. Действия делят на две части:
- Полный регресс. То есть полное регрессионное тестирование, выполняемое QA-отделом до релиза, чтобы убедиться, что приложение работает.
- Итеративный регресс. В конце каждого спринта выполняется итеративный регресс. Фокус на функциях и апдейтах в приложении, и точках приложения, которые могли “пострадать” от апдейтов.
Чтобы получить максимальный профит от этого метода, должна быть обеспечена качественная коммуникация внутри QA-команды, и с другими командами на проекте.
Приоретизация тестов, исходя из рисков.
В этом методе тесты группируются по приоритетам:
Высокий приоритет. Общее количество регрессионных тест-кейсов с таким приоритетом — около 10%. Это критически важные модули и функции. Стараются найти места потенциальных дефектов, и проверяют модули, где особенно часты были обновления. Это выполняется в первую очередь.
Средний приоритет. Общее количество таких тестов — около 30%. Тест-кейсы с граничными значениями, негативные тест-кейсы и пр. На этом этапе тест-кейсы нацелены на некие “стандартные” для этого приложения баги, которые часто находили в прошлых релизах.
Низний приоритет. Оставшиеся 60% тест-кейсов, проверяется “остаток” функциональности приложения, не такой критически важный.
Больше сотрудничества в приоритизации тестов. Все члены QA-команды могут высказывать свою личную точку зрения о приоритетах, исходя из опыта и компетенций. Каждое изменение в коде проверяется всей командой.
***
Также на сайте: