Приоритизация на основе оценки рисков — это важный шаг на пути достижения максимальной эффективности в кратчайшие сроки. Последовательное и правильное применение этого подхода обеспечивает оптимизацию всего процесса разработки программного обеспечения. Одна из важнейших задач заключается в определении возможности тестирования требований к ПО. Однако еще более важной и сложной задачей является приоритизация и категоризация требований с целью планирования и оптимизации процессов разработки и тестирования.
Если Вы хотите:
-
определить возможность тестирования ваших требований
-
количественно определить критичность требований
-
понять важность требований в вашем проекте до начала разработки
-
сократить расходы на тестирование дефектов, которые можно выявить на начальном этапе разработки ПО
Значит вам нужно использовать метод приоритизации на основе оценки рисков.
Этот метод поможет вам уточнить, переопределить и приоритизировать требования до начала разработки и тестирования.
В этой статье мы подробно расскажем об определении возможности тестирования требований, способах улучшения тестируемости требований, об основных аспектах приоритизации на основе оценки рисков, а также рассмотрим преимущества этого метода.
Определение возможности тестирования требований
Как часто вы видели, чтобы менеджеры проектов или руководители групп тестирования старались понять, насколько приемлемы для тестирования те или иные требования к ПО? Или чтобы требования анализировались в рамках «командного упражнения»? Ответом, скорее всего, будет «Очень редко».
Однако это одна из главных задач управления тестированием, от успеха решения которой зависит эффективность всего процесса тестирования.
Чтобы удостовериться, что требования будут тестируемыми, необходимо убедиться в их полноте, непротиворечивости, корректности, выполнимости и однозначности. Если они удовлетворяют этим пяти критериям, можно с уверенностью сказать, что данные требования являются тестируемыми и все члены вашей команды могут их понять и однозначно интерпретировать.
Определение возможности тестирования требований — это первый шаг процесса приоритизации на основе оценки рисков. Следующий вопрос: На каком этапе жизненного цикла разработки ПО или Agile-процесса необходимо определять тестируемость требований? Ответ вполне очевиден. На этапе анализа или планирования спринта бизнес-аналитики должны собрать все требования, а команда тестировщиков должна проверить эти требования и убедиться, что они являются значимыми и могут быть протестированы.
Скорее всего, на этапе анализа в случае жизненного цикла разработки ПО состав команды тестировщиков еще не определен, а в случае Agile не определен состав команды Scrum. Однако рекомендуется определить, по крайней мере, ключевых членов команды: руководителя группы, инженеров по тестированию и разработчиков, которые могут работать над уточнением требований.
Если все требования являются тестируемыми и вы в этом уверены, то это хорошая новость. Однако, если есть какие-то нетестируемые требования, то их можно сделать тестируемыми, применив метод приоритизации на основе оценки рисков.
Делаем требования тестируемыми
Например, одно из требований определено следующим образом: «Приложение должно выдавать сообщение о статусе или отключать пользователя в случае отсутствия его активности в течение примерно 60 секунд».
Если вы внимательно посмотрите на это определение, то увидите некоторые неоднозначности. У вас могут возникнуть следующие вопросы.
- О каком приложении идет речь?
- Должно оно только выдавать сообщение о статусе, или отключать пользователя, или делать и то и другое?
- Указан временной интервал «примерно 60 секунд». И неизбежно возникает вопрос: нужно ли отключать пользователя, если никакой активности нет на протяжении 50 секунд?
Из-за этих неоднозначностей данное требование невозможно протестировать. Члены команды могут интерпретировать его по-разному. Разработчики могут реализовать одну возможность, а тестировщики будут тестировать какую-то другую. В результате выпускаемый продукт не удовлетворит заказчика и не будет иметь никакой ценности. Ваша задача - сделать требование абсолютно ясным.
Чтобы иметь возможность его протестировать, необходимо составить список всех вопросов (неоднозначностей) и попросить бизнес-аналитиков найти на них ответы. Получив ответы, нужно обновить требования и передать их обновленную спецификацию всем членам команды. Выполнив эту задачу, мы можем перейти к процессу приоритизации требований на основе оценки рисков.
Сущность приоритизации на основе оценки рисков
Приоритизация на основе оценки рисков — это процесс, выполняемый с целью
- Проверить, являются ли требования тестируемыми
- Понять, что именно нужно тестировать
- Приоритизировать требования в зависимости от их критичности. Под критичностью понимается критичность для бизнес», а не с технической точки зрения.
Мы уже обсудили пункт первый этого определения выше. Вам понятно, как нужно оценивать требования по пяти важнейшим параметрам тестируемости и как затем их можно трансформировать в тестируемые требования.
Второй пункт определения: что именно нужно тестировать применительно к данным требованиям. В жизненном цикле разработки ПО каждое требование связано с определенным риском. Предположим, у вас есть такое требование: «Измените шрифт на веб-сайте компании». Даже это, на первый взгляд, простое требование сопряжено с определенным риском. Нам нужно понять, какие шаги необходимо предпринять, чтобы исключить этот риск.
Третий пункт — это суть процесса приоритизации на основе оценки рисков. При приоритизации на основе оценки рисков мы присваиваем численные значения некоторым входным параметрам каждого требования. Это параметры «Влияние» и «Вероятность».
Например, у вас есть 100 требований. Вы присваиваете численные значения этим входным параметрам для всех 100 требований. Обычно эти два параметра оцениваются по шкале от 1 до 3: 1 — низкий уровень, а 3 — высоки» уровень.
«Влияние» указывает на важность требования. С какими последствиями есть вероятность столкнуться, если это требование не будет правильно реализовано в готовом продукте? Такого рода последствия обозначаются словом «влияние».
Например, если уровень влияния «высокий», то ему можно присвоить значение 3. Если уровень «низкий», то его можно оценить как 1. В случае среднего уровня влияния, значение будет 2. Точно так же оценивается параметр «Вероятность».
«Вероятность» указывает на возможность возникновения сбоев или ошибок на этапе промышленной эксплуатации. Она также оценивается по шкале от 1 до 3.
Теперь на основе оценок, присвоенных параметрам «Влияние» и «Вероятность», для каждого требования рассчитываются уровни риска по следующей простой формуле:
Уровень риска = Влияние * Вероятность
Очевидно, что по этой формуле максимальный уровень риска равен 9 (т.е. Влияние * Вероятность = 3*3 = 9), а минимальный уровень риска равен 1. Таким образом, уровни риска варьируются в пределах от 1 до 9.
Определив уровни риска, мы можем разделить требования по группам с высоким, средним и низким уровнями риска, руководствуясь указанными ниже правилами.
Обратите внимание, что в зависимости от компании, в которой вы работаете, эти параметры и модель оценки могут различаться.
В левой части таблицы приведены правила категоризации требований, а в правой части показаны преобразования и сочетания, которые возможны при уровнях риска «Высокий», «Средний» и «Низкий».
Процесс приоритизации на основе оценки рисков
Приоритизация на основе оценки рисков — это процесс, осуществляемый под управлением руководителя группы тестирования. Он должен обеспечить эффективное проведение приоритизации на основе оценки рисков в рамках жизненного цикла разработки ПО. Этот процесс состоит из трех шагов.
Шаг 1. В конце этапа анализа руководитель группы тестирования передает членам команды перечень всех требований. Каждый член команды проверяет требования на предмет ясности. Руководитель группы организует совещание со всеми членами команды, а также с бизнес-аналитиками, заинтересованными лицами и разработчиками.
Шаг 2. На этом совещании каждый высказывается по поводу всех требований и предлагает значения вводных параметров («Влияние» и «Вероятность»).
Скорее всего, у членов команды будут разные оценки некоторых требований. В этом случае такие требования нужно обсудить и постараться прийти к единому мнению. Если кто-то продолжает настаивать на своем мнении, рекомендуется для начала выбрать более высокую оценку.
Шаг 3. Руководитель группы консолидирует все мнения и передает результаты приоритизации на основе оценки рисков с указанием уровня риска (высокий, средний и низкий) для каждого требования. Эти результаты могут быть представлены в следующем виде.
Исходя из этих данных, команды начинают работать над разработкой, тестированием и реализацией.
Преимущества приоритизации на основе оценки рисков
- Этот процесс позволяет определить тестируемость требований и сделать требования тестируемыми, если они не соответствуют критериям тестируемости.
- Можно сосредоточиться на задачах тестирования уже на этапе анализа требований.
- Все заинтересованные лица получают актуальную информацию о требованиях.
- Можно выявить критические важные требования. После этого можно больше внимания уделить тестированию данных требований.
- Возможно получить количественную оценку информации о рисках в рамках проекта.
- Кроме того, можно оптимизировать пользовательское приемочное тестирование, пропустив на этом этапе тесты требований с низким приоритетом. Однако для этого необходимо определить приемлемый уровень для бизнес-подразделений и привлечь их на свою сторону.
- Это поможет вам оптимизировать процесс тестирования.
Выводы
Приоритизация на основе оценки рисков — это метод, с помощью которого можно проанализировать требования еще на этапе сбора требований. Благодаря применению этого метода вы сможете сосредоточиться на тестировании и минимизировать количество дефектов, которые возникают в системе из-за неточных формулировок требований. При этом вы можете определить приоритеты и категории требований. Это поможет вам оптимизировать пользовательское приемочное тестирование. Приоритизация требований является основой тестирования и повышает эффективность процесса разработки ПО.
Автор статьи
Yogesh Sanjeevan Kshirsagar
Principal Consultant
Оригинал статьи