Что такое регрессионное тестирование?

• Определение
• Когда нужны “регрессы”?
• Виды регрессионного тестирования
• Разница между регрессионным и повторным тестированием (re-testing)
• В чем преимущества регрессионного тестирования
• Подходы
• Составление тест-кейсов
• Сколько “регрессов” нужно?
• Как проводится регрессионное тестирование
• Пример
• Инструменты
• Сложности в процессе
• Лучшие практики
• Приложение: чем регрессионное отличается от дымового

Определение

Кратко: проверка, не повлияли ли изменения кода на существовавшую функциональность.

Подробнее: когда команда устраняет баг, добавляет новую функцию, или улучшает имеющуюся, то, разумеется, при этом будет изменен исходный код приложения. Известно, что даже совсем небольшое изменение исходного кода может привести (и часто приводит) к целому “букету” новых багов. Поэтому тестировщики должны искать и устранять эти “побочные эффекты” — и для этого предназначены регрессионные тесты (“регрессы” на жаргоне тестировщиков). 

Когда нужны “регрессы”?

Как уже сказано выше, когда в существующую кодовую базу были добавлены новые функции и/или улучшения “старых”. «Регресс» предохраняет от новых багов/дефектов уже работающий (протестированный) билд. 

Особенно внимательно проверяют код, в котором есть большие шансы возникновения «ошибок несовместимости» и код, в котором раньше часто возникали ошибки.

Когда проблемный деплой затягивается по каким-то причинам, «регрессы» могут выполняться практически каждый день. Также хорошей практикой является регресс после функционального тестирования еженедельных релизов.

Итак, основная цель — предохранение существующей функциональности от возможных дефектов, создаваемых при обновлении кода. Часто случается ситуация: исправление одного дефекта провоцирует другой дефект; тогда дебаг сочетают с “регрессами”.

Виды регрессионного тестирования

Тип, который будет применяться, зависит от конкретного SDLC-цикла, и особенностей новой/обновленной функции. 

Коррекционное

Простая форма “регресса”, не требующая больших усилий и затрат. Выполняется в случаях, когда в существующую кодовую базу не вносятся большие изменения, а лишь какая-то единичная новая функция. Задача — протестировать существующую функциональность, скорее всего даже “старыми” тест-кейсами без создания новых.

Выборочное

“Селективное регрессионное” анализирует, как сочетается новый код с существующим; например, когда в код включаются новые значимые переменные и функции, проводится быстрая проверка результатов этого.

Прогрессивное

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

Полное

Как уже говорилось выше, даже небольшие изменения в коде способны сильно повлиять на продукт; тем более если код изменился значительно — тогда делают полное регрессионное тестирование, которое должно исправить все “побочные эффекты”.

Частичное

Когда в коде есть небольшие изменения и нужно экономить время; направлено только на критические баги.

Полное повторное регрессионное

Иначе называемое retest-all regression. Повторное выполнение всех тест-кейсов. Из-за большого объема работы такое делается редко.

Регрессионное юнит-тестирование

Код модулей-юнитов «изолируется» и тестируется, а все другие запросы/интеграции/зависимости «отключены». Выполняется, когда нагрузка (или трафик) на приложение не очень большие, обычно в ночное время.

Разница между повторным и регрессионным тестированием

Для новичков эти понятия звучат одинаково, однако их суть отличается. 

Повторное тестирование (re-testing) означает постоянный процесс тестирования отдельных тест-кейсов для устранения багов и подготовки к релизу. Один и тот же набор юнит-тестов многократно повторяется, чтобы проверить функциональность кода. Итак, повторное тестирование — это повторное выполнение автоматизированных (или ручных) тестов с целью гарантировать, что новый билд работает нормально.

Регрессионное тестирование — это проверка нового билда всякий раз при обновлении кода (поступлении коммита). Тестировщик проверяет, что в коде не появились новые баги в результате модификаций и улучшений продукта. После разработки регрессионного тест-сьюта можно (и нужно) автоматизировать его с помощью соответствующих инструментов (об этом далее). В повторном тестировании автоматизация нерелевантна.

Преимущества регрессионного тестирования

Качество программных продуктов довольно сильно зависит от регрессионного тестирования. Как и функциональные тесты, “регресс” должен выполняться на каждом этапе разработки, чтобы держать качество продукта на хорошем уровне. Команды, практикующие DevOps, активно применяют «регрессы» в своем жизненном цикле, не допуская появления дефектов после обновлений кода. Итак, преимущества:

