Stages of Risk Management Encountered by the Software Testing Managers

Stages of Risk Management Encountered by the Software Testing Managers

Software testing managers� come across following four stages while managing risks associated with their projects & products:

1) Risk identification;
2) Risk analysis;
3) Risk mitigation; and
4) Risk monitoring.

Stage � 1: Risk Identification:
In risk identification the risks presented by the project & product are identified & documented for further analysis

It is the initial step of recognizing what risks are present (i.e. what unwanted events might occur). At this stage the main priority is to ensure that as many risks as possible are identified rather than analyzing any of them in any depth. The emphasis is on taking the broadest possible view and involving as many different stakeholders as possible to ensure that risk is considered from many viewpoints.

Techniques for identification are those that encourage an open mind and speculation; all ideas should be welcomed and captured. Later stages of the process will analyze and quantify the risks.

Following six identification techniques are most commonly used for risk identification.

a) Using Brainstorming Technique:
Brainstorming is an ideal technique for capturing ideas quickly. To be really effective a brainstorm session needs to be short and intense, while participants are in a creative mood. A conducive atmosphere is vital, and participants need to feel safe from criticism or ridicule. A facilitator should be appointed to control the activity and ensure that everyone is encouraged to contribute. During the risk brainstorm session everything suggested should be recorded (ideally on a flip chart or whiteboard, but a sheet of paper would do) without comment or analysis. The session should be kept going while ideas are flowing freely, but stopped as soon as there are gaps in the flow of ideas. Often a second session, after a little break and starting from the list generated by the first brainstorm session, can yield more ideas triggered by the initial list.

b) Organizing Risk Workshops:
A workshop is a more structured session than a brainstorm session. The aim is to have as many different stakeholder viewpoints represented as possible. However, the generally accepted view is that a workshop is more effective with 8�12 participants. As for the brainstorm session, a facilitator should be appointed to run the workshop.

c) Learning from the Past Lessons:
This technique capitalizes on knowledge gained from previous projects. Looking back over past projects to identify mistakes made and risks not well managed can be a powerful trigger for recognizing potential risks in a current project. In this case the technique depends on the existence of some records of past projects, in the form of post-project reviews or risk registers. If a risk analysis was done for past projects and records kept, these can be useful if there are people available who were involved or who can remember the projects. This can be a good way to at least recognize risks that were not handled effectively in the past. If there are no records this is not a suitable technique, but it might be a good idea to begin keeping enough records to allow it to be used for future projects.

d) Conducting Interviews:
Interviews are a way to ensure that all stakeholder viewpoints are considered. More structured than a brainstorm or a workshop, an interview can ensure that every viewpoint is considered and it can also ensure that every stakeholder’s input is based on a consistent set of questions. An interview is inevitably more formal than a brainstorm or a workshop, and this may become an inhibiting factor; interviewees are likely to be less spontaneous and creative than in a workshop situation. Interviews can be a very good way to follow up on brainstorms or workshops to ensure that those who made little contribution are at least heard and to follow up on any questions raised by the brainstorm or workshop. The idea of workshops or brainstorming followed by interviews suggests a fairly time-consuming and expensive approach, but it will ensure that all participants have had the opportunity to contribute.

e) Carrying out Independent Assessment:
Independent assessment by an expert can help to ensure that all important areas are covered, but independent experts are likely to be expensive, so this is not an approach that would normally be used except where the cost is justified, for example if an organization is entering a safety critical area of application for the first time. Of course an independent assessment does not necessarily require an expert and there may be specialists within the organization who are independent of the project that could carry out an effective risk assessment. This is still a relatively expensive approach, however.

f) Use of Checklists and Templates:
Checklists and templates are both ways to provide a starting point for the risk assessment. Checklists can be based on past experience, lessons learned or input from an expert, or they can just be copied from books or produced in a brainstorm or a workshop.

Templates, typically providing the main headings for a risk assessment document, are an alternative to checklists, or they may be used to ensure that the topics included in the checklist are included in the documentation. The main thing is that everything the organisation considers important in a risk assessment is incorporated into these guidance documents. No matter how shaky the initial checklists or templates, they will improve if they are continuously updated from real project experience.

Stage � 2: Risk Analysis

The risks are analyzed to find out for their probability of occurrence & the impact they would have if they would have materialized. The product of probability & impact is the overall level of risk. This allows the risks to be ranked in order of the level of the risks.

Risk analysis is about getting more information about the risks, especially the relative risk levels of the risks identified. Risk level is defined as the product of the probability of a risk occurring and the impact of the risk if it occurred. Thus if a risk had a probability of 1/100 of occurring and its impact would be a loss to the organization of $1,000, we would define the risk level as $10.

The aim of risk analysis is, as far as possible, to quantify the risks so that they can be ranked and prioritized. The simple example given is untypical because neither the probability of occurrence nor the impact would normally be quantifiable as precisely as in the example, if at all. Nevertheless, the definition of level of risk is still useful. If precise quantification is not possible then some more qualitative measure of probability and impact can be used. Gradings of both probability and impact could be as simple as Low, Medium or High. We can use a 7 x 7 Risk Analysis Matrix to record risks by level as described in the following figure.

If more is known, then finer grain estimates of probability and impact can be used. Instead of three levels for each there could be five, seven or even nine. The most important thing is that the matrix provides a basis for ranking risks and deciding on the priorities for risk mitigation.

Following figure provides an example of a matrix with seven levels and populates the matrix with some examples of the number of unwanted events identified in the various combinations of probability and impact. Based on a populated matrix such as this a risk mitigation strategy can be worked out.

In the above figure of example we see that the unwanted events associated with risks are spread around the matrix. A few are in the extreme corners of low impact and low probability, which can be ignored, or high impact and high probability, which demand attention. The more difficult judgements are around what to do about those that occur around the middle of the table, and here some closer examination may be necessary before a risk mitigation strategy is decided.

Stage � 3: Risk Mitigation

Here each risk is considered for mitigation & mitigation actions are decided based upon the nature & level of the risk.

Risk mitigation is the term used for the action we decide to take in tackling each risk. Mitigation actions can be anywhere on a spectrum from doing nothing at one end to doing as much as possible to eliminate the risk at the other end. In between there are many options, such as taking out insurance to cover any losses, spending extra money on specialist resources to tackle a high risk area more effectively than we could do for ourselves, or outsourcing a risky area to a third party who will take on the risk and compensate us if it materializes.

Testing is a key element of risk mitigation because it can provide evidence of the effective countering of a risk. For example, if there is a risk that a system will have inadequate performance there will need to be development action to ensure that adequate performance is achieved, and it will then be performance testing that identifies objectively whether the performance is adequate or not. For this reason the testing associated with the higher risks needs to be the priority. This is the main principle behind risk-based testing.

Stage � 4: Risk Monitoring

Risk mitigation actions & risk levels are continuously monitored throughout the project to ensure that the overall risk levels remain acceptable.

Full Study Material for ISTQB Advanced Test Manager Exam

Yogindernath Gupta

An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.