11.2 Identify Risks

11.2 Identify Risks itto

 

 

Risks will exist all over your test project, and being able to identify and document risks from your strategy and plan is a key activity in being able to anticipate and mitigate those challenges.

Throughout the formation of your test strategy, a number of Risks, Assumptions, Issues, and Dependencies will be uncovered. Because risks change over time, new risks are determined as the project progresses, some risks are mitigated and closed, some risks become issues, and so on, identifying risks is an iterative process that continues throughout the life cycle of the test project.

Throughout the development of your test strategy you will have a number of approaches to various deliverables; each of these will contain assumptions and risks. Common risks in SAP test projects include:

  • test environment setup (Basis/Netweaver creation of test clients)
  • data availability for test cycles
  • testers identified and onboarded for test activities
  • support availability and/or training for testers during test cycles
  • delays in delivery of configuration, developments, security roles/profiles, etc
  • quality of testing in unit, integration, and user acceptance test cycles
  • delays in hardware and software procurement
  • scope creep and loose change control procedures impacting test preparation
  • lack of visibility of other in-flight projects or third party developments that impact the implementation

Although the initial identification of risks can come from the test manager and the test team, participation in assessing and analysing those risks usually covers more than one team, and follows a process (loose or formalised) of enquiry and investigation. For example, given our requirement that we need a test environment set up by a particular date to meet our entry criteria for integration testing, then:

  • We can check against the overarching project plan and with the Netweaver team to confirm the planned date of delivery of the test client. If the delivery date is well in advance of the planned start date for testing then we may choose not to enter a formal risk but rather to add a review date into our test project plan to check that the client has been delivered. If the planned delivery date is the week before integration testing starts though then any delay has more of an impact so we may formalise that risk in the risk register.
  • When the risk is formalised we can work with the Project Manager to assess the impact and potential cost of the risk if it turns into an issue, and with the PM and Netweaver team to assess the likelihood of the risk transpiring.
  • As part of the risk management plan the risk is reviewed regularly to reassess the likelihood and to prepare mitigations and contingency plans. Given that the actual delivery of the test client is largely out of our personal control, we can work with the other project teams and the Project Manager to determine the possibility of using any existing clients, the work required to get them ready as a back-up, the possibility and cost of delaying entry into the integration test phase, and the possibility of delaying other activities in the Netweaver plan to enable the test client to be delivered on time.