Примечание редактора: Добро пожаловать в серию статей "Лидерство в тестировании" от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы — особенно в гибких командах — преуспеть в своих ролях руководителя тестирования и менеджера по управлению. В предыдущей статье мы рассмотрели важность тестовых моделей. 

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

Риски, если они материализуются, оказывают негативное влияние на наши проекты. Управление рисками — это осмысление существующих рисков и принятие мер по снижению их вероятности, устранению или уменьшению их влияния на цели наших стейкхолдеров. 

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

С точки зрения тестирования и обеспечения качества, риск — это "тип неудачи, о котором следует беспокоиться”. Тестирование на основе рисков — это практика моделирования возможных режимов отказа системы как рисков продукта для определения объема тестирования, масштабирования и установления приоритетов. 

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

• Риски проекта, процесса и продукта 

• Манифест тестирования, основанного на риске 

• Классический подход к риску 

• Риски для продукта и тестирование 

• Практические аспекты 

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

Мы будем использовать следующее определение риска: Риск - это угроза для одной или нескольких целей заинтересованных сторон в проекте и обладает неопределенной вероятностью. 

Риски проекта, процесса и продукта 

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

Существует три типа рисков, связанных с программным обеспечением. 

Проектный риск: Эти риски относятся к проекту в его собственном контексте. Проекты обычно имеют внешние зависимости, такие как наличие навыков, зависимость от поставщиков, фиксированные сроки или ограничения, такие как контракт с фиксированной ценой. Внешние зависимости — это обязанности по управлению проектом. 

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

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

Далее мы сосредоточимся на рисках продукта. Мы будем использовать термин "риск продукта" следующим образом: 

Риск продукта — это вид или закономерность отказа системы неприемлемый на продакшене.  

Манифест тестирования, основанного на рисках 

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

Это задача руководства – выполнять и/или контролировать следующие задачи тестирования, основанные на оценке рисков: 

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

Вероятность, последствия и подверженность 

Чтобы оценить риск продукта, нам нужно понять, каковы последствия такого рода сбоя. Если происходит сбой, мы говорим, что риск материализовался. Затем мы спрашиваем: “Насколько серьезен риск?”, далее будем называть эту степень подверженностью. 

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

• Вероятность (или правдоподобие) материализации риска. Это значение обычно выражается в процентах от нуля до 100 процентов (но не включая их). 

• Последствие (или воздействие, или потеря) материализации риска. Это потенциальная стоимость ущерба, если произойдет такой сбой. 

Подверженность риску – насколько он серьезен – рассчитывается как произведение вероятности и последствий: 

“Подверженность = Вероятность риска Х последствия риска”.   

Количественная или качественная оценка 

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

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

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

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

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

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

Мы более подробно обсудим определение скоупа, приоритетов и масштабирования в последующих статьях, так что будьте внимательны. 

Риски для продукта и тестирование 

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

Вы часто будете слышать, как люди говорят, что ‘тестирование снижает риск’. Это неправда — иногда тестирование может увеличить риск. Мантра "тестирование снижает риск" возникает из недостаточного понимания как рисков, так и тестирования. 

Допустим, мы выявили риск того, что какая-то фича может выйти из строя. Мы формулируем тест и запускаем его. Тест может пройти успешно, а может и не пройти. Как успешное прохождение теста или неудача повлияют на нашу оценку риска? 

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

Существует четыре релевантных результата теста, которые влияют на вероятность риска. Они обобщены в этой таблице: 

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

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

Теперь, когда вы понимаете потенциал тестирования для нашей оценки рисков, мы можем рассмотреть возможность определения тестов из описаний рисков. 

Планирование тестирования с учетом рисков 

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

• Получаем сбои, обнаруживаем ошибки и исправляем их (снижая риск такого рода сбоев) или 

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

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

Практические аспекты 

Теперь перейдем к некоторым практическим соображениям, связанным с тестированием, основанным на риске. 

Что, если заинтересованные стороны не заинтересованы в оказании помощи в оценке рисков? 

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

Что делать, если существует несколько вариантов тестирования риска продукта? 

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

Мы рассмотрим, как вы могли бы сделать выбор, в следующей статье "Сколько тестов достаточно?”. 

Что, если тестирование (для устранения риска) обходится слишком дорого? 

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

Если мы больше тестируем фичи с высоким риском, мы меньше тестируем другие фичи, не так ли? 

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

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

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

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

Что, если тестирование - неправильный ответ? 

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

• Покупайте ПО для тестирования у стороннего производителя, не создавайте инструменты сами и не рискуйте. 

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

• Перенесите обработку в батч систему на копии данных. 

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

• И так далее. 

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

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

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

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

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

Однако, если мы сосредоточимся на критических фичах и найдем в них неисправности, необнаруженные неисправности в этих критических фичах менее вероятны. Неисправности, оставшиеся в некритических элементах системы, имеют меньшие последствия. 

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

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

Вот и все, что касается нашего манифеста по тестированию на основе рисков. Концепция будет вновь появляться в серии "Лидерство в тестировании", так что следите за обновлениями, чтобы увидеть больше статей!