Тестирование на основе рисков

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

Думаю все знают, что полноценный процесс разработки тест-кейсов строится на документации. Мы анализируем, выделяем требования из документации и затем покрываем требования позитивными и негативными тест-кейсами. Этот подход в тестировании называется test-case based, т.е. тестирование на основе тест-кейсов. Многие привыкли так работать обосновывая это тем, что так мы можем свести к минимуму возникновение дефектов на бою.

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

Мы продолжаем отталкиваться от требований, а следовательно, и тест-кейсов, которые их покрывают.

Подход к управлению тестированием, основанный на проблемах

Но в 1994 году Джеймс Бах стал говорить о новом подходе к управлению тестированием, основанного на проблемах. Это одно из первых упоминаний того, что можно тестировать программное обеспечение отталкиваясь от проблем, с которыми можно столкнуться при внедрении программного продукта.

Впервые, Джеймс Бах в своей статье «The Challenge of «Good Enough» Software » начинает говорить о том, что если мы минимизируем или исключим все проблемы, которые могут быть связаны с качеством нашего продукта, то по умолчанию качество нашего продукта будет высоким.

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

После уже в 1996, Рональд Хигьера и Яков Хаймес выпускают свой труд «Software Risk Managment», в котором описывают методологии управления рисками для ПО. Наверное именно эта работа и послужила отправной точкой для подхода Risk-Based Testing, потому что буквально через 3 года Джеймс Бах начинает говорить об непонятной теории в вакууме «Эврестическом методе тестировании на основе рисков», в котором появляется отсылка к критериям качества,

Критерии качества

Основные критерии могут быть внутренними и внешними.

К внутренним относятся:

Уязвимости: Какие недостатки и сбои могут иметь компоненты системы?
Угрозы: Какие входные данные или ситуации могут быть причиной сбоя в работе компонента системы?
Потери: Кто или что может привести к потенциальным фэйлам и к чему это приведет?

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

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

Таким образом отличие внутренних рисков от внешних в том, что внутренний риски отвечают на вопрос:

«Какие риски могут быть связаны именно с внутренней составляющей нашего продукта?»

а внешние:

«Какое влияние (событие) на наш продукт может привести к риску возникновения проблем?»

Сложно? никто не говорил что будет легко! 🙂

Перейдем к внешним рискам.

Разделить их можно на 3 составляющих:

Модель качества продукта
Общие риски
Доменные риски

Модель качества — это наиболее знакомая всем система качества ПО по ISO 25010.

Основными критериями качества служат 8 характеристик качества продукта.

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

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

Ну и последнее, это доменные риски.

Доменные риски — это риски, связанные с работоспособностью ПО, т.к. для того, чтобы определить их, мы можем просто продолжить предложение:

«Мы можем столкнуться с проблемами, которые связаны с….»

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

На этом можно считать, мы немного разобрались с теорией управления рисками и теперь перейдем к подходам, которые могут применяться в risk-based testing.

Подходы к тестированию в risk-based testing

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

На текущий момент существует множество технических подходов в тестированию, основанному на риска, но тем не менее я выделяю следующие:

Failure Mode and Effect Analysis (FMEA)
Fault Tree Analysis (FTA)

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

И первым, и наиболее популярным подходом к risk-based testing является модель FMEA.

FMEA (Failure mode and effect analysis) — модель анализа причин и последствий отказов системы, которая определяет потенциальные дефекты в системе и причины их возникновения.

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

Для изменения таких сбоев используется 3 показателя:

Серьезность
Приоритет
Вероятность

Рассмотрим на примере. Мы имеем систему, которая автоматизирует бизнес процесс выдачи кредитных продуктов конечному пользователю.

И наша система выполняет 3 основных функции:

Оформление кредита
Закрытие кредита
Формирование документов для клиента

В ходе брейншторма команда проекта определяет основные риски системы:

