Software company should always have a risk management done so that there will be smooth release of the product. Risk management is divided into 3 main parts.
1. Risk Identification
2. Risk Impact Analysis
3. Risk Mitigation
Risk Identification
Risk identification will be the first step of risk management where the QA manager or the QA lead would identify all the risk which could be involved in the project which would impact the project plan
Examples of Risk Identification
- Non availability of test environment or logistics
- Critical defects found during the release state
- Non availability of testing resources
- Requirement or design changes
- Natural calamity
- Understand of technologies
Risk Impact Analysis
QA manager has to prioritize the risk based on the probability of occurrence and impact due to the risk. Taking the same example of risk identification we can prioritize the impact as shown below
- Non availability of test environment or logistics - Probability Low, Impact High
- Critical defects found during the release state - Probability Medium, Impact High
- Non availability of testing resources - Probability Low, Impact Medium
- Requirement or design changes - Probability Low, Impact High
- Natural calamity - Probability Low, Impact Medium
- Understand of technology - Probability Medium, Impact High
Risk Impact can be shown in percentages or scale from 1-10
Risk Mitigation
QA manager should be having solutions to every risk that may occur. Solution needs to be practical and should be always be in a state of executing the solutions in a way it is mentioned i,e, Risk mitigation should not give false promises
- Non availability of test environment or logistics - Have a quick meeting with the customer and get him/her to provide a list of devices and test environment which would be their highest priority for the release
- Critical defects found during the release state - If a critical defect is found during the release state then have an experienced working developer and a Qa to just work on the defect and have it regressed quickly as possible
- Non availability of testing resources - If a Qa gets sick or if he leaves the company then have a back up Qa from start of the project where he will be briefed with the project requirements and his involvement will be less than 10%
- Requirement or design changes - Customer has to be formally informed that no changes will be entertained without pushing the release dates and if there is any changes then it would be taken as a Change Request with efforts breakdown
- Natural calamity - A backup resource would be provided in another location and will be assigned with the task if any Natural calamity occurs.
- Understand of technology - Training will be provide and a team which has already released a similar project will help before the project reaches the first alpha.