Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье для новичка о нем рассказывается. Вроде бы можно закрыть тему… Но почти каждый раз, когда на собеседовании я задаю вопрос: «Как мне выбрать тесты для регресса?», четкого ответа я не получаю. Это не зависит от уровня тестировщика, его опыта и направления.
Из интереса я пристала к разработчикам, аналитикам, менеджерам и архитекторам с этим же вопросом, но получила лишь размытые формулировки и жалобы на то, что мы слишком долго проводим регресс и давно пора все автоматизировать. Такое происходит, потому что с виду простой вопрос содержит множество уровней, о которых обычно нет времени задуматься. Меня зовут Алена Вахтина и я ведущий специалист по тестированию в Лиге Цифровой Экономики. В этой статье постараюсь хотя бы частично рассмотреть такие подводные камни регрессионного тестирования.
Что такое регрессионное тестирование. Теория и практика
Если открыть курсы для подготовки к сдаче ISTQB, то можно увидеть следующие определения: «Регрессионное тестирование (regression testing):Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. [ISTQB Глоссарий 2.3]».
Исходя из этого определения, можно сказать, что проведением регрессионного тестирования можно считать ситуацию, когда ты тестировал какую-то фичу и решил дополнительно проверить часть программы, потому что она могла сломаться. В реальности мы так не считаем.
Чаще всего под регрессионным тестированием понимается полное тестирование программы после окончания разработки в спринте и до вывода его на прод.
Перед тем стартом регресса совершается несколько дополнительных шагов:
отбитие релиза или релизной ветки;
вывод релиза на специальную тестовую среду, схожую с продуктивной.
После этого начинается регресс — бич любого тестировщика. Ведь это от одного и больше дней прохождения тестов, которые ты делал в прошлом спринте. Так для чего же его проходить? Как минимум для следующего:
для уверенности в релизной сборке;
для того, что проверить, что новые фичи не затронули старый код.
Плюсы явно перевешивают минусы. Так и получается: с ним сложно, а без регресса практически невозможно. Как говорится, «мыши плакали, кололись, но продолжали грызть кактус».
Какие тесты подбирать
Что такое регресс и зачем он нужен — вспомнили, теперь перейдем к основному вопросу: какие тесты должны входить в регресс. В свою очередь эта проблема делится на две:
Какие тесты выбрать для регресса?
Какими должны быть тесты по размеру, признакам и правилам оформления?
В регресс, можно сказать, должны попадать все тесты, которые были написаны на проекте. Если их всего три и вы только начинаете формировать список, то, это подходящий сценарий. А если больше ста или тысячи и регресс занимает не день и не два? Чтобы поддерживать такой большой список тестов в актуальном состоянии, нужно весь спринт заниматься только им.
Часто еще случается, что на вялотекущем проекте остается один тестировщик, которому досталось в наследство это большое количество тестов и багов. Как в такой ситуации не взвыть от отчаяния и не погибнуть под тяжестью регресса? Просто: не нужно запихивать в него все тесты.
Разделим регресс на две большие части:
ядро регресса;
тесты, проверяющие новый функционал.
Со второй частью все понятно. Добавляем все тесты, которые затрагивают новые фичи и исправленные баги. Обычно их не больше десяти штук, что примерно равно количеству задач, сделанных за спринт.
Теперь перейдем к ядру. Какие тесты должны туда попадать? Те, которые касаются основного функционала. Например, если вы тестируете интернет-магазин, то там точно нужна проверка просмотра товара, добавления его в корзину и оплата. А вот рекламная рекламная акция, приуроченная к Новому году, туда не войдет — особенно если сейчас лето.
Остановиться лучше на тестах, которые повторяют наиболее частые действия пользователей. Еще у нас в регрессе бывают тесты, которые касаются каких-то критичных пропущенных в прод ошибок, потому что это означает, что ту часть мы не покрыли тестами по той или иной причине. Но мы их периодически чистим, заменяя на обычные тесты по некогда сломанному функционалу.
Список тестов в регресс составили. Теперь нужно проверить, подходят ли тесты, которые мы отобрали, удобно ли их проходить. Или на один тест мы потратим весь день, а оставшиеся тридцать в списке так и не останутся не проверенными.
Для того, чтобы тест было легко пройти, следует соблюдать несколько простых правил. Их для себя я вывела, когда ревьюила или проходила чужие тесты. Список не полный, его можно дополнять, менять под себя:
тест не должен быть завязан на другой тест (если ранее должен быть создан какой-нибудь объект, то его лучше отдельно описать в приложенном файле или в описании к тесту);
в описании должен быть логин и пароль пользователя, который работает в системе;
необходимо четко прописать, как заполняются поля в столбике «данные теста», если в тест включаются какие-либо данные. Так, если в тесте нужно заполнить, например, поле «дата», не являющаяся обязательным, то во втором столбце это должно быть отмечено;
один шаг должен содержать ровно одно действие. Если описаны два, то их нужно разделить, исключение могут составить переходы по страницам;
если в тесте есть ссылка на загрузку файла или картинки, то нужно не забыть прикрепить образец;
в шагах желательно иметь четкие формулировки (например, слово «попробовать» не должно фигурировать в тесте);
в тестах не должно быть формулировки «в альтернативном случае», для этого нужен другой тест;
если в тесте упоминается запрос в БД, то его нужно прописать полностью в столбике «данные теста»;
желательно в тестах не смешивать front и back части, т. е. не должно быть описания работы через клиентскую часть и сразу же запроса curl (Postman);
шаги из описаний лучше вынести в шаги теста;
желательно, чтобы шагов в тесте было не больше 10-12;
по возможности тест должен касаться одной предметной области.
Как я уже сказала, могут быть еще другие правила. Можете указать их в комментариях, а я тем временем продолжу.
Сколько тестов должно быть в регрессе
Осталось понять, сколько тестов должно быть в регрессе. Для этого рассмотрим простую математическую задачу. Возьмем среднего тестировщика, проходящего средний тест длиной в 10 шагов.
Допустим, ему требуется 10 минут на прохождение всех шагов. Добавим выполнение всех предусловий — еще 5 минут, вероятность нахождения с последующим оформлением бага — также дополнительно 5 минут (естественно, на ловлю бага нужно больше времени, но учитывается, что он есть не в каждом тесте). В сумме получилось 20 минут. Значит, за час сферический тестировщик в вакууме проходит три теста. Следовательно, за день он пройдет 8*3=24 теста. В реальности обычно получается меньше с учетом остальных задач — люди в среднем проходят от 10 до 20 тестов.
Со средней производительностью одного человека определились. Теперь посчитаем, сколько человек у нас в команде. Чаще всего это один человек, изредка — два или три. Пока запомним это число, вскоре оно нам понадобится.
Осталось ответить на последний вопрос: сколько дней можно потратить на регресс? Обычно при спринтах в 2 недели, чтобы тестировщики не выпадали из работы команды, на регресс отводится от 1 до 2 дней.
Теперь считаем: 20 (пусть у нас будут очень продуктивные тестировщики)* 2 (два тестировщика в команде) *2 (берем максимальное количество дней) = 80 тестов.
Отлично, 80 тестов в рамках среднего проекта вполне достаточно для практически полного покрытия. Однако я уверена, что мне сейчас возразят, что есть такая вещь, как автоматизация. И будут правы.
Что по автоматизации регресса
Автоматизировать регресс нужно — это постулат. Что же еще автоматизировать, как не постоянно повторяющейся процесс, имеющий особую цену для качества продукта? Так что, как только появляются первые тесты регресса, начинаются разговоры об автоматизации. Логично? Да. Вот только можно ли начинать автоматизацию сразу же?
Я склоняюсь к ответу нет. Чаще всего первые регрессионные тесты появляются в момент, когда разработка продукта активно ведется. В таком случае поддерживать автоматизированные тесты будет дороже, чем проводить регрессионное тестирование вручную: слишком быстро меняется код, и на правку одного теста будет уходить больше времени, чем на написание нового.
Когда же тогда нужно приступать к тестированию? На мой взгляд, самый подходящий момент — покрывать регресс автотестами, когда появился хотя бы один стабильный модуль, вероятность изменения которого низка. В таком случае время на прохождение регресса снизится за счет автоматизации, но не будет большого прироста расходов на правки автоматизированных тестов.
Бывает противоположная ситуация. Проект существует давно, написаны сотни ручных тестов, и нужно бы начать автоматизировать. Тогда возникают следующие вопросы:
С чего начать?
Какой процент тестового покрытия можно заменить автотестами?
Какие тесты лучше писать — UI или REST?
и т. д.
Ответов на эти вопросы на Хабре множество. Можно начать, например, с этой статьи. Или другой, или этой. От себя добавлю, что главное — с чего-то начать, например, выбрать хотя бы первые 10 тестов. Через год уже половина регресса будет покрыта, если не забивать на это дело.
На этом все. Надеюсь, хотя бы немного разложила процесс регресса по полочкам, и теперь начинать новый цикл регрессионного тестирования будет не так страшно. Удачи!
