Как провести регрессионное тестирование в условиях ограничения по времени и обеспечить необходимый уровень контроля качества?
Хорошо, когда на регрессионное тестирование есть достаточно времени, но что же делать, когда вам нужно максимально оперативно дать заключение по релизу? Как быстро решить вопрос отбора необходимых тестов? Как легко определить какой функционал должен быть протестирован?
Давайте разбираться по порядку.
Введение
Матрица критичности-сложности (далее просто МКС) – это метод, позволяющий классифицировать функциональность программного продукта с точки зрения сложности ее тестирования и критичности для бизнеса.
Цель – получить максимальное тестовое покрытие при наименьших затратах. МКС также помогает решить задачу снижения затрат на тестирование с минимальными негативными последствиями для качества ПО.
Матрица критичности-сложности
МКС держится на 3 китах (рисунок 1):
Рисунок 1 — Три кита
Процесс – под процессом будем понимать функционал ПО.
Трудозатраты – это одна из составляющих сложности, которая отвечает на вопрос «сколько надо времени что бы провести тест?» и считается в человеко-час.
Критичность – важность функционала для бизнеса.
Итак, разобравшись с терминами и определениями, рассмотрим, как же будет выглядеть МКС в общем виде (рисунок 2).
Рисунок 2 — Общий вид МКС
Пока что мало что понятно? Не беда. Рассмотрим конкретный пример.
Пример
Представим, что наша задача – протестировать сервис Яндекс.Маркет (рисунок 3).
Рисунок 3 — Сервис Яндекс.Маркет
Разберем сайт на модули (например, Личный кабинет, Поиск, Карточка товара) и сделаем тест-кейсы для каждого модуля. Затем для каждого тест-кейса проставим уровень критичности (тут нам поможет аналитик со стороны бизнеса) и сложности (трудозатраты). Для нашего примера они будут такими (рисунок 4):
Рисунок 4 — Уровни критичности и сложности
Примечание: в рамках своего проекта вы меняете Количество часов (это время выполнения одного теста и задается в интервальном виде для группы тестов) и Среднее время на тест (среднее время выполнения теста – задается для группы тестов и необходимо для построения МКС в часах).
По итогу мы получим вот такую нехитрую таблицу (рисунок 5):
Рисунок 5 — Таблица тест-кейсов
Примечание: Критичность и Сложность выбираются из выпадающего списка, а Группа подставляется автоматически. Ссылка на данную таблицу в конце статьи.
Помимо автоматического выбора Группы, автоматически наполняется МКС в 2 видах:
Матрица критичности-сложности (кол-во тестов) (рисунок 6).
Рисунок 6 — МКС (кол-во тестов)
Матрица критичности-сложности (в часах) (рисунок 7).
Рисунок 7 — МКС (кол-во часов)
Пример МКС из данной статьи можно найти, отсканирован qr-code (рисунок 8) или перейдя по ссылке.
Рисунок 8 — Ссылка на пример МКС
Выводы
Как видно из примера, построить МКС достаточно просто, а вот какая от этого польза давайте разберем:
- МКС позволяет легко делить тесты на группы и в условиях ограничения по времени становиться намного проще и быстрее совершать отбор тестов, которые направлены на проверку ключевого функционала ПО;
- Это отличный инструмент, позволяющий понять полезность и важность тестов – можно легко определить сколько тестов направлено на ключевой, а сколько на вторичный функционал;
- С помощью МКС можно наглядно показать, сколько необходимо времени на регрессионное тестирование;
- Развивать модель регрессионного тестирования становиться проще, ведь мы видим четкий вектор, в котором необходимо двигаться.
Хотите начать использовать МКС на своем проекте? Обращайтесь к нам, в Перфоманс Лаб, мы с удовольствием вам поможем.
