How to come up with risks for the Risk Register

Question

The IEEE standard 29119-3 defines the content one should include in a test plan. One such part of that content is the Risk Register. This standard specifically states of this register:

Identifies the risks considered by the testing covered by this plan. This should include any relevant risks that may be specified in the Organizational Test Strategy. Provides an exposure level for each risk based on its impact and probability. Provides recommendations to treat the risks.

They specifically recommend that this register be broken into a product risk register and a project risk register.

My struggle here is in figuring out how to define a proper set of risks. I have a product which must meet a certain set of requirements so in my mind, the risk is that we won't meet these requirements. But it seems unhelpful that my risk register should list the risks as:

1) We don't meet requirement 1
2) We don't meet requirement 2
...

with the accompanying mitigations being

1) Test to make sure we meet requirement 1
2) Test to make sure we meet requirement 2
...

How can I define proper risks and accompanying mitigations which are meaningful? What should I consider in defining a product/project risk?

Answer 1

I'd look more at things from a quality assurance point of view, not a quality control point of view. For example, how sure are you that the requirements you've been given are the right requirements? How sure are you that there aren't requirements that are missing?

Then, for the requirements, I'd focus more on things you can't/won't test. For example, let's say your program has switches/settings of some sort. Chances are very good that you can't exhaustively test all combinations of settings. How will you choose which ones that you will test?

If you're building something that's performance sensitive, or may have load/concurrent user issues, how will you decide what the right level of stress is to test with?

Will you assume that the surrounding programs (operating system, databases, etc) are working properly, or will you do some sort of integration testing?

Answer 2

The first step would be to find out what kind of risks are product and what - project. When you know that then you will realise that as a tester you cannot influence (reduce) project risks. Risks, which you can lower with software testing, are product risks.

Second - never ever do it alone. In many cases, testers do not have the big picture about risks or wrong assumptions what kind of problems particular software has to solve. If you still have to create risk register, nobody else did it before you and you do not have access to the customer, then at least cooperate with a project manager (risks are his/her job anyway).