Risk in software testing

In software testing Risksare the possible problems that might endanger the objectives of the project stakeholders. It is the possibility of a negative or undesirable outcome. A risk is something that has not happened yet and it may never happen; it is a potential problem.

In the future, a risk has some probability between 0% and 100%; it is a possibility, not a certainty.

The chance of a risk becoming an outcome is dependent on the level of risk associated with its possible negative consequences.

For example, most people are expected to catch a cold in the course of their lives, usually more than once. But the healthy individual suffers no serious consequences. Therefore, the overall level of risk associated with colds is low for this person. In other hand the risk of a cold for an elderly person with breathing difficulties would be high. So, in his case the overall level of risk associated with cold is high.

We can classify risks into following categories:

1.     Product risk (factors relating to what is produced by the work, i.e. the thing we are testing).

2.     Project risk (factors relating to the way the work is carried out, i.e. the test project)

Product risk in software testing

Product risk is the possibility that the system or software might fail to satisfy or fulfill some reasonable expectation of the customer, user, or stakeholder. (Some authors also called the ‘Product risks’ as ‘Quality risks’ as they are risks to the quality of the product.)

The product risks that can put the product or software in danger are:

§  If the software skips some key function that the customers specified, the users required or the stakeholders were promised.

§  If the software is unreliable and frequently fails to work.

§  If software fail in ways that cause financial or other damage to a user or the company that user works for.

§  If the software has problems related to a particular quality characteristic, which might not be functionality, but rather security, reliability, usability, maintainability or performance.

Two quick tips about product risk analysis:
First, remember to consider both likelihood of occurrence of the risk and the impact of the risk. While you may feel proud by finding lots of defects but testing is also about building confidence in key functions. We need to test the things that probably won’t break but would be very bad if they did.

Second, early risk analysis, are often educated guesses. At key project milestones it’s important to ensure that you revisit and follow up on the risk analysis.

 Project risk in software testing

Testing is an activity like the rest of the project and thus it is subject to risks that cause danger to the project.

The project risk that can endanger the project are:

§  Risk such as the late delivery of the test items to the test team or availability issues with the test environment.

§  There are also indirect risks such as excessive delays in repairing defects found in testing or problems with getting professional system administration support for the test environment.

 For any risk, project risk or product risk we have four typical actions that we can take:

§  Mitigate: Take steps in advance to reduce the possibility and impact of the risk.

§  Contingency: Have a plan in place to reduce the possibility of the risk to become an outcome.

§  Transfer: Convince some other member of the team or project stakeholder to reduce the probability or accept the impact of the risk.

§  Ignore: Ignore the risk, which is usually a good option only when there is little that can be done or when the possibility and impact of that risk are low in the project.