Positive risk in software testing

Positive risk refers to risk that we initiate ourselves because we see a potential opportunity along with a potential for failure (the negative risk associated with “loss” of the opportunity). There are several kinds of opportunities that can be leveraged in projects if responses to them are well-timed and prompt action is initiated.

Take the following cases of positive risk.

Case 1: It is estimated to take six months to complete a development project assuming the efficiency level of the developers are 60-70%,during the course of development you came to know that the developers efficiency is 80-90% and your are going to finish the development activity in lesser time. In this case there is no negative risk identified.

Case 2: in a software development project that is scheduled to take 90 days. The customer would prefer earlier delivery, and would get more value from an earlier delivery, but understands and concurs with the 90-day development period. Utilizing a new software-testing tool might allow delivery in 60 days. Here the negative risk also can occur, like this is the first time that your organization has used the tool (lack of expertise, learning curve required). If the tool doesn’t work out, delivery might take 110 days, rather than 90.

Case 3: It is estimated to take six months to complete a medium-sized software development project. You may be able to complete the project sooner using Extreme Programming techniques, delivering the first iteration in three months, then monthly updates after that. There is a risk, however, that new techniques will not work well, or that staff may resist the changes, causing a delay in the project.

Risk analysis in software testing
A risk is a potential for loss or damage to an Organization from materialized threats. Risk Analysis attempts to identify all the risks and then quantify the severity of the risks.A threat as we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.

Risk Identification:

1. Software Risks: Knowledge of the most common risks associated with Software development, and the platform you are working on.

2. Business Risks: Most common risks associated with the business using the Software

3. Testing Risks: Knowledge of the most common risks associated with Software Testing for the platform you are working on, tools being used, and test methods being applied.

4. Premature Release Risk: Ability to determine the risk associated with releasing unsatisfactory or untested Software Prodicts.

5. Risk Methods: Strategies and approaches for identifying risks or problems associated with implementing and operating information technology, products and process; assessing their likelihood, and initiating strategies to test those risks.


Traceability means that you would like to be able to trace back and forth how and where any work product fulfills the directions of the preceding (source-) product. The matrix deals with the where, while the how you have to do yourself, once you know the where.

Take e.g. the Requirement of User Friendliness (UF). Since UF is a complex concept, it is not solved by just one design-solution and it is not solved by one line of code. Many partial design-solutions may contribute to this Requirement and many groups of lines of code may contribute to it.

A Requirements-Design Traceability Matrix puts on one side (e.g. left) the sub-requirements that together are supposed to solve the UF requirement, along with other (sub-)requirements. On the other side (e.g. top) you specify all design solutions. Now you can connect on the crosspoints of the matrix, which design solutions solve (more, or less) any requirement. If a design solution does not solve any requirement, it should be deleted, as it is of no value.

Having this matrix, you can check whether any requirement has at least one design solution and by checking the solution(s) you may see whether the requirement is sufficiently solved by this (or the set of) connected design(s).

If you have to change any requirement, you can see which designs are affected. And if you change any design, you can check which requirements may be affected and see what the impact is.

In a Design-Code Traceability Matrix you can do the same to keep trace of how and which code solves a particular design and how changes in design or code affect each other.

Demonstrates that the implemented system meets the user requirements.

Serves as a single source for tracking purposes.

Identifies gaps in the design and testing.

Prevents delays in the project timeline, which can be brought about by having to backtrack to fill the gaps.

Risk analysis is appropriate to most software development projects.

Use risk analysis to determine where testing should be focused:

1. Which functionality is most important to project

2. Which functionality is most visible to user

3. Which functionality has largest impact on users.

4. Which aspects of the application is most important to the customer

5. Which aspects of the application is tested early in the development cycle.

These are some of the risk analysis factors to test an application.

The two most important characteristics of Risks are
a. Its Adverse effect to the success of the project
b. Its uncertainty.

Typical parameters used in analysis of risks are
1. Probability of occurrence
2. Impact of the risk - this is sometimes a product of Severity of the impact and period in which the risk might occur.

The product of the above two parameters will give you Risk Exposure factor based on which the priority of the risks to be mitigated or acted upon could be decide.

Risks are always as against the business requirements for which the software has been created. So, it is always very important to understand the risks that can affect the client's business and its impact. Testers need inputs from client as well as developers with regard to this understanding. What you may consider as risk from testing point of view may not be as seen by the client. So, it is necessary to associate risk level with each requirement and also the priority. This will be very beneficial while suggesting go/no go for production.