[ISTQB] 5.5 Risk and Testing (K2)

• A risk is a factor that could result in future negative consequences; usually expressed as impact and likelihood.
• A product risk is a risk directly related to the test object.
• A project risk is related to the management and control of the test project :lack of staffing, strict deadlines, changing requirements...

LO-5.5.1 Describe a risk as a possible problem that would threaten the achievement of one or more stakeholders' project objectives (K2)

A project risk can threaten the completion of the project on time, on budget and to achieve objectives. 

Several factors like suppliers issues, personal or organisational issues, technical issues can introduce project risks. For example: a third party don't deliver the product on time, there is an ambiguity in the contract, not enough staff or skilled staff is in place, team conflicts, there are problems in requirements definition, test environments are not ready on time, late planning...

All stakeholders have to be aware of project and product risks, the risk assessment and mitigation have to be shared and agreed for making decisions. 

LO-5.5.2 Remember that the level of risk is determined by likelihood (of happening) and impact (harm resulting if it does happen) (K1)

Assessing the severity of a risk implies determining the combination of:
- its likelihood to occur.
- its impact. 

A risk analysis must therefore be used to decide:
- what we should start testing.
- where should we test more. 

The higher the risk is, the higher the need of testing should follow for ensuring acceptable project/product quality and fit for purpose. 

LO-5.5.3 Distinguish between the project and product risks (K2)

• Product risks involve a potential failure in the system/software, they threat the quality of the product. They are identified during the initial stages of the project and are taken in account during test planning and control, specification, preparation and test execution
• Project risks as introduced in previous K2. They are related to the project management and threat its completion.

LO-5.5.4 Recognize typical product and project risks (K1)

• Product risks: arise from poor software characteristics, poor data integrity and quality, software that not performed its intended function. Testing confirms that the risk is present, fixing defects reduces the likelihood of failure and redesigning reduce the impact of failure. 

LO-5.5.5 Describe, using examples, how risk analysis and risk management may be used for test planning (K2)

Risk management is part of planning process and includes risk identification (risk recorded), risk assessment (severity, risk acceptability), risk mitigation (contingency plan). 
IEEE 829 outlines that test plans require to define risks and related contingencies. 

Risks are therefore reviewed in a regular basis and reassessed so new mitigation actions could be vetted: avoid, share, reduce, test.

Risk-based approach determines the test techniques to use (static, dynamic..), the extent of testing and influence test schedule execution.