Регрессионное тестирование (regression testing) — это тестирование, с которым рано или поздно сталкивается каждая команда, разрабатывающая программный продукт. И каждого тестировщика начинает заботить вопрос: как разработать эффективную стратегию регрессионного тестирования. Если регрессионного тестирования будет недостаточно, то есть высокая вероятность, что заказчик получит продукт с ошибками, в противном случае — вплоть до потери заказчика. Эвристика  Карен Джонсон (Karen Johnson) помогает создать эффективную стратегию для регрессионного тестирования используя мнемонику RCRCRC.

Давайте для начала вспомним, что такое регрессионное тестирование. Согласно SWEBOK регрессионное тестирование (regression testing) — это выборочный повторный тест системы или компонента для проверки того, что модификации не вызвали непреднамеренных эффектов, и что система или компонент по-прежнему соответствуют указанным требованиям. Также определения можно посмотреть в ISTQB и Wiki. В принципе, они все очень похожи и выражают одну и туже идею.

Эвристика RCRCRC позволяет найти правильный баланс при планировании работ по регрессионному тестировании между временем, рисками и тестовым покрытием. Давайте рассмотри ее более подробно.

RCRCRC (Recent)

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

RCRCRC (Core)

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

RCRCRC (Risky)

Какой функционал/часть продукта обладает максимальными рисками. Джейсом Бахом (James Bach) была разработана эвристика тестирования, основанная на рисках (Heuristic Risk-Based Testing). Применительно к регрессионному тестированию можно использовать список общих рисков, которые являются универсальными для любой системы:

• Новое. Все что не имеет истории в системе. В нашем случае это дублирует п. Recent. За основу берем приемочные тест-кейсы, но не ограничиваем себя жесткими рамками приемочных критериев.
• Измененное. Все, что было изменено в соответствии с новыми требованиями или улучшено/оптимизировано. Что тут использовать, думаю, уже понятно.
• Зависимость потоков. Все, чьи ошибка приведут к каскадному сбою в остальной части системы. Проводим анализ матрицы взаимодействия компонентов тестируемой системы.
• Критичность. Все, чей сбой приведет к существенному урону в основных сценариях (вспоминаем Core)
• Точность. Все, что должно на 100% соответствовать требованиям. Одним из самых распространенных примеров- это брендинг компании, для которой разрабатывается продукт. Создайте соответствующий чек-лист, только не забывайте его во время обновлять.
• Стратегичность. Все, что имеет важное значение в рамках компании, и отличает наш продукт от продуктов конкурентов.
• Сторонние взаимодействия. Все, что используется в продукте, но разработано вне проекта. Во многих проектах  есть дополнительные утилиты, которые со временем могут превратиться в «костелиты», наша задача помочь им избежать такой участи. Кроме того, помним, о компонентах 3х лиц.
• Распространение. Проверяем полноту и корректность новой сборки, а также пути ее получения.
• Забагованность. Следует уделить внимания тем частям продукта, где вероятность возникновения ошибок максимальная (см Chronic).
• Недавняя неудача. Вспоминаем, все те проблемы, с которыми недавно сталкивались. Необходимо убедиться, что они не возникли повторно (см Repaid).
• Популярность. Все, что будет использоваться много раз. Здесь нам помогут тест-кейсы основных сценариев.

RCRCRC (Configuration sensitive)

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

RCRCRC (Repaid)

Исправления ошибок часто влечет новые проблемы. Поэтому учитываем какие изменения могли быть внесены при исправлении багов в текущей итерации, с высокой критичностью (Severity).

RCRCRC (Chronic)

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

Регрессионное тестирование. Чек-Лист

1. Приемочные тест-кейсы текущей итерации.
2. Тест-кейсы основных сценариев.
3. Анализируем матрицу взаимосвязей компонентов системы. Используем эвристику SFDIPOT, чтобы ничего не забыть.
4. Учитываем пользовательские конфигурации.
5. Проводим анализ рисков.
6. Перепроверяем баги с высокой критичностью текущей итерации.
7. Планируем тестирование с учетом проблемных областей продукта.

Регрессионное тестирование- это дело всей команды!

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

MindMap

Посмотреть и скачать схему можно тут: На русском, In English

Обратная связь

В Твиттере получила обратную связь от автора (Карен Джонсон)!

Thanks! Thanks for sharing. More structured than I work with but that’s just me. Great that you could share an example.

— karennjohnson (@karennjohnson) December 29, 2017