1 августа 2018

Оптимизация регрессионного тестирования в гибкой разработке

Спасибо тестировщику Noveo Анастасии за рубрику переводов о тестировании!

regression_testing_in_agile_development-01

Регрессионное тестирование часто становится проблемным вопросом для менеджеров Agile-проектов. Этот вид тестирования несет в себе две основных трудности:

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

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

Регрессионное тестирование в гибких проектах: как оптимизировать?

Существует три наиболее распространенных пути оптимизации регрессионного тестирования в гибкой разработке:

  • двухуровневый подход;
  • приоритизация тестов (коллективный подход и подход на основе оценки рисков);
  • автоматизированный подход.

У каждого из них есть плюсы и минусы.

Двухуровневый подход

two-level-approach

В соответствии с этим подходом команда тестировщиков делит регрессионные тесты на два цикла:

  1. Регрессия по итерациям. Команда проводит регрессионные тесты в конце каждого спринта. Такая регрессия сосредоточивается на фичах и изменениях, сделанных в рамках итерации, и частях приложения, которые могли быть затронуты.
  2. Полная регрессия. Тестировщики проводят полное регрессионное тестирование перед релизами и выпусками новых версий, чтобы убедиться, что продукт работает как положено.

Тем не менее, этот подход не так прост, как кажется. Чтобы всё прошло успешно, требуется непрерывная коммуникация внутри команды. Общаясь с разработчиками, тестировщики получают полное представление о том, что было сделано в течение итерации, и обоснованно выбирают необходимый тип регрессионного тестирования. Еще один пункт, который следует учесть, это время, прошедшее с момента последней полной регрессии. Это может помочь в установлении графика регулярного полного регрессионного тестирования и проведении ряда тестов вне зависимости от изменений, которые были внесены в ходе итерации. Это поможет команде избежать утомительной полной регрессии после каждого спринта и сохранить приложение относительно “чистым” от багов в любой момент.

Приоритизация тестов: подход на основе оценки рисков

risk-based-approach

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

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

  • Высокий приоритет. Эти тест-кейсы составляют около 10% всех регрессионных тестов. Они покрывают критичный функционал, области, которые чаще всего видят пользователи, области, склонные к появлению багов, а также области, в которые вносили много изменений.
  • Средний приоритет. Эти тест-кейсы (около 30%) описывают исключительные условия (негативные проверки, проверки на границах и т.д.). В основном в эту категорию попадают тест-кейсы, которые регулярно находили баги в рамках предыдущих релизов.
  • Низкий приоритет. Эти тест кейсы (оставшиеся 60%) покрывают весь остальной функционал. Тестировщики используют их для регрессии перед крупным релизом для обеспечения полного тестового покрытия.

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

Приоритизация тестов: коллективный подход

collaborative-approach

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

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

Осторожно: технические недоработки

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

Проблемы появляются, когда эти недостатки выходят из-под контроля. Дисциплинированная гибкая поставка (Disciplined Agile delivery, DAD) — фреймворк, который предлагает широкий диапазон шагов по эффективной работе с техническими недоработками. Удивительно, но постоянное гибкое регрессионное тестирование — один из них. Это возвращает нас к началу.

Итак, возможно ли оптимизировать гибкое регрессионное тестирование и в то же время контролировать техническую часть? Ответ на этот вопрос — автоматизация регрессионного тестирования, наша третья стратегия.

Автоматизированный подход

automated-approach2

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

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

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

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

Ориентированность на коммуникацию

Чтобы оптимизировать гибкое регрессионное тестирование, команде тестировщиков следует установить непрерывную коммуникацию с другими членами команды:

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

Это общепринятый фундамент для всех трех стратегий оптимизации регрессионного тестирования.

Подытоживая сказанное

Регрессионное тестирование в гибкой разработке напоминает горькую таблетку: неприятно, но необходимо для обеспечения качества продукта. К счастью, у команд тестировщиков Noveo в гибкой разработке есть множество стратегий, которые можно применить для оптимизации регрессии. Самые популярные из них — это двухуровневый подход, приоритизация тестов и автоматизация регрессии.

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

Noveo regression testing

Оригинал: https://www.scnsoft.com/blog/regression-testing-in-agile-development

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: