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

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

Для подобных тестов стоит подобрать наиболее рискованные моменты логики разрабатываемого ПО. Подобная тактика позволяет предусмотреть все негативные сценарии поведения веб-продукта и максимально быстро реализовать все установленные со стороны клиента бизнес-цели.

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

Группа рисков на старте разработки

Пожелание клиента – основной акцент функционала веб-продукта на взаимодействие банка с физическими лицами.

Найденный риск – потенциальная потеря части аудитории из-за малого спроса веб-версии продукта со стороны физических лиц, в отличие от мобильной версии ПО (приложение клиент-банка).

Аргументы QA – текущая статистика предпочтений пользователей на базе отзывов и процесса распределения аудитории по числу скачиваний веб- и мобильной версии ПО.

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

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

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

Теперь рассмотрим выбор правильной стратегии тестирования.

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

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

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

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

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

Вывод: стратегия тестирования может кардинальным образом меняться с учетом специфики проекта и количества этапов разработки.

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

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

Особенности и компоненты проверок на основе рисков

Компоненты тестирования на основе оценки риска

На практике существует сразу несколько разновидностей стратегий тестирования, которые подбираются для достижения определенных целей:

1. Тестирование на основе требований;
2. Методические проверки;
3. Реактивные стратегии;
4. Консультативные стратегии.

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

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

Риск – это потенциальное негативное последствие неправильного функционирования определенной системы. Любое последствие может быть риском при одновременном наличии 2 составляющих: негативность и возможность.

Все риски можно поделить на 2 типа:

• Риск веб-продукта. В зависимости от ситуации он может быть управляемым или неуправляемым. Управляемый можно охарактеризовать как усложнение функциональности, которое приводит к регрессии, вследствие чего проектная группа сталкивается с необходимостью решения некоторых задач (например, создание резервных копий, обработка определенной информации, вывод специальных сообщений). Неуправляемый риск – это текущая зависимость логики веб-продукта от внешних систем и их зафиксированный отказ в надлежащем функционировании.
• Риск проекта. Определенная группа сложностей и непредвиденных ситуаций, которые случаются на проектах. Для решения подобных (профильных задач) обычно используют методологию на основе оценки риска, которая позволяет заранее определить некоторое число таких рисков, сгруппировать их в зависимости от приоритета важности и выполнить соответствующие проверки. В течение постепенного выполнения тестов, клиент получает аналитические метрики, в которых детально описано, что и как было протестировано, какие кейсы удалось выполнить и какова тенденция будущего нахождения багов в смежном функционале.

Методику на основе оценки риска можно поделить на 4 этапа:

1. Выявление рисков – на данной стадии необходимо зафиксировать все потенциальные риски и составить их список;
2. Оценка рисков – анализ рисков по степени их приоритетности;
3. Уменьшение рисков – стадия, на которой нужно определить уровень тестирования рисков;
4. Управление рисками – решается вопрос касательно того, как поступать дальше, если ранее не найденные риски будут обнаружены при внедрении будущего блока функционала.

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

К слову, для полного понимания методики оценки риска мы рассмотрим способ проверки платформы интернет-эквайринга.

Взаимодействие с рисками

(на основе платформы интернет-эквайринга)

Например, у нас есть следующие требования:

• до 1000 одновременных подключений;
• полная безопасность выполнения финансовых операций;
• персонализированный доступ к транзакции только у лица, которое совершает финансовую операцию;
• поддержка стандарта безопасности SET (Secure Electronic Transaction).

В группу рисков можно отнести следующие ситуации:

• сбой системы при максимальном количестве одновременных подключений;
• применение хакерами SQL-инъекций при махинациях во время транзакций;
• несанкционированный доступ к сторонним транзакциям при редактировании параметров URL;
• потеря конфиденциальных данных во время обрыва связи с банком при совершении финансовой операции;
• применение просроченных сертификатов при обеспечении платформы SET.

Есть еще и группа организованных рисков:

• незапланированное падание системы из-за недоступности внешней архитектуры;
• работа с трудновоспроизводимыми кейсами, которые априори не могут быть найдены в проверяемой среде.

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

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

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

Природа методики оценки и управления рисками

В сегодняшней практике тестирования используется сразу несколько оценок и управлений рисками: легкие методы (PRAM и PRISMA) и более классические (формальные) – FTA и FMEA.

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

При работе с методикой FTA анализируются все причины, которые могут быть катализаторами багов внутри бизнес-процессов системы. Аналитика строится от самого главного риска к самому легкому.

Вся разница в этих двух методиках в том, что первый заточен исключительно на функциональности ПО, а второй –на природе бизнес-процессов.

Кроме этих традиционных и очень затратных по времени процессов есть и весьма гибкие подходы. Например, метод PRAM (прагматический анализ и управление рисками), а также PRISMA (управление рисками ПО).

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

Легкие методы очень схожи по своей природе с классическими. С их помощью делается упор на коммерческие и технические риски, проводится аналитика всех рисков и факторов, которые могут повлиять на вероятность наступления нежелательной ситуации.

Итоги

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

Такие проверки со стороны компаний по контролю качества весьма востребованы в сфере банковского дела, страховых фирмах, а также при необходимости создания сложных корпоративных CRM-систем.