Некорректный расчет процентной ставки по кредиту
Лишние средства могут не перевестись на счет клиента при закрытии кредита
Система может упасть под нагрузкой в 300 пользователей
Отсутствие возможности автоматической печати документов

Шкала измерения может зависеть от проектной специфики, но я рассмотрю вариант с измерением по шкале от 1 до 4, где 1 — блокирующий эффект, а 5 — незначительный эффект.

Далее мы определяем для каждого риска значение показателей:

Серьезность (S):

Приоритет (P):

Вероятность (L):

После проведенного анализа выполняется расчет показателя RPN (Risk Priority Number)

RPN = S*P*L

В итоге мы получаем расчет приоритезацию рисков относительно тестирования ПО:

Далее в зависимости от полученного показателя определяется глубина тестирования:

Если значение PRN 1-10, то проводим полное тестирования со всевозможными позитивными и негативными проверками, в том числе и минорные тесты.
Если значение PRN 11-30, то проводим сбалансированное тестирование основной функциональности.
Если значение PRN 31-70, то проводим поверхностное тестирование функциональности.
Если значение PRN свыше 70, то проводим тестирование при наличии свободного времени.

Преимущества модели FMEA в том, что она использует прозрачную модель оценки объемов тестирования, отталкиваясь от рисков в использовании ПО.

В противовес модели FMEA зачастую ставится модель FTA.

FTA (Fault Tree Analysis) — модель анализа возможных дефектов, работающая на основе логико-вероятностной модели причинно-следственных связей отказов системы с отказами ее элементов и другими событиями (воздействиями).

Модель FTA, используя подход «сверху-вниз», позволяет поэтапно определять всевозможные причины, которые могут приводить к дефектам в бизнес-процессах системы. Анализ начинается с основных процессов системы, которые в дальнейшем разделяются на составные части процесса, образуя таким образом древовидную комбинацию. Анализ проводится до самого низкого уровня, например, до неработоспособной кнопки перехода на следующее окно оформления кредитного продукта или отсутствия возможности ввода в поле «Дата» числовых символов. Каждое такое событие анализируется и определяются возможные дефекты, с которыми можно столкнуться при работе с системой.

В классическом понимании уровни модели FTA выглядят так:

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

Визуально, это будет выглядеть так:

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

Кроме этих моделей прогнозирования рисков, существует еще несколько подходов, таких как:

ХАССП
Cost of Exposure technique
Quality Function Deployment (QFD)

Разбор этих моделей может занять еще 20 часов и n-ое количества текста будет очень долгим, поэтому в этой статье я их рассматривать не буду.

Дам лишь небольшие определения.

HACCP (Hazard Analysis and Critical Control Points) — анализ рисков и критичные контрольные точки, концепция, предусматривающая систематическую идентификацию, оценку и управление опасными факторами, существенно влияющими на продукт.

Более подробно концепция ХАССП рассматривается в ГОСТ Р 51705.1, но важно понимать, что этот документ не связан с ИТ и применение этого подхода в тестировании требует серьезной доработки.

Cost of Exposure technique — название говорит само за себя. Этот подход мало известен, но суть его в том, что любые риски в тестировании можно посчитать путем перемножения значения вероятности риска на среднюю стоимость (потери) при наступлении всех рисков.Такой подход очень подходит для тех, кто задает фразы:

«Зачем платить за тестирование 100 рублей, если наш дефект будет стоит всего 50 рублей».

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

Ну, и напоследок, рассмотрим, QFD (Quality Function Deployment).

Это японская модель оценки качества продукта, которая ориентируется на потребности заказчика. Это сложная модель, которая иначе называется, «домик». Она очень сложна в применении и, возможно, я рассмотрю ее позже в следующих статьях.

Заключение

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

Risk-Based Testing позволяет сократить объемы тестирования за счет приоритезации проверок и их точной направленности. Конечно же у модели есть недостатки, но, кто не рискует, тот не побеждает!