Risk based testing что это

Risk Based Testing: Approach, Matrix, Process & Examples

Updated October 8, 2021

Risk Based Testing (RBT) is a software testing type which is based on the probability of risk. It involves assessing the risk based on software complexity, criticality of business, frequency of use, possible areas with Defect etc. Risk based testing prioritizes testing of features and functions of the software application which are more impactful and likely to have defects.

Risk is the occurrence of an uncertain event with a positive or negative effect on the measurable success criteria of a project. It could be events that have occurred in the past or current events or something that could happen in the future. These uncertain events can have an impact on the cost, business, technical and quality targets of a project.

Risks can be positive or negative.

In this tutorial, you will learn-

When to implement Risk based Testing

Risk based testing can be implemented in

Risk Management Process

Let’s now understand the steps involved in Risk Management Process

Risk Identification

Risk identification can be done through risk workshops, checklists, brainstorming, interviewing, Delphi technique, cause and effect diagrams, lessons learnt from previous projects, root cause analysis, contacting domain experts and subject matter experts.

Risk Register is a spreadsheet which has a list of identified risks, potential responses, and root causes. It is used to monitor and track the risks (both threats and opportunities) throughout the life of the project. Risk response strategies can be used to manage positive and negative risks.

Risk breakdown structure plays an important role in risk planning. The Risk Breakdown structure would help in identifying the risk prone areas and helps in effective evaluation and risk monitoring over the course of the project. It helps in providing sufficient time and resources for risk management activities. It also helps in categorizing many sources from which the project risks may arise.

Risk Breakdown structure sample

Risk Analysis (Includes Quantitative and Qualitative Analysis)

Once the list of potential risks has been identified, the next step is to analyze them and to filter the risk based on the significance. One of the qualitative risk analysis technique is using Risk Matrix (covered in the next section). This technique is used to determine the probability and impact of the risk.

Risk Response planning

Based on the analysis, we can decide if the risks require a response. For example, some risks will require a response in the project plan while some require a response in the project monitoring, and some will not require any response at all.

The risk owner is responsible for identifying options to reduce the probability and impact of the assigned risks.

Risk mitigation is a risk response method used to lessen the adverse impacts of possible threats. This can be done by eliminating the risks or reducing them to an acceptable level.

Risk Contingency

Contingency can be described as a possibility of an uncertain event, but the impact is unknown or unpredictable. A contingency plan is also known as the action plan/back up plans for the worst case scenarios. In other words, it determines what steps could be taken when an unpredictable event materializes.

Risk Monitoring and Control

Risk control and monitor process are used to track the identified risks, monitor residual risks, identify new risks, update the risk register, analyze the reasons for the change, execute risk response plan and monitor risk triggers, etc. Evaluate their effectiveness in reducing risks.

This can be achieved by risk reassessments, risk audits, variance and trend analysis, technical performance measurement, status update meetings and retrospective meetings.

The table below gives information about the

We need to remember that risk increases with changes in technology, the size of the project, length of the project (Longer project timeframe), the number of sponsoring agencies, project estimates, efforts, and a shortage of appropriate skills.

Risk Based Testing Approach

high-risk areas should be most intensively covered.

Risk Based Testing Approach to the System Test

Diagram below gives a clear overview of the above-mentioned process

System Testing includes both Functional tests as well as Non-Functional tests.

Functional testing ensures that the product/application meets customer and business requirements. On the other hand, non-functional testing is done to verify if the product stands up to customer’s expectations in terms of quality, reliability usability, performance, compatibility, etc.

How to do Risk Based Testing: Complete Process

This section covers, Risk based Test Process

F1-Functional Requirement, R1-Risk Associated with F1

F2-Functional Requirement, R2-Risk Associated with F2

F3-Functional Requirement, R3-Risk Associated with F3

Specific Test objectives: The risks and test objectives listed are specific to the test types.

Procedure to design the risk based test process

Generic Test Objectives- These generic objectives are applicable to multiple projects and applications

Generic Test objectives can be defined for the different test stages

Let’s consider the system test stage

Prioritization and Risk Assessment Matrix

Risk assessment matrix is the probability impact matrix. It provides the project team with a quick view of the risks and the priority with which each of these risks needs to be addressed.

