Тестирование на основе рисков: особенности подхода и его преимущества.
Конкуренция в сфере разработки программного обеспечения очень высокая. Чтобы добиться успеха, компании стремятся с минимально возможными затратами создавать продукты максимально высокого качества. И справиться с этой задачей без эффективно настроенного QA-процесса практически невозможно.
Но проблема заключается в том, что дедлайны и бюджет редко позволяют специалистам по обеспечению качества одинаково тщательно тестировать все функции приложения. Им приходится решать, на выполнение каких задач стоит потратить больше усилий и времени, а какие не требуют столь пристального внимания. Как же они принимают такие важные решения? Полагаться на субъективное мнение членов команды — не самый оптимальный вариант. Правильно определять цели и рационально расставлять приоритеты позволяет тестирование на основе рисков.
Если вы ещё не знакомы с этим подходом, оставайтесь с нами. В этой статье мы поговорим о том, что такое тестирование на основе рисков, каковы его преимущества и что представляет собой процесс управления рисками при тестировании программного обеспечения.
Что такое тестирование на основе рисков?
Для начала давайте вспомним, что такое риск. Под риском мы подразумеваем возможность возникновения какого-либо события, которое может оказать неблагоприятное влияние на проект. Уровень риска определяется двумя факторами: вероятность наступления события и величина ущерба, который оно может нанести.
И именно уровень риска может служить надёжным параметром для расстановки приоритетов в тестировании программного обеспечения. Очевидно, что при неограниченном количестве возможных тестовых сценариев и ограниченных ресурсах имеет смысл приложить максимум усилий на тестирование функций, которые используются чаще всего и некорректная работа которых может нанести наибольший ущерб.
То есть, QA команда должна ответить на два вопроса о каждой функции:
Представим, что специалисты по обеспечению качества работают над тестированием банковского приложения. Перед ними стоит задача проверить работу двух функций:
Очевидно, что QA команде нужно будет приложить значительно больше усилий для тестирования первой функции. Конечно, это очень упрощенный пример. (В реальности приложения намного сложнее и специалисты должны проверять работу сотен элементов.) Но он наглядно показывает, в чём суть тестирования на основе рисков.
Такой подход позволяет оптимизировать ресурсы и получить максимальную пользу от тестов. Расставляя приоритеты задачам, специалисты по обеспечению качества ориентируются на результаты предварительной оценки рисков.
Теперь давайте подробнее рассмотрим, что такое процесс управления рисками при тестировании программного обеспечения.
Процесс управления рисками при тестировании программного обеспечения.
Процесс управления рисками может варьироваться в зависимости от компании и сложности разрабатываемого продукта. Но, как правило, он включает следующие этапы:
Теперь, когда вы лучше понимаете процесс управления рисками при тестировании, давайте остановимся подробнее на матрице для определения приоритетов и оценки рисков.
Матрица рисков.
Для анализа рисков команды QA часто используют матрицу, где на одной стороне располагается уровень вероятности возникновения события, а на другой — степень потенциального воздействия на проект. Это позволяет разделить все риски на группы:
Конечно, в зависимости от проекта такая матрица может быть более подробной. Тогда возможным рискам будет присваиваться больше уровней вероятности. Например, частые, возможные, случайные, редкие, крайне редкие. Что касается степени потенциального воздействия, она может делиться на катастрофическую, критическую, серьёзную, приемлемую, незначительную.
Преимущества тестирования на основе рисков.
Как видите, тестирование на основе рисков позволяет компаниям эффективно управлять ограниченными ресурсами. Такой подход помогает QA командам оптимизировать свою работу, правильно расставлять приоритеты, находить самые критические ошибки раньше, а также видеть степень тестового покрытия на каждом этапе жизненного цикла разработки программного обеспечения. Таким образом, главные преимущества тестирования на основе рисков — это снижение затрат на разработку, сокращение времени выхода на рынок и повышение качества приложений.
Как управлять объемами тестирования на основе рисков.
Постоянно, тестируя ПО, очень часто многие команды, ввиду приверженности к стандартной модели, тестируют функциональность, опираясь на тест-кейсы или чек-листы. И чем крупнее организация, тем больше и сложнее процесс разработки и написания тест-кейсов. Если для компании, занимающейся разработкой коробочного ПО часто достаточно просто подготовить чек-лист со списком проверок, то в больших организациях, таких как банки, телеком, ретейл, зачастую используется автоматизированная система управления тестированием, которая позволяет вести полноценный цикл разработки тест-кейсов, начиная с проработки требований, и заканчивая согласованием и валидацией тест-кейсов, размер которых может превышать 30 шагов, если мы тестируем сквозной бизнес процесс.
Думаю все знают, что полноценный процесс разработки тест-кейсов строится на документации. Мы анализируем, выделяем требования из документации и затем покрываем требования позитивными и негативными тест-кейсами. Этот подход в тестировании называется test-case based, т.е. тестирование на основе тест-кейсов. Многие привыкли так работать обосновывая это тем, что так мы можем свести к минимуму возникновение дефектов на бою.
Но, с развитием гибкой методологии, все чаще и чаще приходится отказываться от модели тест-кейсов, т.к. этап подготовки занимает просто невероятно большое количество времени, которого к сожалению нету в коротких спринтах. Кто-то переходит на чек-листы, тем самым сокращая по времени процесс разработки тест-кейсов, кто-то начинает приоритезировать тест-кейсы в зависимости от важности бизнес процесса, но тем не менее подход к тестированию от этого не изменяется.
Мы продолжаем отталкиваться от требований, а следовательно, и тест-кейсов, которые их покрывают.
Но в 1994 году Джеймс Бах стал говорить о новом подходе к управлению тестированием, основанного на проблемах. Это одно из первых упоминаний того, что можно тестировать программное обеспечение отталкиваясь от проблем, с которыми можно столкнуться при внедрении программного продукта.
Впервые, Джеймс Бах в своей статье “The Challenge of “Good Enough” Software ” начинает говорить о том, что если мы минимизируем или исключим все проблемы, которые могут быть связаны с качеством нашего продукта, то по умолчанию качество нашего продукта будет высоким.
И в целом он был прав, потому что если мы поставим себя на место пользователя системы и посмотрим с его стороны, с какими проблемами он может столкнуться при работе с продуктом и исключим их, то у пользователя не будет проблем, а следовательно, он будет удовлетворен работой продукта.
После уже в 1996, Рональд Хигьера и Яков Хаймес выпускают свой труд “Software Risk Managment”, в котором описывают методологии управления рисками для ПО. Наверное именно эта работа и послужила отправной точкой для подхода Risk-Based Testing, потому что буквально через 3 года Джеймс Бах начинает говорить об непонятной теории в вакууме “Эврестическом методе тестировании на основе рисков”, в котором появляется отсылка к критериям качества,
Основные критерии могут быть внутренними и внешними.
К внутренним относятся:
Все эти критерии относятся к внутренней работе продукта, а точнее к механизму работы. Так, будут менеджером, вполне возможно, организовав встречу с разработчиком, выяснить основные нюансы в разрабатываемом продукте. Основная задача менеджера будет в данном случае полностью погрузится в техническую составляющую ПО и определить все риски продукта.
При оценки рисков по внутренним критериям необходимо понимать, что произойдет с системой, если, к примеру, не будет работать функция, или какие есть зависимости данной функции от других внешних компонентов, конфигураций и т.д,
Таким образом отличие внутренних рисков от внешних в том, что внутренний риски отвечают на вопрос:
“Какие риски могут быть связаны именно с внутренней составляющей нашего продукта?”
“Какое влияние (событие) на наш продукт может привести к риску возникновения проблем?”
Перейдем к внешним рискам.
Разделить их можно на 3 составляющих:
Модель качества – это наиболее знакомая всем система качества ПО по ISO 25010.
Основными критериями качества служат 8 характеристик качества продукта.
Эти характеристики предназначены, что максимально всесторонне покрыть требования к качеству продукта, а значит, на каждую характеристику могут ложиться определенные риски при ее невыполнении.
Доменные риски – это риски, связанные с работоспособностью ПО, т.к. для того, чтобы определить их, мы можем просто продолжить предложение:
“Мы можем столкнуться с проблемами, которые связаны с….”
На текущий момент существует множество технических подходов в тестированию, основанному на риска, но тем не менее я выделяю следующие:
В целом, конечно, это модели оценки рисков продукта, но с развитием тестирования в отдельный процесс, они нашли применение и в тестировании.
FMEA (Failure mode and effect analysis) – модель анализа причин и последствий отказов системы, которая определяет потенциальные дефекты в системе и причины их возникновения.
Для изменения таких сбоев используется 3 показателя:
Рассмотрим на примере. Мы имеем систему, которая автоматизирует бизнес процесс выдачи кредитных продуктов конечному пользователю.
И наша система выполняет 3 основных функции:
В ходе брейншторма команда проекта определяет основные риски системы:
Шкала измерения может зависеть от проектной специфики, но я рассмотрю вариант с измерением по шкале от 1 до 4, где 1 – блокирующий эффект, а 5 – незначительный эффект.
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Для обеспечения качества информационного продукта в медицине, страховании, банкинге и других отраслях, наряду с другими методами тестирования, важно использовать тестирование, основанное на рисках. Для проверки выбирают самые рискованные области создаваемого программного обеспечения. Это позволяет предусмотреть негативные сценарии и успешно реализовать бизнес-цели заказчика.
В статье расскажем, как мы в компании SimbirSoft работали с рисками (на примере системы интернет-эквайринга и других проектов) и какие методики оценки и управления рисками мы используем в проектах заказчиков.
Риски на старте проекта
Для начала приведем пример из нашей практики в разработке для банковского сектора.
Предложение заказчика: сделать акцент на веб-версии банка для физических лиц.
Выявленный нами риск: возможная потеря аудитории из-за низкого спроса веб-версии у физических лиц, в отличие от мобильного клиент-банка.
Наши аргументы: статистика предпочтений пользователей на основе отзывов и распределения аудитории по мобильной и веб-версии.
Выводы: физическим лицам более удобна мобильная версия, так как телефон всегда под рукой. Операции совершаются быстро, система авторизации позволяет получить доступ ко всем удобным услугам. В этом случае важен быстрый доступ к ограниченному набору самых популярных функций.
Юридическим лицам важна полнота предоставляемых функций, возможность выгрузки, распечатки и работа с большим объемом информации. Для этого более удобна веб-версия.
Наше решение: сделать акцент на мобильном клиент-банке для физических лиц.
В начале работы с проектом важно правильно выбрать стратегию тестирования. Рассмотрим на примерах, почему она важна и как ее выбирать.
Стратегия тестирования должна отвечать бизнес-целям
Рано или поздно все компании сталкиваются с необходимостью организовать процесс тестирования и приходят к пониманию, что выстраивание его стратегии — важный этап разработки ПО. Порой — через собственный горький опыт. Особенно опасно недооценивать роль тестирования и подбора стратегии при разработке масштабных проектов. Процесс тестирования должен подбираться под бизнес-цели и специфику проекта, иначе не приведет к положительным результатам ни через месяц, ни через год.
Например, рассмотрим тестирование мобильного и веб-приложения для банка. На старте проекта мы подобрали стратегию, основанную на требованиях с невысоким уровнем детализации. Мы использовали чек-листы, чтобы сократить время на тестирование и поддержку тестового базиса. По мере роста функциональности, добавления эквайринга, sms-авторизации и оповещения, более сложных систем чек-листы уже не справлялись со своей задачей. Со временем в команду подключалось все больше QA-специалистов, нужно было передавать информацию и координировать их действия. С усложнением продукта любое изменение могло повлиять на смежные функции, то есть возрастал риск регрессии. Назревала необходимость автоматизации регрессионных тестов, поэтому мы переключились на тест-кейсы.
Вывод: в зависимости от проекта, его специфики или этапа разработки стратегия тестирования меняется.
Стратегию нужно подбирать под цели проекта, чтобы наилучшим способом обеспечить качество выпускаемого продукта. Она отвечает на вопросы «что», «где» и «когда» будет тестироваться. В любой момент времени вы знаете, в какой точке находитесь и куда придете в дальнейшем — согласно стратегии.
Бизнес-целью может быть обеспечение безопасности данных заказчика, а также самого ПО на этапе продакшена. Безопасность начинается с процесса разработки и продолжается на этапе тестирования.
Например, на одном из проектов мы создали безопасную среду для разработки и тестирования, разворачивали инфраструктуру, которая соответствовала всем требованиям и помогала защитить данные. Запрашивали сертифицированные токены и именные флешки для каждого QA-специалиста для доступа к тестовой инфраструктуре. Так мы обеспечивали бизнес-цель проекта в безопасности ПО и сохраняли конфиденциальность данных клиента и пользователя.
За счет стратегии тестирования можно сделать акцент на действительно важных аспектах для конкретного проекта. Логично, что выпуск мобильной игры или сложной банковской CRM-системы требует разных подходов к тестированию.
Стратегия тестирования в банковской сфере
Мы в компании SimbirSoft в своей практике применяли весь спектр методологий разработки, но приоритетными для нас всегда остаются гибкие технологии. И даже там, где по ряду причин нет возможности их использовать, команда берет на вооружение лучшие практики и применяет их в повседневной работе. Тестирование становится органичной частью всего процесса и вливается в общий воркфлоу. В этом случае оно отвечает не только за качество продукта, но даже за качество всего процесса работы.
Какие технологии мы используем:
В полную силу стратегия тестирования раскрывает себя в проектах со сложной бизнес-логикой. Например, ПО для информационного обеспечения банков, построение системы интернет-эквайринга, автоматизированная торговая площадка. В таких проектах важно применять подходящую стратегию тестирования, так как цена некоторых ошибок может привести к реальным убыткам и сильно повлиять на репутацию компании в худшую сторону.
Также к основным целям тестирования — поиск дефектов и проверка ПО на соответствие требованиям — могут добавляться дополнительные. Например, банкам важно быстро внедрять новые требования Центробанка. Это значит, что к основной цели добавится своевременное выполнение тестирования с требуемым качеством для критичных задач.
Недавно в проекте банковской сферы мы столкнулись с изменением в федеральном законодательстве — повышением ставки НДС с 18% до 20%. Для адаптации под изменение законодательства была проделана предварительная большая работа, так как изменение касалось не только замены форм, интерфейсов, но и переделки логики нескольких формул расчета. Необходимо было обеспечить правильное отображение на многих платформах. Также в функции отложенного платежа нужно было учесть переходный период со ставками 18% и 20%.
Теперь расскажем более подробно о том, как мы выстраиваем стратегию и почему часто выбираем тестирование на основе рисков.
Плюсы тестирования на основе рисков
Существует несколько стратегий тестирования, которые выбираются под определенные цели:
В случае работы с проектами со сложной бизнес-логикой нужно определить жесткие требования при проектировании систем, на которых в дальнейшем строится тестирование. Подходящий инструмент — это тестирование, основанное на требованиях.
Один из видов стратегии, основанной на требованиях — тестирование на основе рисков. При этом в первую очередь тестируются те части функциональности системы, которые наиболее подвержены рискам. Риск — это возможное негативное последствие неправильной работы системы. Последствие является риском при наличии двух составляющих, таких как возможность и негативность.
Риски бывают двух типов:
Он может быть управляемым и неуправляемым. В примере выше мы столкнулись с управляемым риском: быстрый рост и усложнение функциональности, в связи с чем повышалась вероятность регрессии. Здесь мы решали проблему наличием понятной тестовой базы и последующей автоматизацией. Тот риск, на который мы не можем повлиять — зависимость от внешних систем и их отказ в процессе интеграции. Здесь мы закладываем мероприятия, которые позволят снизить их влияние на нашу систему. Например, использование резервного копирования, обработка исключительных случаев, вывод предупреждений для пользователя.
Например, на проекте мы столкнулись с тем, что заказчик раньше не работал с распределенной командой, в связи с чем используемый воркфлоу не отвечал требованиям и создавал дополнительные коммуникационные проблемы: отсутствие понимания, дублирование задач, выполнение взаимоисключающих задач и так далее. Мы договорились о перестройке и улучшении процесса — переработали воркфлоу, познакомили всех членов команды, провели митинги, презентации и ретроспективы. В итоге работа пошла в нужном русле.
Risk-based подход позволяет составить некое количество рисков, за короткий срок протестировать риски с высоким приоритетом и дальше предоставлять заказчику метрики, насколько качественно их протестировали, показывая количество запланированных и пройденных кейсов и количество дефектов.
Имплементация risk-based подхода на проекте проходит в четыре этапа:
Risk Identification — на этом этапе нужно проидентифицировать риски и получить их список.
Risk Assessment — здесь мы анализируем список и классифицируем его по приоритетности.
Risk Mitigation — на этом этапе определяем, как глубоко будем тестировать риски.
Risk Management — здесь решаем, как дальше будем работать с ними и проходить их, идентифицировать новые риски.
Риски выявляются и оцениваются группой заинтересованных сторон в ходе сессий мозговых штурмов. В команду должны входить бизнес-аналитики или носители знаний о системе от заказчика, разработчики, менеджер или руководитель проекта, архитекторы, QA-специалисты. К выявлению и оценке рисков мы привлекаем в том числе специалистов по информационной безопасности, сотрудников, которые непосредственно работают с текущей системой, бизнес-аналитика, который погружен в процессы.
Рассмотрим risk-based подход на примере тестирования системы интернет-эквайринга.
Работа с рисками (на примере системы интернет-эквайринга)
Выделим следующие требования:
D1.Обеспечение 1000 одновременных подключений к системе в секунду.
D2. Безопасность совершения транзакций.
D3. Доступ к транзакции должен быть только у лица, совершающего транзакции.
D4. Обеспечение и поддержка стандарта SET (Secure Electronic Transaction).
В качестве риска продукта мы можем выделить:
RP1. Падение системы при одновременных подключениях.
RP2. Использование SQL инъекций в процессе совершения транзакции.
RP3. Доступ к чужой транзакции при смене параметров в URL.
RP4. Потеря данных при обрыве связи с банком в момент совершения транзакции.
RP5. Использование недействующих сертификатов при обеспечении системы SET (Secure Electronic Transaction).
В качестве организационных рисков:
RO1. Падение разрабатываемой системы из-за недоступности внешних систем.
RO2. Наличие трудно воспроизводимых кейсов, которые не могут быть обнаружены в тестовой среде.
Таким образом, каждый риск логически вытекает из требований, которые есть в системе, но не ограничивается ими. Риски дополняют требования и выявляют дополнительные кейсы, которые могут возникнуть при работе с системой.
Риски могут быть снижены или компенсированы в зависимости от целей проекта и требований к системе. Принимается условие, чтобы риск был покрыт тест-кейсом хотя бы один раз:
1. На каждый продуктовый риск подготавливается набор тест-кейсов RP1-RP4 с условием, что каждое требование и каждый риск должен быть покрыт хотя бы одним тест-кейсом. В зависимости от целей тестирования происходит расширение набора тест-кейсов до определенного уровня детализации.
2. На каждый организационный риск подготавливается список мероприятий, которые могут снизить влияние риска на разрабатываемый продукт.
Методики оценки и управления рисками
Существует несколько методик оценки и управления рисками: легковесные методы (PRAM, PRISMA) и более формальные (FMEA, FTA).
При модели FMEA команда проекта выявляет все процессы, компоненты, модули системы, в которых может произойти отказ системы или ошибка, способные привести к ухудшению качества продукта. В ходе брейншторма определяются риски системы по трем показателям: серьезность, приоритетность, вероятность. Затем просчитывается Risk Priority Number для каждого риска и в зависимости от показателей закладывается глубина тестирования.
При модели FTA поэтапно определяются все причины, которые могут привести к дефектам в бизнес-процессах системы. Анализ проходит от самого высокого до самого низкого уровня. Разница между FMEA и FTA в том, что первый подход сосредоточен на функциональности системы, а второй — на бизнес-процессах.
Помимо этих формальных и тяжеловесных подходов существуют более гибкие и неформальные. Например, методы PRAM (Прагматический анализ и управление рисками) и PRISMA (Управление рисками продукта). Они успешно и легко комбинируют стратегии, основанные на риске и требованиях. В основном в этих подходах используют спецификации требований в качестве входных данных, но в процессе могут участвовать и заинтересованные стороны.
Легковесные методы анализа рисков очень похожи на формальные. Они делают упор на технические или коммерческие риски, взвешивая вероятность возникновения риска и факторы, влияющие на эту вероятность.
Однако, единственные два фактора, используемые этими методами — это вероятность риска и его влияние. Кроме того, в этих подходах применяют упрощенные качественные суждения и шкалы для принятия решения.
Наши команды используют гибкие легковесные методы и адаптируют подходы PRAM и PRISMA под свои цели.
Как мы работаем с тестированием на основе рисков
Например, на одном из проектов мы определяем проектные и продуктовые риски, которые могут сработать. Для этого в анализе участвуют аналитики, разработчики и QA — по одному представителю от команды.
Формируется таблица рисков с продуктами. По ним определяется оценка вероятности срабатывания риска и его возможного влияния на систему по пятибалльной шкале. В таблице 1 — самое сильное влияние, 5 — самое слабое. Также и для вероятности 1 — большая вероятность, 5 — небольшая вероятность.
Как мы дальше работаем с рисками продукта
Далее по каждому из них происходит трассировка покрытия риска продукта тест-кейсами.
Выбираем следующие проверки:
TC1. Проверка нагрузки при наличии более 1000 подключений к системе
ТС2. Проверка нагрузки при 1000 подключений к системе
ТС3. Ввод SQL-инъекции во время совершения транзакции
ТС4. Ввод SQL-инъекции на странице успешной транзакции, путем подстановки других данных
ТС5. Ввод XSS (Cross-Site Scripting) скриптов в доступные поля для ввода при совершении транзакции
ТС6. Имитация разрыва связи с интернетом в процессе транзакции
ТС7. Выход из сеанса транзакции на этапе подтверждения
ТС8. Проверка просроченных сертификатов при совершении транзакции
Таким образом, приоритетные проверки — это TC2, ТС4, ТС5.
ТС6 и ТС8 имеют высокое влияние, но меньшую вероятность, поэтому приоритет проверки по ним ниже, но проверки тоже обязательны.
ТС7 не относится ни к одному из требований, но расширяет проверку на негативный сценарий, который возможен при стабильной работе системы.
Как мы дальше работаем с рисками проекта
Также определяем действия для проектных рисков, по которым назначаем дополнительные мероприятия и решения.
По риску «RO2. Наличие трудновоспроизводимых кейсов, которые не могут быть обнаружены в тестовой среде» можно предпринять следующее:
Запасной план
Важно иметь план действий на тот случай, если один из продуктовых или проектных рисков сработает. Иногда может спасти настройка системы резервного копирования проекта. Не всегда можно снизить риск до минимального уровня, но должна быть возможность уменьшить хотя бы его последствия. На эту тему был наш пост «Рождественская история»: как может сработать риск, вероятность которого стремится к нулю.
Например, мы должны полностью исключить потерю данных во время транзакции, но учесть все случаи слишком трудозатратно. Поэтому нужно иметь способы обработки таких случаев. Один из вариантов подстраховки — разработка более подробного логирования. Это обеспечит постоянную точку отката к предыдущему действию, если в процессе совершения транзакции что-то пошло не так.
Заключение
Тестирование на основе рисков позволяет покрывать наиболее рискованные области тест-кейсами, тем самым снижая их влияние и вероятность срабатывания. Это наиболее выигрышная стратегия для систем со сложной бизнес-логикой и высокой ценой ошибки. Решение подходит для банковского сектора, страховых компаний, сложных внутренних CRM-систем медицинского профиля. При risk-based подходе мы также работаем с проектными рисками, благодаря чему совершенствуется общий процесс тестирования и управления проектом.
