Регресс — скучная и иногда пугающая часть работы тестировщиков, без которой не обойтись. За счет чего можно сократить время регресса, как контролировать этот процесс и о каких возможных трудностях стоит знать заранее? QA-инженер IT Test Алиса Мордвинова рассказывает, что делать, чтобы регрессионное тестирование проходило гладко.
Обновление DoQA 4.3 (Titanium)
Релиз для автоматизаторов: раздел «Автотесты», запуск в GitLab, Jenkins и TeamCity, Quality Gate и глобальный поиск
Как эффективно провести регрессионное тестирование

Сокращаем время прохождения регресса
Перед началом регресса следует помнить, что это командная работа. Поэтому для успешного результата работать нужно сообща и не забывать — каждому может понадобиться помощь. Вот, что можно сделать, чтобы регресс прошел быстрее.
- Подготовить задачи заранее.
- Составьте список задач, которые реализуются к регрессу. Если все участники процесса знают, какие задачи будут в регрессе, — это не станет неожиданностью и стрессом. Лучше заранее продумать, к кому можно обратиться за помощью или что изучить.
- Отслеживайте уровень разработки задач. По мере продвижения в разработке новых функций или доработок можно сразу оценить, какие кейсы пойдут на проверку. Если их не прописали во время основного тестирования, это можно сделать перед регрессом, чтобы не тратить время в процессе него.
- Создавайте тестовые аккаунты для быстрого прохождения тестовых кейсов при регрессе. Чем сложнее приложение, тем более сложные и многоуровневые аккаунты в нем у пользователей. Ситуация, когда одни условия в кейсе исключают другие и наоборот, — обычная практика.
Однако создать такое условие может быть проблематично. Например, у пользователя приложения есть задолженность по продукту, и она достигается путем движения дат в стороннем сервисе. Смоделировать такую ситуацию сможет не каждый сотрудник даже с доступом к этому сервису.
О создании всех условий для кейса тестировщику стоит позаботиться заранее, потому что в нужный момент всё может пойти не так — сервис будет недоступен, человек занят и так далее. У каждого тестировщика должно быть несколько тестовых аккаунтов, чтобы между ними можно было проводить разные операции.
- Пройти автотесты перед ручным регрессом с воспроизведением упавших кейсов вручную вместе с мануальными тестировщиками — это сэкономит время и силы.
- Создать один тест-ран с кейсами на всех в определенной последовательности.
- Создается тест-ран, необходимый для проверки реализуемых задач.
- Каждый берет на себя тест-кейсы, которые ему назначены. Обычно это те задачи, в которых человек разбирается лучше всего, особенно если они связаны со сложными функциями. Однако есть кейсы, которые невозможно выполнить любому. Например, пройти верификацию в узбекском банке смогут только граждане Узбекистана.
- Если кто-то из команды не успевает со своими кейсами, можно помочь. Благодаря одному тест-рану, виден прогресс всех.
- Выполнить непройденные кейсы, после окончания своих. Важно не забыть согласовать эти кейсы с командой.
Система управления тестированием DoQA может стать инструментом, который поможет вам сделать регрессионное тестирование упорядоченнее и быстрее. Попробуйте DoQA бесплатно — пробный период на 30 дней доступен.
Контролируем процесс регресса
Регресс — такой же важный процесс, как разработка или тестирование. За ним необходимо наблюдать, корректировать, направлять. Вот какие способы контроля можно использовать.
- Ежедневные синки.
Нужны для уточнения процента выполнения, обозначения сроков, обсуждения проблем и поиска быстрых решений.
- Созвоны при прогоне мелких кейсов.
С помощью них можно ускорить выполнение некоторых задач. Например, при проверке флоу смены номера телефона или пароля для разных типов пользователей на разных девайсах. У каждого тестировщика на руках есть креды — логины и пароли — тестовых пользователей с разными настройками, на которых можно проверить некоторые кейсы. Таким образом за счет командной работы можно быстро пройти кейсы, на которые ушло бы больше сил.
- Договоренность о проверке определенных кейсов при переключении настроек на бэкенде. Этот шаг выполняется в начале или в конце тестирования, в зависимости от сложности внесенных изменений, если они были, и состоит из таких этапов:
- подготовка тест-кейсов и аккаунтов для проверки;
- согласование дня и времени;
- уточнение трудностей;
- прогон кейсов группой или по отдельности. Оперативно происходит возврат настроек на бэке, например, при увеличении или уменьшении времени жизни токена в тестовой среде. При необходимости заводятся баги, оставляются комментарии в тест-кейсе для дальнейших работ, например, корректировки тест-кейсов.
Устраняем проблемы
- Тест-кейсы не в актуальном состоянии.
Их много, не всегда удается успевать за фичами или правками, а еще не все любят писать тест-кейсы. Поэтому стоит выделять обязательное время на корректировки.
- Нет подходящих тестовых аккаунтов.
Тестовые аккаунты могут испортить, забрать или удалить. Поэтому каждому тестировщику стоит иметь несколько аккаунтов для тестов. А еще хорошая практика — аккаунты для тестирования на проде, чтобы можно было зайти и посмотреть, как выглядят экраны, баннеры или продукты. На это придется выделить деньги, но оно того стоит.
- Нехватка времени.
Тестировщиков часто просят помочь с другими задачами, где-то подсказать или что-то настроить. На это бывает уходит половина дня, из-за чего время на прохождение регресса увеличивается. Хорошей практикой может стать разделение: два часа работы, один час ответов на вопросы. Таким образом и работа делается, и коллеги без ответов не остаются.
- Несвоевременная проверка релизной сборки с залитыми исправленными багами.
О срочности правки багов стоит сообщить тимлиду разработчиков, чтобы он скорректировал работу.
Если вы участвуете в регрессе, вы так или иначе на него влияете. Соответственно все сложности с которыми столкнулись вы, вероятно, были и у ваших коллег. Чтобы избежать повторения негативных моментов в будущем, не стесняйтесь предложить вашей команде провести ретроспективу по регрессу или хотя бы, чтобы каждый сообщил о проблемах, с которыми столкнулся. Все возникшие сложности можно собрать воедино и провести общее обсуждение. Каждый сможет предложить способы их исправить. Даже если не всё удастся решить, быть услышанным тоже очень важно.
Начните работу в облачной версии DoQA прямо сейчас
14 дней бесплатно без ограничений по функциональности.
Войти в систему
Вам может быть интересно
Подпишитесь на рассылку DoQA
Будем отправлять подборки статей о тестировании, анонсы митапов и новости системы. Никакого спама — только полезные материалы.
Начните работу в облачной версии DoQA прямо сейчас
14 дней бесплатно без ограничений по функциональности в облачной версии системы
Попробовать

















