В данной статье мы расскажем о виде тестирования, который обычно воспринимается как должное и редко вызывает вопросы. Однако, на наш взгляд, руководители ИТ-проектов должны знать, что такое регрессионное тестирование как и для чего оно проводится. Понимание процесса даст возможность разработать грамотную стратегию, снизить расходы на тестирование и получить продукт высокого качества.
Начнём. Изменения в коде неизбежно сопровождают процесс разработки программного обеспечения. Добавляется новая функциональность, вносятся изменения в существующую, устраняются дефекты. При этом любые изменения могут затронуть уже существующую функциональность, которая исправно работала. Проверить, чтобы изменения не «поломали» рабочее ПО, – задача регрессионного тестирования.
Цель регрессионного тестирования – это удостовериться в том, что существующая функциональность не была затронута изменениями в коде.
Приведём пример
регрессионного тестирования, расскажем в каких ситуациях применяется регрессионное тестирование. Представьте, что ваша команда разработала простое приложение-фонарик. В приложении есть всего две функции: включение и выключение фонарика. Вы проводите тестирование функциональности, чтобы убедиться в правильной работе этих функций и приложения в целом. Результат тестирования положительный – вам не о чем беспокоиться.
Спустя какое-то время вы решаете усовершенствовать приложение, добавив в него функцию включения от того, что пользователь встряхивает телефон. Новая функциональность добавлена, проводится очередной раунд тестирования. Однако на этот раз вам необходимо проверить работоспособность не только новой функциональности, но и включения/выключения. А вдруг изменения затронули и её каким-то образом?
Этот пример демонстрирует место регрессионного тестирования в процессе разработки ПО.
Регрессионное тестирование и методологии управления проектами
Рассмотрим, как на проведение регрессионного тестирования влияет методология проекта. Возьмём для примера три самых популярных: гибкую, каскадную и гибридную.
Гибкая методология (Agile)
Agile тестирование ведётся короткими итерациями (спринтами), продолжительностью 4–6 недель каждая. В конце каждой итерации заказчик получает готовый продукт, который может выполнять определённые функции. В идеале регрессионное тестирование проводится в конце каждого спринта, но на деле так происходит редко.
В чём трудность? Жёсткие дедлайны и задержки при разработке оставляют меньше времени на тестирование, чем требуется.
Решение. В конце каждого спринта проводится регрессионное тестирование с частичным покрытием, проверяются области, которые с большей долей вероятности могли быть затронуты разработкой. Перед крупными релизами проводится регрессионное тестирование всего продукта.
Каскадная методология управления проектами (Waterfall)
Каскадная методология предполагает переход к следующему этапу только после полного завершения предыдущего. Таким образом, тестирование начинается после окончания разработки.
В чём трудность? Вносить изменения в готовый продукт – трудоёмкий и дорогостоящий процесс. Неудивительно, что каскадная модель применяется на небольших проектах с чёткими требованиями, которые не меняются в процессе разработки.
Решение. До того как начать процесс разработки, рекомендуется провести тестирование требований и убедиться, что они обладают всеми характеристиками качественных требований: единичностью, актуальностью, выполнимостью и т. д.
Рекомендуем доверять тестирование требований независимым специалистам, которые их объективно оценят и дадут рекомендации по оптимизации. Ведь устранение ошибок в требованиях – это исправление в тексте. Исправление ошибок в готовом продукте – это часы работы разработчиков и тестировщиков.
Гибридная методология
Все преимущества гибкой и каскадной методологий объединила в себе гибридная методология управления проектами. Этапы планирования и определения требований проходят согласно каскадной методологии, а этапы проектирования, разработки, внедрения и оценки – согласно гибкому подходу. Соответственно, на разных стадиях проекта будет выполняться полное или частичное регрессионное тестирование.
7 стадий регрессионного тестирования
Независимо от того, какой методологии придерживаетесь вы, изменения ПО требуют выполнения регрессионного тестирования, состоящего из следующих стадий:
- Анализ внесённых изменений, требований и поиск областей, которые могли быть затронуты.
- Составление набора релевантных тест-кейсов для тестирования.
- Проведение первого раунда регрессионного тестирования.
- Составление отчета о дефектах.
Каждый регрессионный баг вносится в баг-трекинговую систему, описываются шаги для его воспроизведения. Если возможно, описание сопровождается видео, скриншотами.
- Устранение дефектов.
- Верификация дефектов.
На этой стадии QA-инженеры проверяют, действительно ли дефект исправлен. Если проблема остается, создаётся новый отчет. В некоторых случаях устранение дефекта подлежит обсуждению. Все критические и значительные дефекты должны быть устранены обязательно, а вот минорные, устранение которых требует больших затрат, могут быть оставлены. Особенно в тех случаях, если пользователю они не видны.
- Проведение второго круга регрессионного тестирования.
- Исходя из опыта команды «Точка качества», в среднем требуется не менее трёх раундов регрессионного тестирования для устранения всех дефектов и стабилизации приложения.
Регрессионное тестирование: ручное или автоматизированное?
На любом проекте регрессионные тесты – первые кандидаты на автоматизацию. Они запускаются регулярно, в большом количестве. Автоматизация позволяет не только сократить сроки тестирования, но и высвобождает ресурсы для более высокоуровневых задач, исследования приложения. Однако несмотря на востребованность автоматизации, ручное регрессионное тестирование также имеет место быть.
Ручное тестирование
Внедрять автоматизацию на небольших проектах, которые длятся всего несколько месяцев, не всегда целесообразно: затраты могут не окупиться, а разработка автотестов лишь затянет сроки реализации проекта. В таком случае тестирование проводится вручную без каких-либо особых инструментов, за исключением баг-трекинговой системы, например, JIRA.
Однако если проект разрастается, функциональность ПО увеличивается с каждым последующим релизом, это влечёт за собой увеличение объемов тестирования. В таком случае стоит задуматься о привлечении специалистов по автоматизации.
Автоматизация регрессионного тестирования
Решение об автоматизации принимает заказчик, а исполнение ложится на плечи
профессиональных инженеров по автоматизации, которые обладают необходимым опытом, знают языки программирования.
Выгоду автоматизации тестирования нельзя недооценивать:
- Улучшается качество продукта.
- Ускоряется выпуск ПО на рынок.
- Оптимизируется стоимость тестирования.
Кстати, есть и такие проекты, на которых разумно совместить ручные проверки с автоматизированными. Все зависит от специфики программного продукта.
Подведём итог
Согласно отчёту World Quality Report 2017, в среднем 26% всего ИТ-бюджета компаний идет на тестирование. Опыт компании «Точка качества» говорит о том, что 40–70% этих затрат приходится на регрессионное тестирование.
Если вы переведёте проценты в реальные деньги, то поймете, почему регрессионное тестирование заслуживает вашего внимания и требует тщательно продуманной стратегии. Выбор правильного подхода тестирования поможет эффективно обнаружить все проблемные места, устранить их, обеспечить высокое качество программного решения.
Как подобрать стратегию, тип регрессионного тестирования, оптимальный для вашего ПО? Спросите у нас! Получить
бесплатную консультацию QA-специалиста.