Probability is the measure of the chance for an uncertain event will occur. Exposure in terms of time, proximity and repetition. It is expressed in terms of percentage.

This can be classified as Frequent(A), Probable(B), Occasional(C), Remote(D), Improbable(E), Eliminated(F)

Severity is the degree of impact of damage or loss caused due to the uncertain event. Scored 1 to 4 and can be classified as Catastrophic=1, Critical=2, Marginal=3, Negligible=4

The priority is classified into four categories, which is mapped against the severity and probability of the risk as shown in below image.

Serious: The risks that fall in this category are marked in Amber color. The activity must be stopped, and immediate action must be taken to isolate the risk. Effective controls must be identified and implemented. Further, the activity must not proceed unless the risk is reduced to a low or medium level.

High: The risks that fall in this category are marked in Red color ate action or risk management strategies. Immediate action must be taken to isolate, eliminate, substitute the risk and to implement effective risk controls. If these issues cannot be resolved immediately, strict timelines must be defined to resolve these issues.

Medium: The risks that fall in this category are marked in Yellow color. Reasonable and practical steps must be taken to minimize the risks.

Low: The risks that fall in this category are marked in green color) marked can be ignored as they usually do not pose any significant problem. Periodical review is a must to ensure the controls remain effective

Generic Check list for Risk Based Testing

Comprehensive list of important points to be considered in Risk based testing

Risk Based Testing Results Reporting and Metrics

Reporting test status is about effectively communicating the test results to the project stakeholders. And to give a clear understanding and to show the comparison of test results with test objectives.

Test Summary Report, Test coverage report

Metrics is a combination of two or more measures used to compare software processes, projects, and products.

Inherent Risk vs. Residual Risk Assessment

Risk identification and analysis should also include inherent risks, residual risks, secondary risks and recurrent risk

Test result measurement based on risk helps the organization to know the residual level of quality risk during test execution, and to make smart release decisions.

Risk Profiling and Customer Feedback

Risk profiling is a process for finding the optimal level of investment risk for the client considering the risk required, risk capacity and risk tolerance.

Customer Feedback

Gather customer feedback and reviews to improve the business, product, service and experience.

Benefits of Risk Based Testing

The benefits of Risk Based Testing is given below

Summary:

In Software Engineering, Risk based testing is the most efficient way to guide the project based on risks.

The testing efforts are effectively organized, and level of priority of each risk item is rated. Each risk is then associated with the appropriate test activities, where a single test having more than one risk item, then the test is assigned as the highest risk.

Tests are executed according to the risk priority order. Risk monitoring process helps in keeping track of the identified risks, and reducing the impacts of residual risks.

Источник

Risk based testing что это

Что пишут в блогах

Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.

Где: Кострома / онлайн

2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.

Онлайн-тренинги

Что пишут в блогах (EN)

Blogposts:

Wednesday

Разделы портала

Про инструменты

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

Итак, во-первых: риски и проблемы зачастую сваливаются в одну кучу. Риск, по определению какой-то существующий или развивающийся фактор процесса, который обладает потенциально негативным воздействием на процесс и, как следствие, на его результат. Можно, конечно, дотянуть любую проблему до понятия риска, только зачем? В среднем, обычный тренинг по управлению рисками состоит всего на 20-25% из материалов про сам процесс управления рисками и описания типичных рисков, а в остальные 75% времени тренеры пытаются впихнуть под видом рисков описания процессных проблем под соусом «а ещё у вас может быть вот что…». Повторюсь — зачем?

Итак, разберёмся.

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

Проще говоря, чтобы чётко разграничить риск и проблему: риск это то, что может случиться и привести к негативным последствиям, а проблема, это то, что уже случилось и мешает работать. И риск и проблема мешают или могут мешать работать, но способы работы с рисками и проблемами несколько разные: первые надо пытаться понять, найти и по возможности минимизировать их последствия до того как они «выстрелят», а с проблемами надо работать по факту — чинить или «тушить». Если отделить риски и проблемы, область управления рисками становится намного проще и понятнее.

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

Как работать с рисками

Алгоритм работы с рисками можно неплохо представить в виде часто используемой в тренингах и литературе картинки:

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

Что, обычно, вызывает сложности на начальных этапах работы с рисками: собственно начать (внести эти активности в рабочие планы); понять, что работа с рисками не rocket science и что эти активности как и любые другие должны быть спланированы, обеспечены ресурсами (исполнителями), выполнены, а результаты должны быть проанализированы (что «выстрелило», что — нет, с чем мы справились успешно и т.д.).

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

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

Также не хотелось бы отвлекать внимание от основной темы этой статьи идеями про правильное целеполагание, но если в плане управления рисками будет написано «поговорить с шефом про ЗП ведущему тестеру» вместо «решить вопрос про повышение ЗП ведущему тестеру на 20%», то результатом выполнения такого таска в плане будет, скорее всего, не «повысили ЗП на 20%», а «поговорили с шефом про повышение…».

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

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

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

Неполная оценка трудозатрат по проекту
Фредерик Брукс, в своей известной книге «Мифический человеко-месяц» отмечал, что именно этот риск является зачастую основной причиной невыполненных вовремя или вовсе провальных проектов.

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

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

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

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

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

Как бороться: ревью и аудиты, формальные и «на бегу». В этом месте одна голова хорошо, а две — лучше.

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

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

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

Почему планы тестирования и разработки ещё должны быть связаны жестко на уровне единого плана проекта: в зону ответственности менеджера проекта, при фиксированной длительности итерации кроме всего прочего относится управление объёмом (scope) итерации, для чего ему необходимо видеть работы по тестированию. Грубо говоря, в ограниченной по времени итерации задача ПМ-а выбрать такой объём функционала, который команда успеет и сделать и протестировать.

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

Стратегия тестирования отсутствует или непринята группой разработки или заказчиком
Формально не риск, а проблема, которая порождает риск, что стратегия тестирования не будет выполнена в той части задач, где пересекается с задачами разработки или не будет обеспечена ресурсами (зачастую именно проектным временем) и как результат всё равно не выполнена.

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

Увольнение сотрудников
Риск увольнения ключевого или не очень ключевого сотрудника есть всегда.

Проблема не в том, что люди уходят, а в том, что уходят тогда, когда нужно им, а не проекту, а на ввод нового сотрудника, его обучение и вывод на «проектную мощность» требуется время — соотв. планы проседают, скорость падает, все нервничают.

Что делать. Держать «скамейку запасных» не всегда возможно по экономическим причинам. «Кормить лучше» помогает далеко не всегда, а иногда (в случае как раз с не ключевыми товарищами) это ещё и попросту невыгодно. Что тут можно сделать? Самое очевидное, что я вижу, это «договориться с соседями» — просто побеседовать с соседними отделами или проектами (у которых этот риск тоже есть) и договориться, что в случае такого события, они смогут хоть как-то (если это позволит специфика продукта и текущая загруженность) помочь вам людьми. Аналогично, будьте готовы помочь сами. Да-да, спасение утопающих — дело рук самих утопающих.

Остальные проблемы
Изменение даже зафиксированных требований или их приоритетов, зачастую относят к рискам, как к фактору, который повлияет на объём итерации и соотв. приведёт к пересмотру планов и возможно срыву сроков поставки версии. Я бы не называл эту часть проектной работы риском — это реальность, с которой надо работать как с проектным ограничением и стараться не дотягивать даже до состояния проблемы. Действенным путём является как раз ограничение объёмов итерации по срокам, когда любое изменение в требованиях приводит к выталкиванию какого-то другого кусочка работ (и девелопмент и тестирование) в следующую итерацию. Принудительно или административно «заставить» требования не меняться ещё ни у кого не получалось – бизнес меняется, требования меняются и если Заказчик готов платить не только за естественные изменения в требованиях, но и за свои «фантазии» или «неорганизованность» — это надо принять и уметь с этим жить. Способы есть и они работают.

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

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

Риск игнорирования рисков
Один из рисков, который распространяется на все уровни управления рисками.
Нежелание принимать во внимание тот факт, что риски есть, что процесс (даже самый налаженный, выверенный, формализованный и контролируемый) может давать сбои, обычно приводит к чересчур оптимистичным планам, к конфликтам при их невыполнении, к необходимости перепланировать в «пожарном режиме» (что обычно приводит к просчётам и ещё больше нарушает нормальный ритм работ) и как результат к провалам.

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

Источник