Type of Risks: Risks that affect different places are:
1) Business risks
2) Process risks
3) Project risks
this article, the fourth type of risk i.e. the product risk is described in
1) Business risks: These risks are threatening the entire organization from the
business point of view
2) Process risks: These risks are related to the processes or the way work is
3) Project risks: These risks are related to the project and the successful
completion of the project. In the situation it may be late with the developers
incurring some penalty clause, or reduced probability of gaining some later
4) Product risks: Project risks and product risks can influence and be the
cause of each other. A project risk may cause a product risk, and a product risk
may cause a project risk. Out of different risks that the project may present,
the risks related to the final product need be analyzed since some features are
more risk bearing than others. In the situation the product may not work
properly with the result that some penal loss may be imposed on the developers.
It could be that the users may use the product "incorrectly," in a way that was
not allowed for and which, while no blame is associated with the developers,
might prejudice the probability of the developers getting similar contracts in
The risks threatening the product are the software testing engineer's main
point of concern. They are the risks of defects remaining in the product when it
is delivered. We want to deliver the required quality and reliability. This
cannot be tested into the product at the end of the development, but must be
worked into the product through the work products produced during development
and in the implementation of the components.
Best way is to recognize & track the product related risks from the
moment requirements are written. While it may not be possible to assign a cost
to the risk from the beginning, it should be possible to assign a hazard
potential (High, Medium, or Low) to each requirement such that it can be
eventually transformed into a risk.
In this way we can possibly do the following:
1) Identify the features most in need of early prototyping, or formal
2) Determine the level and rigor of tests needing to be written.
3) Assign the bug fixing priorities.
4) Assign effort.
5) Monitor the feature status.
6) Identify when the features are likely to be used, from the operational
profile that will provide the risk exposure factor.
Source of the Product Risks: Product risks can be originated from the
following sources wherein requirements being the prime source.
1) Functional and nonfunctional requirement
2) Missing requirements
3) Ambiguous requirements
4) Misunderstood requirements
5) Requirements on which stakeholders do not agree
Product risks have adverse effect on the customer satisfaction. Product risks
may be related to different requirement types, such as functionality, safety,
and security and political and technical factors.
Few examples of product risks are:
1) A small, but important functionality has been overlooked in the
requirements and is therefore not implemented
2) A calculation of discounts is wrongly implemented, and the customer may
lose a lot of money
3) The instrument may reset to the default values if it is dropped on the
4) It is possible to print a report of confidential customer information
through a loophole in the reporting facility
5) An installation procedure is difficult to follow
These risks are the main concern of the testers, since testing may mitigate
the risks. The test strategy for a product should be based on the product risks
that have been identified and analyzed.
Relationship between Product Testing and Risk Management:
and management of risks are generally very tightly interwoven as they support
each other. Testing can be based on the results of risk analysis, and test
results can give valuable feedback to support continuous risk analysis.
The result of a product risk analysis can be used in test planning to make
the test as effective as possible. It can be used to target the testing effort,
since different types of testing are most effective for different risks.
The risk analysis results can also be used to prioritize and distribute the
test effort. The areas with risk exposure are generally planned for testing
first and given the most time and other resources.
Finally the product risk analysis can be used to qualify the testing already
done. If test effort is related to risks it is possible to report on dissolved
and remaining risks at any time.
Testing can dissolve or mitigate the product risks. The testing reduces the
probability of sending a product with defects out to the customers, as testing
locates failures and the subsequent correction of the
Who are involved in Software Risk Analysis?Going by the best practice suggested by the experts, risk
analysis activity is entrusted to different group of experts forming a unified
team. The participants can include users, customers, testers, developers as well
as other capable persons who can contribute well.
Risk Perception of different people: People in different professions can have
different perceptions on risks.
1) Project Managers: Project managers are generally under the time pressure due to
which they are used to compromises. They very well know that even though things
may look dark, the heaven is not going to fall.
2) Developers: Developers that is programmers, designers and analysts always feel
proud of their work, and they know how it was done. They have really done their
best, and they are usually reluctant to accept that there may still be defects
left in their piece of work.
3) Testers: Testers usually have a pessimistic view on products. Experienced
testers remember their previous experiences where they received objects for
testing and got far more failures than they expected.
4) End users: The end users are usually highly failure-tolerant. They tend to
remember previous experiences, but what they remember is that even though the
system failed, they found a way around it or another way of doing their
Scales for Risk Analysis: The analysis of risks uses metrics for
probability and effect. When we work with metrics it is mandatory to use agreed
and understood scales. This is true in case of risk analysis as well.
We can work with two different kinds of scale, that is:
1) Qualitative scale
2) Quantitative scale
1) Qualitative scale: In this we work with feelings or assessments.
"Effect" can be expressed as "Bad" > "Worse" > "Worst"
"Probability" can be expressed as "Not likely" > "Likely" > "Very
2) Quantitative scale: In this we work with exact measures or numbers.
"Effect" can be expressed as actual cost in $ or Rs. or €.
"Probability" can be expressed as <= 10%, >10% & <= 50%, >50%
& <=80%, > 80%
Whichever way to do it, project managers define and agree on scales for both
probability and effect before the start of risk
Estimation of Risk Level:
The risk level is calculated for each of the identified risks & expressed
in the form of following equation
Risk Level = Final Effect x Final
The distribution of the final risk level over individual risks is used to
plan the test activities. It can be used to prioritize the test activities and
to distribute the available time and other resources according to the relative
risk level. A test plan based on a risk analysis is more trusted than a plan
based on "Gut Feeling."
The testing results can be used as input to the continuous risk analysis. If
we get more defects than expected in a particular area it means that the
probability is higher than we expected, and the area hence has a higher risk
level. On the other hand if we get small number of defects than expected the
risk level is lower.
Many More Articles on Risk Analysis
& Security Testing