The risk ???
it doesn??™t work???
can for example be broken down into a series of other risks:
??? The old features fail.
??? The new features fail.
Each of these can then be decomposed into a list of features and tested for. Some of these features
represent greater risks than others. Thus you can:
??? Identify an hierarchy of risks and thus test objectives.
??? Monitor the degree of the risk, with reference to the bugs found and the amount of coverage
obtained so far such that you can determine the amount of risk involved in releasing at any point.
If you then relate the features by criticality, you can order your tests and testing such that the
biggest risks are prioritized and monitored.
4.
What are the solutions?
Table 3.4 shows that the cost of reducing the risks are lower than the total
risks. No estimate is given for the cost to later releases of having kludgy, unmaintainable code in
the system. This is left as an exercise. From this table it is a simple matter to calculate the total
risk the project faces (probability
*
cost). Note that exposure in this case is considered to be 100%.
Conclusion.
This is a very primitive and partial attempt at demonstrating how to think about
and estimate project risk. It??™s something a project manager should do. It??™s something test managers
often end up having to do in order to fight their corner, and ensure they have the company focusing
realistically on the state of the project and what needs to be done to preserve its quality.
Pages:
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150