Суть регрессионного тестирования заключается в том, чтобы найти проблемы, возникшие в результате изменений продукта. Предположим, есть продукт, состоящий из множества частей, при изменении одной из его частей могут возникнуть проблемы в других частях, либо добавление нового функционала приведет к ошибкам в старом.
Зачем нам проводить данный вид тестирования? Одна из очевидных причин — минимизировать регрессионные риски. То есть, риски того, что при очередном изменении продукт перестанет выполнять свои функции.
С регрессионным тестированием плотно связана другая активность — импакт анализ. Обычно под импакт анализом имеют в виду попытку оценить регрессионные риски ещё на этапе планирования изменений, а так же попытку определить объем регрессионного тестирования с учетом изменений, которые уже произошли (это определение чаще используют сами тестировщики). Очевидно, что от эффективности импакт анализа зависит эффективность регрессионного тестирования. Но не всегда тщательно проведенный импакт анализ позволяет сократить затраты на последующее тестирование.
Процесс организации регрессионного тестирования выглядит следующим образом:
1. Сбор информации. Мы изучаем продукт и его окружение. Собираем информацию о релизах, о типичных изменениях в продукте, о критериях качества, о пропущенных в прошлом регрессионных багах.
Активности, которые мы проводим (или можем проводить) на данном этапе:
— Сессии исследовательского тестирования. Цель: изучить продукт.
— Составление структуры приложения. Мы можем проводить декомпозицию по фичам, структурную декомпозицию по модулям, из которых состоит продукт, а также другие типы разбиения продукта. Цель: изучить продукт и подготовить основу для импакт анализа и оценки покрытия.
— Построение модели приложения. Практически любой, даже очень сложный продукт, можно представить в виде рисунка, наглядно показывающего взаимодействие отдельных модулей. Цель: подготовить основу для импакт анализа.
— Составление списка критериев качества, важных для продукта.
— Изучение статистики регрессионных ошибок.
— Изучение типичных изменений продукта в среднестатистическом релизе.
— Изучение графика будущих релизов.
Отталкиваясь от информации, собранной на этом шаге, мы принимаем решения по стратегии регрессии.
2. Формирование стратегии. Мы принимаем решения по стратегии регрессионного тестирования, которая является общей для всех релизов.
Решения, которые мы можем принимать:
— Будем ли мы составлять набор регрессионных тестов, специфичный для конкретного релиза, или у нас будет универсальный набор тестов.
— Кто будет проводить импакт анализ и на каких уровнях.
— Насколько полным и тщательным будет импакт анализ.
— Нужна ли нам библиотека регрессионных тестов.
— Если да, то как и когда мы будем обновлять эту библиотеку.
— Как мы будем измерять эффективность регрессионного тестирования.
— В частности, какие виды тестового покрытия будут для нас важны. А различных видов покрытия очень много.
— Когда мы будем начинать регрессионное тестирование.
Когда эти высокоуровневые решения приняты, мы можем использовать эту стратегию для всех релизов. Для каждого релиза мы будем уточнять ее и дополнять необходимыми деталями, получая план регрессионного тестирования. Итак, мы опускаемся с высокого уровня (общего для всех релизов) на уровень конкретного релиза.
3. Сбор информации о конкретном релизе. Мы опускаемся на более низкий уровень, на уровень релизов, и изучаем изменения в конкретном релизе.
Какая информация нам будет нужна:
— Список изменений, как минимум.
— Дата релиза.
— Доступность тестовых стендов / окружений в ходе тестирования.
— И другие вещи, важные при составлении тест плана для конкретного релиза.
Собранная информация будет использована дальше, когда мы будем составлять детальный план регрессионного тестирования.
4. Составление тест плана по регрессии. Мы принимаем решения по тестированию конкретного релиза. Этот шаг включает в себя и импакт анализ изменений.
Какие решения мы принимаем на этом шаге:
— Как и когда проводить импакт анализ, кто будет это делать.
— Для каких изменений мы будем проводить импакт анализ.
— Каким будет список тестов для регрессионного тестирования. Формируется в результате импакт анализа.
— Какими будут приоритеты тестов.
— В каком формате мы будем хранить тесты (чеклисты, тест кейсы, тест идеи, другие).
— Каким будет график регрессионного тестирования.
— Как мы будем оценивать тестовое покрытие.
— Какой уровень тестового покрытия будет для нас достаточным и др.
Решений на этом этапе много. Мы часто действуем на опыте и используем решения, которые уже принимали в прошлом для похожих релизов.
На следующем шаге мы должны быть достаточно гибкими и уметь подстраиваться под ситуацию. Мы должны быть готовы к корректировке плана регрессии.
5. Выполнение регрессии. Во время выполнения регрессионных тестов мы следим за процессом и анализируем найденные проблемы (или отсутствие проблем). Полученная информация используется для корректировки плана регрессии.
Что мы делаем во время выполнения регрессионных тестов:
— Анализируем найденные ошибки.
— Логичным будет уделить больше внимание тестированию той части системы, где возникает ошибка, и тех частей, что с ней связаны.
— Анализируем другие сигналы. Например, отсутствие найденных ошибок может быть полезной информацией для размышления.
— Оцениваем тестовое покрытие.
— Предоставляем отчетность по статусу регрессионного тестирования.
— Оцениваем реальность графика регрессионного тестирования.
— Меняем приоритеты тестов.
— Участвуем в триаже багов. Найденные проблемы нужно либо исправить в текущем релизе, либо перенести в будущий релиз. Обычно в триаже багов тестировщики принимают участие наряду с другими стейкхолдерами.
После окончания цикла регрессионного тестирования полезно выполнить еще один этап.
6. Работа над ошибками. После проведения тестирования мы анализируем регрессионные проблемы, которые прошли мимо нас, делаем выводы. Если у нас есть регрессионная библиотека тестов, то обновляем её с учетом последних изменений продукта.
— Анализ ошибок, которые были пропущены. Особенное внимание уделяется регрессионным ошибкам, то есть проблемам в старом функционале, возникшим в результате свежих изменений.
— Возможные изменения стратегии регрессионного тестирования.
— Обновление библиотеки регрессионных тестов. Если такая имеется. Обычно свежий функционал добавляется в регрессионную библиотеку, так как начиная со следующего цикла регрессии этот функционал будет уже старым.