• Упрощает бизнес-операции, контролируя качество продукта после добавления новых функций
• Регрессионные тесты могут выполняться на этапе интеграции, когда изучается взаимодействие нескольких подсистем, находят дефекты сразу в нескольких из них
• Можно автоматизировать ручные регрессионные тесты, экономя время, возможно в несколько раз.
• Раннее обнаружение и устранение багов, что повышает удовлетворенность пользователей, ускоряет релиз и экономит средства
• При правильном проведении достаточно высоки шансы, что модификации кода не ухудшат функциональность уже протестированного ранее кода, что нет «побочных эффектов»

Подходы

Подход, или общая стратегия регрессионного тестирования, чтобы «регресс» прошёл успешно:

• Повторное выполнение всех имеющихся тестов. После релиза тестировщики должны повторно проверить «проблемные области». Это может быть непросто, особенно если речь идёт о ручных тестах, и значит нужна автоматизация.
• Приоритеты. Не менее половины регрессионных тестов должны быть посвящены критически важной функциональности.
• А далее — сложные функции, затрагивающие многие компоненты, качество которых тоже нужно внимательно проверять.
• Исследовательское тестирование при добавлении новых функций.
• Продуманная автоматизация, для ускорения процесса и улучшения продуктивности.
• Рендомное тестирование, проводимое самыми опытными тестировщиками.

Регрессионные тест-кейсы

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

1. Тест-кейсы, ориентированные на часто возникающие баги. Один-единственный коммит способен “поломать” всю функциональность. Также, дефекты имеют свойство “кучковаться” в нескольких модулях. Тестировщик должен помнить основные закономерности, подбирая тест-кейсы, ориентированные на самые частые дефекты и самые критические области. Для этого нужно хорошо знать приложение, его бизнес-логику, и разумеется иметь большой опыт в “регрессах”.
2. Тест-кейсы, ориентированные на критически важные функции. Основная функциональность приложения должна быть всегда “в фокусе”. Например, банковское приложение должно пройти регрессионные тесты платежной подсистемы, навигации, поисковой подсистемы, и подобное.
3. Разумеется, тест-кейсы с последними обновлениями кода, и они должны проводиться неоднократно. Часто обновляемые участки кода — цель регрессионных тест-кейсов по умолчанию.
4. Пользовательский интерфейс и вообще области, видимые пользователю при первом взгляде на приложение/сайт. Особое внимание должно быть уделено логотипу бренда, изображениям, тексту на кнопках, и подобные важные “визуальные” вещи. Такие тест-кейсы имеют приоритет чуть ниже, чем предыдущие в этом списке, но тоже необходимы, ведь это комфорт пользователя, а значит его привязанность к продукту.
5. Связанные с интеграцией модулей. Функциональность одного компонента может зависеть от функциональности другого. Например, если функция компонента С2 зависит от компонента С1, и С1 модифицирован, это повлияет на С2. Поэтому нужны «регрессионные тесты интеграционного характера».
6. Большие сложные тест-кейсы могут вызывать проблемы и быть в целом непродуктивными. Нужно варьировать тестовые техники, грамотно подбирать нужные в данном случае.
7. Учитывать риски. В этом подходе тест-кейсы приоритизируются исходя из рисков; понятно, что риски возникают после обновлений критически важных частей кода.

Приоритетность:

• Высокая. Ключевая функциональность; недавние обновления кода; компоненты с большим риском возникновения багов
• Средняя. Негативные сценарии; например, валидация полей ввода
• Низкая. Например, интерфейс, логотипы, общий вид контента.

Сколько “регрессов” нужно?

В целом, это зависит от объема нового кода, то есть от количества добавляемых/изменяемых функций и частоты этих обновлений/добавлений. Если обновление большое (major), нужны регрессы всех существующих тест-кейсов. Поскольку апдейт значимый, тест-кейсы будут большими и вероятно сложным, не исключено что понадобится автоматизация всех повторяемых тест-кейсов. Для новой функциональности будет нужно постоянное обновление тест-сьютов.

Далее, подбор соответствующих регрессионных тест-кейсов для покрытия всей функциональности приложения. Если обновления масштабные, подобрать релевантные тест-кейсы, учитывая количество обновлений в приложении. 

Как проводится регрессионное тестирование

Этапы:

1. Планирование тест-кейсов, что зависит от количества модулей и объема внесенных модификаций. Можно разделить кейсы на повторно используемые в будущем и однократные. 
2. Оценка времени на выполнение; время на написание и коррекцию.
3. Автоматизация тест-кейсов, в первую очередь ручных малопродуктивных, повторяемых действий.
4. Присвоение приоритетов, учитывая последние изменения кода, стараясь минимизировать время и усилия. 
5. Выполнение согласно приоритетам. Часто применяется Selenium и другие инструменты.

