Блог A1QA

О тестировании и качестве ПО

Регрессионное тестирование: цели, подходы, этапы проведения

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

Начнем. Изменения в коде неизбежно сопровождают процесс разработки программного обеспечения. Добавляется новая функциональность, вносятся изменения в существующую, устраняются дефекты. При этом любые изменения могут затронуть и уже существующую функциональность, которая исправно работала. Проверить, чтобы изменения не «поломали» рабочее ПО, задача регрессионного тестирования.

Цель регрессионного тестирования – удостовериться в том, что существующая функциональность не была затронута изменениями в коде.

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

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

Этот пример демонстрирует место регрессионного тестирования в процессе разработки ПО.

Регрессионное тестирование и методологии управления проектами

Рассмотрим, как на проведение регрессионного тестирования влияет методология проекта. Возьмем для примера три самых популярных: гибкую, каскадную и гибридную.

Гибкая методология (Agile)

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

В чем трудность? Жесткие дедлайны и задержки при разработке оставляют меньше времени на тестирование, чем требуется.

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

Каскадная методология (Waterfall)

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

В чем трудность? Вносить изменения в готовый продукт – трудоемкий и дорогостоящий процесс. Неудивительно, что каскадная модель применяется на небольших проектах с четкими требованиями, которые не меняются в процессе разработки.

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

Рекомендуем доверять тестирование требований независимым специалистам, которые объективно оценят требования, дадут рекомендации по их оптимизации. Ведь устранение ошибок в требованиях – это исправление в тексте. Исправление ошибок в готовом продукте – это часы работы разработчиков и тестировщиков.

Гибридная методология

Все преимущества гибкой и каскадной методологий объединила в себе гибридная методология управления проектами. Этапы планирования и определения требований проходят согласно каскадной методологии, а этапы проектирования, разработки, внедрения и оценки – согласно гибкому подходу.

Соответственно, на разных стадиях проекта будет выполняться полное или частичное регрессионное тестирование.

7 стадий регрессионного тестирования

Независимо от того, какой методологии придерживаетесь вы, изменения ПО требуют выполнения регрессионного тестирования, состоящего из следующих стадий:

  1. Анализ внесенных изменений, требований и поиск областей, которые могли быть затронуты;
  2. Составление набора релевантных тест-кейсов для тестирования;
  3. Проведение первого раунда регрессионного тестирования;
  4. Составление отчета о дефектах;

Каждый дефект вносится в баг-трекинговую систему, описываются шаги для его воспроизведения. Если возможно, описание сопровождается видео, скриншотами.

  1. Устранение дефектов;
  2. Верификация дефектов.

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

  1. Проведение второго круга регрессионного тестирования.

Исходя из опыта команды A1QA, в среднем требуется не менее трех раундов регрессионного тестирования для устранения всех дефектов и стабилизации приложения.

Регрессионное тестирование: ручное или автоматизированное?

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

Однако несмотря на востребованность автоматизации, ручное регрессионное тестирование также имеет место быть.

Ручное тестирование

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

Однако если проект разрастается, функциональность ПО увеличивается с каждым последующим релизом, это влечет за собой увеличение объемов тестирования. В таком случае стоит задуматься о привлечении специалистов по автоматизации.

Автоматизация тестирования

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

Выгоду автоматизации тестирования нельзя недооценивать:

  • Улучшается качество продукта;
  • Ускоряется выпуск продукта на рынок;
  • Оптимизируется стоимость тестирования.

Здесь история о том, как команда A1QA смогла на 40% уменьшить трудозатраты на регрессионное тестирование, внедрив автоматизацию.

Кстати, есть и такие проекты, на которых разумно совместить ручные проверки с автоматизированными. Все зависит от специфики программного продукта.

Подведем итог

Согласно отчету World Quality Report 2017, в среднем 26% всего ИТ-бюджета компаний идет на тестирование. Опыт компании A1QA говорит о том, что 40-70% этих затрат приходится на регрессионное тестирование.

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

Как подобрать стратегию тестирования, оптимальную для вашего ПО? Спросите у нас! Получить бесплатную консультацию QA-специалиста.

Поделиться статьей: