Для обеспечения качества информационного продукта в медицине, страховании, банкинге и других отраслях, наряду с другими методами тестирования, важно использовать тестирование, основанное на рисках. Для проверки выбирают самые рискованные области создаваемого программного обеспечения. Это позволяет предусмотреть негативные сценарии и успешно реализовать бизнес-цели заказчика.
В статье расскажем, как мы в компании SimbirSoft работали с рисками (на примере системы интернет-эквайринга и других проектов) и какие методики оценки и управления рисками мы используем в проектах заказчиков.
Для начала приведем пример из нашей практики в разработке для банковского сектора.
Предложение заказчика: сделать акцент на веб-версии банка для физических лиц.
Выявленный нами риск: возможная потеря аудитории из-за низкого спроса веб-версии у физических лиц, в отличие от мобильного клиент-банка.
Наши аргументы: статистика предпочтений пользователей на основе отзывов и распределения аудитории по мобильной и веб-версии.
Выводы: физическим лицам более удобна мобильная версия, так как телефон всегда под рукой. Операции совершаются быстро, система авторизации позволяет получить доступ ко всем удобным услугам. В этом случае важен быстрый доступ к ограниченному набору самых популярных функций.
Юридическим лицам важна полнота предоставляемых функций, возможность выгрузки, распечатки и работа с большим объемом информации. Для этого более удобна веб-версия.
Наше решение: сделать акцент на мобильном клиент-банке для физических лиц.
В начале работы с проектом важно правильно выбрать стратегию тестирования. Рассмотрим на примерах, почему она важна и как ее выбирать.
Рано или поздно все компании сталкиваются с необходимостью организовать процесс тестирования и приходят к пониманию, что выстраивание его стратегии — важный этап разработки ПО. Порой — через собственный горький опыт. Особенно опасно недооценивать роль тестирования и подбора стратегии при разработке масштабных проектов. Процесс тестирования должен подбираться под бизнес-цели и специфику проекта, иначе не приведет к положительным результатам ни через месяц, ни через год.
Например, рассмотрим тестирование мобильного и веб-приложения для банка. На старте проекта мы подобрали стратегию, основанную на требованиях с невысоким уровнем детализации. Мы использовали чек-листы, чтобы сократить время на тестирование и поддержку тестового базиса. По мере роста функциональности, добавления эквайринга, sms-авторизации и оповещения, более сложных систем чек-листы уже не справлялись со своей задачей. Со временем в команду подключалось все больше QA-специалистов, нужно было передавать информацию и координировать их действия. С усложнением продукта любое изменение могло повлиять на смежные функции, то есть возрастал риск регрессии. Назревала необходимость автоматизации регрессионных тестов, поэтому мы переключились на тест-кейсы.
Вывод: в зависимости от проекта, его специфики или этапа разработки стратегия тестирования меняется.
Стратегию нужно подбирать под цели проекта, чтобы наилучшим способом обеспечить качество выпускаемого продукта. Она отвечает на вопросы «что», «где» и «когда» будет тестироваться. В любой момент времени вы знаете, в какой точке находитесь и куда придете в дальнейшем — согласно стратегии.
Бизнес-целью может быть обеспечение безопасности данных заказчика, а также самого ПО на этапе продакшена. Безопасность начинается с процесса разработки и продолжается на этапе тестирования.
Например, на одном из проектов мы создали безопасную среду для разработки и тестирования, разворачивали инфраструктуру, которая соответствовала всем требованиям и помогала защитить данные. Запрашивали сертифицированные токены и именные флешки для каждого QA-специалиста для доступа к тестовой инфраструктуре. Так мы обеспечивали бизнес-цель проекта в безопасности ПО и сохраняли конфиденциальность данных клиента и пользователя.
За счет стратегии тестирования можно сделать акцент на действительно важных аспектах для конкретного проекта. Логично, что выпуск мобильной игры или сложной банковской CRM-системы требует разных подходов к тестированию.
Мы в компании SimbirSoft в своей практике применяли весь спектр методологий разработки, но приоритетными для нас всегда остаются гибкие технологии. И даже там, где по ряду причин нет возможности их использовать, команда берет на вооружение лучшие практики и применяет их в повседневной работе. Тестирование становится органичной частью всего процесса и вливается в общий воркфлоу. В этом случае оно отвечает не только за качество продукта, но даже за качество всего процесса работы.
Какие технологии мы используем:
В полную силу стратегия тестирования раскрывает себя в проектах со сложной бизнес-логикой. Например, ПО для информационного обеспечения банков, построение системы интернет-эквайринга, автоматизированная торговая площадка. В таких проектах важно применять подходящую стратегию тестирования, так как цена некоторых ошибок может привести к реальным убыткам и сильно повлиять на репутацию компании в худшую сторону.
Также к основным целям тестирования — поиск дефектов и проверка ПО на соответствие требованиям — могут добавляться дополнительные. Например, банкам важно быстро внедрять новые требования Центробанка. Это значит, что к основной цели добавится своевременное выполнение тестирования с требуемым качеством для критичных задач.
Недавно в проекте банковской сферы мы столкнулись с изменением в федеральном законодательстве — повышением ставки НДС с 18% до 20%. Для адаптации под изменение законодательства была проделана предварительная большая работа, так как изменение касалось не только замены форм, интерфейсов, но и переделки логики нескольких формул расчета. Необходимо было обеспечить правильное отображение на многих платформах. Также в функции отложенного платежа нужно было учесть переходный период со ставками 18% и 20%.
Теперь расскажем более подробно о том, как мы выстраиваем стратегию и почему часто выбираем тестирование на основе рисков.
Существует несколько стратегий тестирования, которые выбираются под определенные цели:
В случае работы с проектами со сложной бизнес-логикой нужно определить жесткие требования при проектировании систем, на которых в дальнейшем строится тестирование. Подходящий инструмент — это тестирование, основанное на требованиях.
Один из видов стратегии, основанной на требованиях — тестирование на основе рисков. При этом в первую очередь тестируются те части функциональности системы, которые наиболее подвержены рискам. Риск — это возможное негативное последствие неправильной работы системы. Последствие является риском при наличии двух составляющих, таких как возможность и негативность.
Риски бывают двух типов:
1. Риск продукта
Он может быть управляемым и неуправляемым. В примере выше мы столкнулись с управляемым риском: быстрый рост и усложнение функциональности, в связи с чем повышалась вероятность регрессии. Здесь мы решали проблему наличием понятной тестовой базы и последующей автоматизацией. Тот риск, на который мы не можем повлиять — зависимость от внешних систем и их отказ в процессе интеграции. Здесь мы закладываем мероприятия, которые позволят снизить их влияние на нашу систему. Например, использование резервного копирования, обработка исключительных случаев, вывод предупреждений для пользователя.
2. Риск проекта
Например, на проекте мы столкнулись с тем, что заказчик раньше не работал с распределенной командой, в связи с чем используемый воркфлоу не отвечал требованиям и создавал дополнительные коммуникационные проблемы: отсутствие понимания, дублирование задач, выполнение взаимоисключающих задач и так далее. Мы договорились о перестройке и улучшении процесса — переработали воркфлоу, познакомили всех членов команды, провели митинги, презентации и ретроспективы. В итоге работа пошла в нужном русле.
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 подходе мы также работаем с проектными рисками, благодаря чему совершенствуется общий процесс тестирования и управления проектом.
Спасибо за внимание!
Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
В статье расскажем, как мы в компании SimbirSoft работали с рисками (на примере системы интернет-эквайринга и других проектов) и какие методики оценки и управления рисками мы используем в проектах заказчиков.
Риски на старте проекта
Для начала приведем пример из нашей практики в разработке для банковского сектора.
Предложение заказчика: сделать акцент на веб-версии банка для физических лиц.
Выявленный нами риск: возможная потеря аудитории из-за низкого спроса веб-версии у физических лиц, в отличие от мобильного клиент-банка.
Наши аргументы: статистика предпочтений пользователей на основе отзывов и распределения аудитории по мобильной и веб-версии.
Выводы: физическим лицам более удобна мобильная версия, так как телефон всегда под рукой. Операции совершаются быстро, система авторизации позволяет получить доступ ко всем удобным услугам. В этом случае важен быстрый доступ к ограниченному набору самых популярных функций.
Юридическим лицам важна полнота предоставляемых функций, возможность выгрузки, распечатки и работа с большим объемом информации. Для этого более удобна веб-версия.
Наше решение: сделать акцент на мобильном клиент-банке для физических лиц.
В начале работы с проектом важно правильно выбрать стратегию тестирования. Рассмотрим на примерах, почему она важна и как ее выбирать.
Стратегия тестирования должна отвечать бизнес-целям
Рано или поздно все компании сталкиваются с необходимостью организовать процесс тестирования и приходят к пониманию, что выстраивание его стратегии — важный этап разработки ПО. Порой — через собственный горький опыт. Особенно опасно недооценивать роль тестирования и подбора стратегии при разработке масштабных проектов. Процесс тестирования должен подбираться под бизнес-цели и специфику проекта, иначе не приведет к положительным результатам ни через месяц, ни через год.
Например, рассмотрим тестирование мобильного и веб-приложения для банка. На старте проекта мы подобрали стратегию, основанную на требованиях с невысоким уровнем детализации. Мы использовали чек-листы, чтобы сократить время на тестирование и поддержку тестового базиса. По мере роста функциональности, добавления эквайринга, sms-авторизации и оповещения, более сложных систем чек-листы уже не справлялись со своей задачей. Со временем в команду подключалось все больше QA-специалистов, нужно было передавать информацию и координировать их действия. С усложнением продукта любое изменение могло повлиять на смежные функции, то есть возрастал риск регрессии. Назревала необходимость автоматизации регрессионных тестов, поэтому мы переключились на тест-кейсы.
Вывод: в зависимости от проекта, его специфики или этапа разработки стратегия тестирования меняется.
Стратегию нужно подбирать под цели проекта, чтобы наилучшим способом обеспечить качество выпускаемого продукта. Она отвечает на вопросы «что», «где» и «когда» будет тестироваться. В любой момент времени вы знаете, в какой точке находитесь и куда придете в дальнейшем — согласно стратегии.
Бизнес-целью может быть обеспечение безопасности данных заказчика, а также самого ПО на этапе продакшена. Безопасность начинается с процесса разработки и продолжается на этапе тестирования.
Например, на одном из проектов мы создали безопасную среду для разработки и тестирования, разворачивали инфраструктуру, которая соответствовала всем требованиям и помогала защитить данные. Запрашивали сертифицированные токены и именные флешки для каждого QA-специалиста для доступа к тестовой инфраструктуре. Так мы обеспечивали бизнес-цель проекта в безопасности ПО и сохраняли конфиденциальность данных клиента и пользователя.
За счет стратегии тестирования можно сделать акцент на действительно важных аспектах для конкретного проекта. Логично, что выпуск мобильной игры или сложной банковской CRM-системы требует разных подходов к тестированию.
Стратегия тестирования в банковской сфере
Мы в компании SimbirSoft в своей практике применяли весь спектр методологий разработки, но приоритетными для нас всегда остаются гибкие технологии. И даже там, где по ряду причин нет возможности их использовать, команда берет на вооружение лучшие практики и применяет их в повседневной работе. Тестирование становится органичной частью всего процесса и вливается в общий воркфлоу. В этом случае оно отвечает не только за качество продукта, но даже за качество всего процесса работы.
Какие технологии мы используем:
- гибкое планирование и подготовка внутренних релизов;
- подготовка user story;
- проведение статус-митингов;
- проведение ретроспектив.
В полную силу стратегия тестирования раскрывает себя в проектах со сложной бизнес-логикой. Например, ПО для информационного обеспечения банков, построение системы интернет-эквайринга, автоматизированная торговая площадка. В таких проектах важно применять подходящую стратегию тестирования, так как цена некоторых ошибок может привести к реальным убыткам и сильно повлиять на репутацию компании в худшую сторону.
Также к основным целям тестирования — поиск дефектов и проверка ПО на соответствие требованиям — могут добавляться дополнительные. Например, банкам важно быстро внедрять новые требования Центробанка. Это значит, что к основной цели добавится своевременное выполнение тестирования с требуемым качеством для критичных задач.
Недавно в проекте банковской сферы мы столкнулись с изменением в федеральном законодательстве — повышением ставки НДС с 18% до 20%. Для адаптации под изменение законодательства была проделана предварительная большая работа, так как изменение касалось не только замены форм, интерфейсов, но и переделки логики нескольких формул расчета. Необходимо было обеспечить правильное отображение на многих платформах. Также в функции отложенного платежа нужно было учесть переходный период со ставками 18% и 20%.
Теперь расскажем более подробно о том, как мы выстраиваем стратегию и почему часто выбираем тестирование на основе рисков.
Плюсы тестирования на основе рисков
Существует несколько стратегий тестирования, которые выбираются под определенные цели:
- основанные на требованиях;
- методические;
- реактивные стратегии;
- консультативные стратегии.
В случае работы с проектами со сложной бизнес-логикой нужно определить жесткие требования при проектировании систем, на которых в дальнейшем строится тестирование. Подходящий инструмент — это тестирование, основанное на требованиях.
Один из видов стратегии, основанной на требованиях — тестирование на основе рисков. При этом в первую очередь тестируются те части функциональности системы, которые наиболее подвержены рискам. Риск — это возможное негативное последствие неправильной работы системы. Последствие является риском при наличии двух составляющих, таких как возможность и негативность.
Риски бывают двух типов:
1. Риск продукта
Он может быть управляемым и неуправляемым. В примере выше мы столкнулись с управляемым риском: быстрый рост и усложнение функциональности, в связи с чем повышалась вероятность регрессии. Здесь мы решали проблему наличием понятной тестовой базы и последующей автоматизацией. Тот риск, на который мы не можем повлиять — зависимость от внешних систем и их отказ в процессе интеграции. Здесь мы закладываем мероприятия, которые позволят снизить их влияние на нашу систему. Например, использование резервного копирования, обработка исключительных случаев, вывод предупреждений для пользователя.
2. Риск проекта
Например, на проекте мы столкнулись с тем, что заказчик раньше не работал с распределенной командой, в связи с чем используемый воркфлоу не отвечал требованиям и создавал дополнительные коммуникационные проблемы: отсутствие понимания, дублирование задач, выполнение взаимоисключающих задач и так далее. Мы договорились о перестройке и улучшении процесса — переработали воркфлоу, познакомили всех членов команды, провели митинги, презентации и ретроспективы. В итоге работа пошла в нужном русле.
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. Наличие трудновоспроизводимых кейсов, которые не могут быть обнаружены в тестовой среде» можно предпринять следующее:
- подготовить стенд «предпродакшн», который максимально приближен к реальной среде приложения, в связке со всеми внешними системами;
- написать сценарии end-to-end тестирования, которые проходят сквозь все смежные системы и обеспечивают проверку транзакции;
- после проведения всех приоритетных проверок использовать техники error guessing по основным требованиям системы и сценарии дополнительных проверок в роли «взломщика системы».
Запасной план
Важно иметь план действий на тот случай, если один из продуктовых или проектных рисков сработает. Иногда может спасти настройка системы резервного копирования проекта. Не всегда можно снизить риск до минимального уровня, но должна быть возможность уменьшить хотя бы его последствия. На эту тему был наш пост «Рождественская история»: как может сработать риск, вероятность которого стремится к нулю.
Например, мы должны полностью исключить потерю данных во время транзакции, но учесть все случаи слишком трудозатратно. Поэтому нужно иметь способы обработки таких случаев. Один из вариантов подстраховки — разработка более подробного логирования. Это обеспечит постоянную точку отката к предыдущему действию, если в процессе совершения транзакции что-то пошло не так.
Заключение
Тестирование на основе рисков позволяет покрывать наиболее рискованные области тест-кейсами, тем самым снижая их влияние и вероятность срабатывания. Это наиболее выигрышная стратегия для систем со сложной бизнес-логикой и высокой ценой ошибки. Решение подходит для банковского сектора, страховых компаний, сложных внутренних CRM-систем медицинского профиля. При risk-based подходе мы также работаем с проектными рисками, благодаря чему совершенствуется общий процесс тестирования и управления проектом.
Спасибо за внимание!
Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
