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

Я давно хотел написать о регрессионном тестировании. А тут и случай представился - 20 июня мы проведём сессию Weekend testing по этой теме.

Что это такое? Суть регрессионного тестирования в том, чтобы найти проблемы, возникшие в результате изменений продукта. Для тех, кто заинтересован в более формальном определении, могу посоветовать Wikipedia, MSDN, ISTQB.



Предположим, есть продукт, состоящий из множества частей:

При изменении одной из его частей могут возникнуть проблемы в других частях:

Либо добавление нового функционала приведет к ошибкам в старом:

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

С регрессионным тестированием плотно связана другая активность - импакт анализ (или иначе, анализ влияния изменений). Обычно под импакт анализом имеют в виду одно из следующих: 
1) Попытку оценить регрессионные риски ещё на этапе планирования изменений (этим определением, по моему опыту, чаще пользуются менеджеры и разработчики);
2) Попытку определить объем регрессионного тестирования с учетом изменений, которые уже произошли (это определение чаще используют сами тестировщики).

В этом сообщении, говоря об импакт анализе, я буду иметь в виду второе определение. Кстати, у Пола Джеррарда есть серия статей, где более детально раскрывается понятие импакт анализа, причем не только с позиции тестировщика (см. список материалов внизу).     

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

В табличке внизу я показал 3 разных случая - соотношение затрат на импакт анализа, на регрессионное тестирование и связанные с ними регрессионные риски:

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

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

Во многом это напоминает другую задачу - составление тестовой стратегии в целом. Или просто я склонен находить параллели между этими задачами, потому что много писал про тестовую стратегию зимой (пост 1, пост 2, пост 3) и мой доклад на SQA days тоже был связан со стратегией тестирования :)

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

1. Сбор информации. Мы изучаем продукт и его окружение. Собираем информацию о релизах, о типичных изменениях в продукте, о критериях качества, о пропущенных в прошлом регрессионных багах.
2. Формирование стратегии. Мы принимаем решения по стратегии регрессионного тестирования, которая является общей для всех релизов.
3. Сбор информации о конкретном релизе. Мы опускаемся на более низкий уровень, на уровень релизов, и изучаем изменения в конкретном релизе.
4. Составление тест плана по регрессии. Мы принимаем решения по тестированию конкретного релиза. Этот шаг включает в себя и импакт анализ изменений.
5. Выполнение регрессии. Во время выполнения регрессионных тестов мы следим за процессом и анализируем найденные проблемы (или отсутствие проблем). Полученная информация используется для корректировки плана регрессии.
6. Работа над ошибками. После проведения тестирования мы анализируем регрессионные проблемы, которые прошли мимо нас, делаем выводы. Если у нас есть регрессионная библиотека тестов, то обновляем её с учетом последних изменений продукта.  

Давайте рассмотрим эти шаги подробнее.

1 шаг: Сбор информации
Активности, которые мы проводим (или можем проводить) на данном этапе:

• Сессии исследовательского тестирования. Цель: изучить продукт.
• Составление структуры приложения. Мы можем проводить декомпозицию по фичам, структурную декомпозицию по модулям, из которых состоит продукт, а также другие типы разбиения продукта. Цель: изучить продукт и подготовить основу для импакт анализа и оценки покрытия.
• Построение модели приложения. Практически любой, даже очень сложный продукт, можно представить в виде рисунка, наглядно показывающего взаимодействие отдельных модулей. Цель: подготовить основу для импакт анализа.
• Составление списка критериев качества, важных для продукта.
• Изучение статистики регрессионных ошибок.
• Изучение типичных изменений продукта в среднестатистическом релизе.
• Изучение графика будущих релизов.

Отталкиваясь от информации, собранной на этом шаге, мы принимаем решения по стратегии регрессии.

2 шаг: Формирование стратегии

Решения, которые мы можем принимать:

• Будем ли мы составлять набор регрессионных тестов, специфичный для конкретного релиза, или у нас будет универсальный набор тестов.
• Кто будет проводить импакт анализ и на каких уровнях. Подробнее об уровнях импакт анализа - в статьях Пола Джеррарда (см. материалы внизу). 
• Насколько полным и тщательным будет импакт анализ.
• Нужна ли нам библиотека регрессионных тестов. 
• Если да, то как и когда мы будем обновлять эту библиотеку.
• Как мы будем измерять эффективность регрессионного тестирования.
• В частности, какие виды тестового покрытия будут для нас важны. А различных видов покрытия очень много :) 
• Когда мы будем начинать регрессионное тестирование. 

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

3 шаг: Сбор информации о конкретном релизе
Какая информация нам будет нужна:

• Список изменений, как минимум.
• Дата релиза.
• Доступность тестовых стендов / окружений в ходе тестирования.
• И другие вещи, важные при составлении тест плана для конкретного релиза.

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


4 шаг: Составление тест плана по регрессии
Какие решения мы принимаем на этом шаге:

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

Решений на этом этапе много. Мы часто действуем на опыте и используем решения, которые уже принимали в прошлом для похожих релизов.

На следующем шаге мы должны быть достаточно гибкими и уметь подстраиваться под ситуацию. Мы должны быть готовы к корректировке плана регрессии.


5 шаг: Выполнение регрессии
Что мы делаем во время выполнения регрессионных тестов: 

• Анализируем найденные ошибки.
• Логичным будет уделить больше внимание тестированию той части системы, где возникает ошибка, и тех частей, что с ней связаны.
• Анализируем другие сигналы. Например, отсутствие найденных ошибок может быть полезной информацией для размышления.
• Оцениваем тестовое покрытие.
• Предоставляем отчетность по статусу регрессионного тестирования.
• Оцениваем реальность графика регрессионного тестирования.
• Меняем приоритеты тестов. Я явно указал эту активность как пример изменения плана, составленного раньше. 
• Участвуем в триаже багов. Найденные проблемы нужно либо исправить в текущем релизе, либо перенести в будущий релиз. Обычно в триаже багов тестировщики принимают участие наряду с другими стейкхолдерами.   

После окончания цикла регрессионного тестирования полезно выполнить еще один этап.

6 шаг: Работа над ошибками
Что он в себя включает:

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

Заключение
Вот такой план :) Получилось не так много информации, как я ожидал. Я сознательно опустил такие крупные темы как: автоматизация регрессии, виды тестового покрытия.

Немного не хватает живого практического примера по использованию описанных шагов. Приходите на сессию викенд тестирования - там потренируемся!

Материалы (на английском):

• Paul Gerrard: 

• Anti-Regression Approaches: Impact Analysis and Regression Testing Compared/Combined - Part I: Introduction & Impact Analysis
• Anti-Regression Approaches - Part II: Regression Prevention and Detection Using Static Techniques
• Anti-Regression Approaches: Impact Analysis and Regression Testing Compared and Combined: Part III: Regression Testing

• Recession Testing is the new RegressionTesting