Risk Analysis in Software testing

Risk management is tricky because the process involves subjective thinking on the part of individuals in the organization. Identification of risks is generally based on an individual's experience and knowledge of the system. Since experience and knowledge are unique to each individual, it is important to employ a wide range of individuals on the risk management team.

Risk management also involves an assessment of the risk tolerance level in the organization. Companies that are more tolerant of risk will be less likely to develop a risk management approach. However, in some industries like the medical industry, there is little tolerance for risk.

While risk management can be applied to any type of industry, Yamini discusses a software risk management technique: risk analysis.

What is Risk Analysis?

Risk analysis is part of an organization's overall risk management strategy. One definition of risk analysis is the "process of exploring risks on the list, determining, and documenting their relative importance." It is a method used to assess the probability of a bad event; and it can be done by businesses as part of disaster recovery planning as well as part of the software development lifecycle.

The analysis usually involves assessing the expected impact of a bad event such as a hurricane or tornado. Furthermore, an assessment of the likelihood of that bad event's occurrence is also taken.

Proposed methods of risk analysis include different indicators. Since one method might not fit perfectly for your project, I suggest pooling together a multitude of expert insight to see if one, or a combination of many methods, works well for you.


The method adopted here modifies Rick Craig and Stefan Jaskiel's work in Systematic Software Testing, presenting a method to complete software risk analysis using other indicators than "expected impact" and "likelihood of failure." Before we do a risk analysis, however, we must understand what is meant by the term "risk."

Definitions of Risk

Risk is the probability that a loss will occur, "a weighted pattern of possible outcomes and their associated consequences." It indicates "the probability that a software project will experience undesirable events, such as schedule delays, cost overruns, or outright cancellation. Risk is proportional to size and inversely proportional to skill and technology levels." Thus, the larger the project the greater the risk.

These definitions indicate that risk involves possible outcomes and consequences of those outcomes. Potential outcomes include both negative and positive outcomes. Negative outcomes such as undesirable events can occur, and when they occur, there will be a loss to someone. The loss can occur in terms of money, lives, or damage to property.

Risk reduction strategies differ based on the level of maturity of the organization. The more mature the organization, the less likely it will be to take risks. Thus, the more mature the organization, the more likely it is for a software team in that organization to do risk analysis of software. This leads us to the justification for doing a risk analysis.

Why Perform a Risk Analysis?

In the medical industry, risk analysis is done for the following reasons:

1. Risk analysis is required by law.
2. 
   
3. Identification of device design problems prior to distribution eliminates costs associated with recalls.
   
4. Risk analysis offers a measure of protection from product liability damage awards.
5. Regulatory submissions checklists (PMA and 510k) used by the FDA now call for inclusion of risk analysis.
6. It is the right thing to do.

Some of these reasons could also apply to software risk analysis and disaster recovery planning in that risk analysis offers protection from product liability damages. Also, it is cheaper to fix a software defect if found in the development stage rather than if a customer finds the defect.

The risk analysis process "provides the foundation for the entire recovery planning effort." Similarly, in software development, risk analysis provides the foundation for the entire test planning effort. It should be included as an integral part of the test plan as a method to guide the test team in determining the order of testing.

The argument here is that testing reduces risks associated with software development and the software risk analysis allows us to prioritize those features and requirements with the highest risk. Testing high-risk items first reduces the overall risk of the software release significantly. Risk analysis also allows the test team to set expectations about what can be tested in the given amount of time.

RELATED POST

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique
Here i am adding the further topics list on software testing subject and the topics may be scattered and you can find under different groups.

MAJOR SYSTEM FAILURES IN THE HISTORY

WHAT IS A SOFTWARE BUG ?

ROLE OF A TESTER

SOFTWARE TESTING INTRODUCTION PART ONE

TESTING INTRODUCTION PART TWO

TESTING INTRODUCTION PART THREE

TESTING INTRODUCTIONS PART FOUR

SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE