GUIDELINES FOR RISK ASSESSMENT

The type and severity of each risk associated with an item of work should be jointly agreed with the customer. This need not be a time consuming task as many risks are common to any size or type of software delivery. Joint agreement of risk may be obtained at the time of raising the DBS or WTI.

a. Time/deadlines:

  • Establish any ‘mission critical’ or ‘soft’ target dates, and incorporate these when assessing the resource requirements.

b. Size of job:

  • Is the client (or you) accurately assessing the impact of the change? Use the dataflow mapping to trace associated processing. User representatives (or the Business Consultant) should be able assess if any future policy events or product changes are affected.

c. Stability of environment:

  • Does the test environment sufficiently mirror the production environment? Has the code been substantially amended in the past? Does the environment contain only valid data or is the data old, corrupt, incomplete or inappropriate?

d. Manageable tests:

  • Not all risks can be eliminated by testing but they can be controlled. Do not test for testing’s sake. Tests should be run for minutes rather than hours.

e. Grade each risk:

  • If the risk is critical to the user, then tests against the risk should be more exacting.

f. Balanced risk model:

  • Review the initial risk model with the users and the analyst. Inevitably the testing required to cover all risks is substantial. Take a pragmatic approach to meet the time and resource constraints without significantly increasing the the risk. The solution must always be achievable and affordable.

g. The user knows best what is mission critical:

  • Although the assessment of risk is a joint process, if the customer identifies an event that they feel must be tested for then this must be included in the risk model.

h. Risks increase if the functionality is to be backdated:

  • Retrofitting code should be avoided if at all possible, as components require a baseline test (see Test Types) at the system date of implementation and re-testing at the current date.

> Top <