Пример

Рассмотрим гипотетический пример регрессионного тестирования веб-сайта “Теслы”. Он принадлежит компании с многомиллиардным оборотом, и часть продаж идут через сайт. Представим, какой объем регрессионных тестов нужен такому сайту?

Во первых, понятно, что сайт должен быть всегда “up and running”, что касается функциональности, надежности и юзабельности.

На главной странице видим ссылки на все модели:

Когда компания выпустит новый продукт, тот же CyberTruck, разработчики добавят соответствующий новый элемент на сайт (например справа от Model Y). После этого понадобится проверка, что после добавления нового элемента “CyberTruck” остальная часть функциональности продолжит работать нормально. Тестировщики проведут регрессионные тесты, автоматические и ручные, например в Selenium. Может случится так, что один из этих тестов упадет. Это будет означать, что существующая функция сайта упала при добавлении нового продукта. Это баг, и он должен быть заведен и устранен. Далее регрессионный тест-сьют должен выполняться каждый раз, когда будет небольшое (и тем более большое) изменение списка моделей на сайте “Теслы”. Далее если будут еще какие-то изменения на сайте, тест-сьют (набор) будет обновляться и “покрывать” эти изменения.

Инструменты

Выбор инструмента зависит от проекта. Наиболее часто применяемые:

Selenium

Открытый инструмент автоматизации веб-сайтов и веб-приложений. Практически главный инструмент в этой сфере. Поддерживает все браузеры и платформы. 

Selenium

Watir

Фреймворк на Ruby для веб-приложений. Открытый код. Автоматизация тестирования браузеров. Применяется для регрессионных тест-сьютов.

Watir

Serenity BDD

Тоже с открытыми исходниками. Качественные автотесты — приемочные, но также и регрессионные. Гибкий настраиваемый процесс тестирования и далее обслуживания автотестов. Хорошая система репортов, особенно по тестовому покрытию.

Serenity BDD

Silk Test

Функциональные и регрессионные тесты вплоть до корпоративного уровня. Кросс-платформенные тесты, также регресс-тесты локализации мобильных приложений (включая веб-, нативные и гибридные).

Silk Test

QA Wizard Pro

Инструмент для функциональных и регрессионных тестов веб-, Windows- и Java-приложений. Также нагрузочное тестирование.

QA Wizard Pro

Сложности

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

• Сложные комплексные тест-кейсы: с расширением проекта увеличивается количество тест-кейсов и их сложность. Затрачивается больше времени и ресурсов. Когда проект/приложение расширяется/масштабируется, растет сложность регрессионных тест-сьютов, которым требуется постоянная проверка и коррекция, чтобы держать в рамках сложность и время выполнения

Лучшие практики

• С внедрением новых функций нужно грамотно корректировать регрессионные тест-сьюты, и в их составе те тесты которые проверяют “старую” функциональность

• Проверка функций и возможностей, наиболее активно применяемых пользователями, и включение их в кейсы, чтобы контролировать их функциональность

• Применение специальных инструментов/фреймворков

• Обновление тест-дизайнов, анализируя фидбек разработчиков и пользователей

• Автоматизация, экономящая время и деньги, ускоряющая релиз

• При возможности, перенос части регрессионных тестов в облачные платформы

Приложение: чем отличается регрессионное тестирование от дымового (smoke) тестирования

Характеристики дымового тестирования: 

Базовое тестирование нового билда. Поле завершения становится ясно, что ключевая функциональность продукта работает «в целом нормально». Если же продукт не проходит дымовое, его возвращают разработчикам. Проверяются самые важные, «опорные» функции, перед тем как приступить к более тщательному функциональному тестированию. Дымовое тестирование делают на первых этапах цикла и поверхностно, поэтому смок-тестирование еще называют «поверхностным тестированием», а также «тестированием верификации билда» (сборки), поскольку это как бы экспресс-проверка начального билда.

Пример дымового тестирования:

Сайт заказа билетов. Smoke-тестирование проверяет, работают ли базовые функции: регистрация и вход на сайт под своим логином, установка и изменение пароля, заказ билетов, отмена заказа, как работают уведомления на почту, и подобное основное.

Характеристики регрессионного тестирования, отличающие его от дымового: 

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

Быстрый пример «регресса»

Регрессионное тестирование упомянутого выше сайта: 

Будут протестированы базовые функции, но в первую очередь — модули, затронутые недавними изменениями в коде; например если был изменен модуль заказа билетов, доработан модуль геолокации, и добавлен модуль промокодов — эти модули будут объектом регрессионного тестирования.

Разница между регрессионным и дымовым тестированием (таблица)