Пока нет оценок.
Пожалуйста, подождите...

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

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

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

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

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

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

Аргументы 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-систем.

Оставить комментарий

WP Facebook Auto Publish Powered By : XYZScripts.com