But Wilco, how can risk-based testing be more efficient when it requires an analysis of what areas of functionality could have high risk or high impact?
This is a very reasonable question.
Risk-based testing
Risk-based testing means you focus the testing effort where it's most likely to pay off, to identify issues we're going to care about most, since they're most likely to occur and most impactful when they do.
Is it really efficient?
Risk-based testing seems to imply a comprehensive upfront analysis of where issues are likely to occur and what impact they are likely to have when they do occur. Indeed it's not an uncommon approach and ends up with a satisfyingly thorough and structured overview which, however, undoes the efficiency the risk-based testing could have had.
Alternatives
It doesn't have to be that way. You could of course try and reduce the thoroughness of the risk assessment by - for example - identifying all scenarios you can think of ahead of time and get the person most intimately acquainted with the area of functionality to give a simple Low/Medium/High/Critical estimation of risk and the person most intimiately acquainted with the users to give their simple Low/Medium/High/Critical estimation of impact, but in the dynamic environments I like to work in it gives more return on investment to be less formal and use the strengths of experienced test specialists and collaborative teams:
- In conversation with the team (whether it be a mobbing/ensembling/teaming/pairing session or a Scrum ceremony or something else), ask questions like "what absolutely must not fail?" (impact) and "what do we feel least confident about?" (risk).
- Use your prior experiences and intuition as a test specialist to gain suspicions that you can then investigate.
- Use the increasing real information about the system under test while testing to refine your informal risk and impact assessment and guide your continued testing.