Каждый, кто работает в тестировании, наверняка знает о том, что перед релизом требуется проводить “регресс”. Это такой вид тестирования, который позволяет выявить баги, рожденные в процессе разработки. Такие баги затрагивают функционал, который, казалось бы, не должен был пострадать.
Хорошим тоном считаются подготовленные заранее сценарии регрессионного тестирования, тест-сьюты либо набор юзкейсов. Несмотря на это, на некоторых проектах я сталкивалась с тем, что тестировщики начинали отклоняться от заданного курса и занимались просто поиском багов параллельно с тест-кейсами регресса. А в некоторых ситуациях регресс приходится проходить и вовсе без пошагового планирования. Это особенно актуально для “молодых” проектов, а также для продуктов, существовавших до этого вообще без тестирования. В таком случае тестировщики обычно пускаются в “вольное плаванье” по продукту.
Почему я против такого подхода?
Время на регресс практически всегда ограничено жёсткими рамками – заказчик/продакт хочет “выкатить” на прод релиз здесь и сейчас, а не ждать неделю, пока команда тестирования даст добро. Именно поэтому важно заранее согласовать сценарии и время.
Ведь часто регрессионное тестирование для заказчика/продакта выглядит бесполезным – на него уходит не один час, при этом команда обеспечения качества проводит его регулярно. В ходе тестирования может набежать большое количество багов low и lowest приоритетов (которые будут пофикшены точно не в ближайшие месяцы, но на поиски которых ушло несколько дней). Некоторым кажется, что это время уходит впустую. Поэтому важно экономить время, которое тратится на прохождение регресса.
Регресс считается законченным именно тогда, когда пройдены все сценарии, и время на их прохождение в большинстве случаев согласовано с заказчиком или продактом. Но если на каждый тест-кейс тестировщик будет тратить больше запланированного на прохождение времени, то в итоге не будет проверен ключевой функционал программы, а это, очевидно, чревато пропущенными багами, с которыми обязательно столкнется пользователь продукта.Это одна из причин, по которой отклоняться от плана – не самая лучшая идея.
Как же провести регресс без готового плана тестирования, не уходя при этом в свободное тестирование?
1. В первую очередь проверяем позитивные кейсы.
Данное правило работает не только для регресса, но и для всех других видов тестирования. Нужно убедиться в том, что продукт может делать то, ради чего он создан, и что в текущем билде не блокируется функционал.
2. Далее необходимо проверить то, на что с прода чаще всего приходят жалобы
В данное правило входят критические баги на проде, из-за которых выкатывались срочные фиксы, а также жалобы пользователей в отзывах (если проект является публичным) или обратной связи (если проект используется для внутренних нужд компании) по продукту. Если проект недавно родился, то можно поискать отзывы по похожим продуктам и изучить то, на что жалуются пользователи (отзывы в магазинах приложений, на сайтах-отзовиках и в статьях-обзорах).
3. Популярные негативные кейсы.
Это такие кейсы, с которыми точно столкнется некоторый процент пользователей. Например, закрытие приложение во время оформления заказа в интернет-магазине, сворачивание и разворачивание приложение, чистка куков в браузере во время прохождения основного кейса, отключение компьютера от интернета и другие. Эти кейсы зависят от типа приложения, платформы и есть в свободном доступе в сети (в будущем я обязательно сделаю подборку таких тест-кейсов).
А когда же проводить исследовательское и ad hoc тестирование?
Оба варианта исключают планирование, поэтому можно долго тестировать, скажем, одну единственную форму регистрации на сайте, но так и не добраться до оформления заказа до планового окончания регресса.
Вывод, который я очень хочу донести до новичков: если осталось свободное время после того, как сделали пункты, описанные выше, в предыдущем разделе, занимаемся исследовательским и ad hoc тестированием продукта. Например, можно погуглить готовые обобщенные чек-листы для текстовых полей, поисковых строк и других элементов приложения по которым нужно сделать исследовательские туры. Почти всегда тут можно найти баги (чаще всего низкого приоритета). Либо включить интуицию и уйти в ad hoc.
