Как эффективно провести регрессионное тестирование

Регресс — скучная и иногда пугающая часть работы тестировщиков, без которой не обойтись. За счет чего можно сократить время регресса, как контролировать этот процесс и о каких возможных трудностях стоит знать заранее? QA-инженер IT Test Алиса Мордвинова рассказывает, что делать, чтобы регрессионное тестирование проходило гладко.

Сокращаем время прохождения регресса

Перед началом регресса следует помнить, что это командная работа. Поэтому для успешного результата работать нужно сообща и не забывать — каждому может понадобиться помощь. Вот, что можно сделать, чтобы регресс прошел быстрее.

Подготовить задачи заранее.

Составьте список задач, которые реализуются к регрессу. Если все участники процесса знают, какие задачи будут в регрессе, — это не станет неожиданностью и стрессом. Лучше заранее продумать, к кому можно обратиться за помощью или что изучить.
Отслеживайте уровень разработки задач. По мере продвижения в разработке новых функций или доработок можно сразу оценить, какие кейсы пойдут на проверку. Если их не прописали во время основного тестирования, это можно сделать перед регрессом, чтобы не тратить время в процессе него.
Создавайте тестовые аккаунты для быстрого прохождения тестовых кейсов при регрессе. Чем сложнее приложение, тем более сложные и многоуровневые аккаунты в нем у пользователей. Ситуация, когда одни условия в кейсе исключают другие и наоборот, — обычная практика.

Однако создать такое условие может быть проблематично. Например, у пользователя приложения есть задолженность по продукту, и она достигается путем движения дат в стороннем сервисе. Смоделировать такую ситуацию сможет не каждый сотрудник даже с доступом к этому сервису.

О создании всех условий для кейса тестировщику стоит позаботиться заранее, потому что в нужный момент всё может пойти не так — сервис будет недоступен, человек занят и так далее. У каждого тестировщика должно быть несколько тестовых аккаунтов, чтобы между ними можно было проводить разные операции.

Пройти автотесты перед ручным регрессом с воспроизведением упавших кейсов вручную вместе с мануальными тестировщиками — это сэкономит время и силы.
Создать один тест-ран с кейсами на всех в определенной последовательности.

Создается тест-ран, необходимый для проверки реализуемых задач.
Каждый берет на себя тест-кейсы, которые ему назначены. Обычно это те задачи, в которых человек разбирается лучше всего, особенно если они связаны со сложными функциями. Однако есть кейсы, которые невозможно выполнить любому. Например, пройти верификацию в узбекском банке смогут только граждане Узбекистана.
Если кто-то из команды не успевает со своими кейсами, можно помочь. Благодаря одному тест-рану, виден прогресс всех.

Выполнить непройденные кейсы, после окончания своих. Важно не забыть согласовать эти кейсы с командой.

Система управления тестированием DoQA может стать инструментом, который поможет вам сделать регрессионное тестирование упорядоченнее и быстрее. Попробуйте DoQA бесплатно — пробный период на 30 дней доступен.

Контролируем процесс регресса

Регресс — такой же важный процесс, как разработка или тестирование. За ним необходимо наблюдать, корректировать, направлять. Вот какие способы контроля можно использовать.

Ежедневные синки.

Нужны для уточнения процента выполнения, обозначения сроков, обсуждения проблем и поиска быстрых решений.

Созвоны при прогоне мелких кейсов.

С помощью них можно ускорить выполнение некоторых задач. Например, при проверке флоу смены номера телефона или пароля для разных типов пользователей на разных девайсах. У каждого тестировщика на руках есть креды — логины и пароли — тестовых пользователей с разными настройками, на которых можно проверить некоторые кейсы. Таким образом за счет командной работы можно быстро пройти кейсы, на которые ушло бы больше сил.

Договоренность о проверке определенных кейсов при переключении настроек на бэкенде. Этот шаг выполняется в начале или в конце тестирования, в зависимости от сложности внесенных изменений, если они были, и состоит из таких этапов:

подготовка тест-кейсов и аккаунтов для проверки;
согласование дня и времени;
уточнение трудностей;
прогон кейсов группой или по отдельности. Оперативно происходит возврат настроек на бэке, например, при увеличении или уменьшении времени жизни токена в тестовой среде. При необходимости заводятся баги, оставляются комментарии в тест-кейсе для дальнейших работ, например, корректировки тест-кейсов.

Устраняем проблемы

Тест-кейсы не в актуальном состоянии.

Их много, не всегда удается успевать за фичами или правками, а еще не все любят писать тест-кейсы. Поэтому стоит выделять обязательное время на корректировки.

Нет подходящих тестовых аккаунтов.

Тестовые аккаунты могут испортить, забрать или удалить. Поэтому каждому тестировщику стоит иметь несколько аккаунтов для тестов. А еще хорошая практика — аккаунты для тестирования на проде, чтобы можно было зайти и посмотреть, как выглядят экраны, баннеры или продукты. На это придется выделить деньги, но оно того стоит.

Нехватка времени.

Тестировщиков часто просят помочь с другими задачами, где-то подсказать или что-то настроить. На это бывает уходит половина дня, из-за чего время на прохождение регресса увеличивается. Хорошей практикой может стать разделение: два часа работы, один час ответов на вопросы. Таким образом и работа делается, и коллеги без ответов не остаются.

Несвоевременная проверка релизной сборки с залитыми исправленными багами.

О срочности правки багов стоит сообщить тимлиду разработчиков, чтобы он скорректировал работу.

Если вы участвуете в регрессе, вы так или иначе на него влияете. Соответственно все сложности с которыми столкнулись вы, вероятно, были и у ваших коллег. Чтобы избежать повторения негативных моментов в будущем, не стесняйтесь предложить вашей команде провести ретроспективу по регрессу или хотя бы, чтобы каждый сообщил о проблемах, с которыми столкнулся. Все возникшие сложности можно собрать воедино и провести общее обсуждение. Каждый сможет предложить способы их исправить. Даже если не всё удастся решить, быть услышанным тоже очень важно.