Тестирование на основе рисков и анализ видов и последствий отказов

Риск – это вероятность негативного или нежелательного результата или события. Риск — это любая проблема, которая может привести к снижению восприятия клиентом, пользователем, заинтересованными сторонами качества и/или успеха проекта.

Виды рисков:
Существует 2 типа рисков: риск продукта и риск качества.

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

Не все риски одинаково важны. Существует несколько способов классификации уровня риска. Самый простой способ - посмотреть на два фактора:

1. Вероятность возникновения проблемы. Вероятность вытекает из технических соображений.
2. Влияние проблемы, если она возникает. Влияние возникает из деловых соображений.

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

1. Доступ к риску на основе качества программного обеспечения.
2. Частота использования.
3. Критичность бизнеса.
4. Возможные участки с дефектами и т.д.

Характеристики тестирования, основанного на оценке рисков (RBT):
Ниже приведены некоторые характеристики тестирования на основе рисков (RBT):

1. Стратегия RBT сопоставляет уровень усилий по тестированию с уровнем риска. Чем выше риск, тем больше усилий по тестированию. Это относится к выполнению тестов, а также к другим тестовым действиям, таким как разработка и реализация тестов.
2. Он соответствует порядку тестирования с уровнем риска. Тесты с более высоким риском, как правило, обнаруживают больше дефектов или связаны с более важными областями приложения, а может быть и с тем и с другим. Чем выше риск, тем раньше мы планируем тесты в цикле — как при разработке, так и при выполнении. Это также помогает укрепить доверие заинтересованных сторон бизнеса.
3. Распределяя усилия и поддерживая порядок тестирования, риск качества систематически и предсказуемо снижается. Поддерживая матрицу прослеживаемости тестов по сравнению с рисками и дефектами, идентифицированными как риски, отчетность о риске как об остаточном риске имеет смысл. Это позволяет заинтересованным сторонам решить, когда прекратить тестирование, т. е. всякий раз, когда риск продолжения тестирования превышает риск завершения тестирования.
4. Если сокращение графика требует сокращения масштабов, легче решить, что нужно убрать. Это всегда будет приемлемо и объяснимо для заинтересованных сторон, поскольку уровни риска согласованы.
5. Для выявления рисков нам необходимо получать данные из различных источников, таких как спецификации требований, проектные спецификации, данные о существующих приложениях, записи о предыдущих инцидентах и т. д. Однако, если эта информация недоступна, мы все же можем использовать этот подход, получая данные из заинтересованные стороны для процесса выявления и оценки рисков.

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

Когда внедрять тестирование на основе рисков?
Подход к тестированию на основе рисков реализуется в сценариях, где:

1. Есть ограничения по времени/ресурсам или бюджету. Например, исправление для развертывания в рабочей среде.
2. Когда реализуется доказательство концепции.
3. Когда команда плохо знакома с технологической платформой или тестируемым приложением.
4. При тестировании в инкрементных моделях или итеративных моделях.
5. Тестирование безопасности проводится в средах облачных вычислений.
   

Как реализуется тестирование на основе рисков?
Риск может направлять тестирование несколькими способами, но ниже приведены основные из них:

1. Усилия распределяются менеджерами тестирования пропорционально к риску, связанному с тестируемым элементом.
2. Методы тестирования выбираются таким образом, чтобы строгость и полнота, требуемые в зависимости от уровня риска объекта тестирования.
3. Тестовые действия должны выполняться в обратном порядке. порядок риска, т.е. Элемент с наивысшим риском должен быть протестирован первым.
4. Приоритизация и устранение дефектов должны осуществляться в соответствии с уровнем риска.
5. Во время планирования и контроля тестирования менеджеры тестирования должны осуществлять контроль рисков для всех существенных элементов риска. Чем выше уровень связанного с этим риска, тем тщательнее его следует контролировать.
6. Отчетность должна быть сделана с точки зрения остаточных рисков. Пример. Какие тесты еще не запущены? Какие дефекты еще не устранены?

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

Преимущества тестирования на основе рисков (RBT):
Путем выявления и анализа рисков, связанных с системой, можно сделать тестирование эффективным и результативным.

1. Эффективный-
   RBT эффективен, потому что вы тестируете наиболее важные области системы в начале цикла (чем раньше обнаружен дефект, тем ниже стоимость решения этих проблем).
2. Эффективный-
   RBT эффективен, потому что ваше время тратится в соответствии с рейтингом рисков и планами снижения рисков. Вы не тратите время на предметы и действия, которые могут быть не очень важны в общей схеме вещей.
3. Сокращенные тестовые случаи-
   Количество тестовых наборов уменьшается по мере того, как тестовые наборы становятся более сфокусированными.
4. Снижение цены-
   Снижение затрат на качество, поскольку критические проблемы устраняются в начале цикла и, следовательно, снижение стоимости изменений.
5. Более быстрое время выхода на рынок-
   Более быстрый вывод продукта на рынок легче достижим при использовании RBT-подхода, поскольку наиболее важные функции доступны в готовом к поставке состоянии в начале цикла.

Анализ видов и последствий отказов (FMEA):
FMEA — это систематический метод, используемый для определения элементов риска качества, известных как виды отказов, т. е. он определяет, где и как тестируемая система может дать сбой, а затем оценивает относительное влияние различных отказов.
Шаги, вовлеченные в процесс:

1. Режимы отказа-
   Что может выйти из строя?
2. Причины отказа-
   Почему может произойти сбой?
3. Последствия отказа-
   Каков будет результат каждой неудачи?

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

Процесс FMEA:
В этом разделе подробно описывается процесс FMEA. Ниже приведены шаги-

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

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

3. После определения воздействия и серьезности также присвойте ранжирование возникновения.

1. Происшествие — это ранговое число, связанное с вероятностью того, что вид отказа и связанная с ним причина будут присутствовать в анализируемом элементе. Ранжирование возникновения имеет относительное значение, а не абсолютное значение, и определяется без учета серьезности или вероятности обнаружения.
2. Для FMEA системы и проекта ранжирование возникновения учитывает вероятность возникновения в течение проектного срока службы продукта.

4. Назначьте рейтинг обнаружения

1. Ранжирование обнаружения учитывает вероятность обнаружения вида/причины отказа в соответствии с определенными критериями.
2. Обнаружение является относительным ранжированием в рамках конкретного FMEA и определяется без учета серьезности или вероятности возникновения.

5. Рассчитайте номер приоритета риска.

1. RPN рассчитывается путем умножения трех столбцов подсчета очков:
   1. Серьезность (пункт 2).
   2. Возникновение (пункт 3).
   3. Обнаружение (пункт 4).

6. Разработать план действий по РПН.

1. Решите, над какими сбоями следует работать в первую очередь, на основе номеров приоритета риска. Самые высокие RPN получают наибольший приоритет.
2. Определите план действий, ответственное лицо и ожидаемую дату завершения.

7. Реализуйте план действий.

8. Переоцените и повторите.

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

Преимущества FMEA:
Ниже приведены преимущества FMEA-

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

Проблемы FMEA:
Ниже приведены проблемы FMEA-

1. Это требует большого количества документации и, следовательно, занимает много времени.
2. При попытке определить причины сбоев может быть сложно определить истинную причину по промежуточным последствиям.
3. Многие организации не понимают, что FMEA не является статической моделью. Для успешного управления рисками необходимо регулярно обновлять FMEA по мере выявления новых потенциальных видов отказов и разработки соответствующих планов контроля.