Just musing about a discussion I had with a group of testers earlier about risk-based testing and the challenge of identifying product risks. There are various approaches that could be employed to help identify risks, but most Scrum teams already consider risk on a regular basis in their backlog refinement sessions (or at least they should), so this would seem the ideal occasion to thrash our risk-based tests too.
A common approach to risk-based testing is for a designated tester to independently identify risks, analyse them and create appropriate mitigation strategies. However, there are obvious drawbacks to this. Most importantly, the tester doesn’t get the benefit of the knowledge and experience of the rest of the team/stakeholders, who have a different perspective on the risks involved. A preferred approach is the ‘risk workshop’, where various team members/stakeholders get together to discuss risks. Getting a wide variety of interested parties together to brainstorm risks can be very beneficial, but (in my experience) these workshops are often difficult to arrange because of the constraints on people’s schedules. Fortunately, Scrum teams already engage in regular Backlog refinement activities, which should include risk identification and analysis. The Scrum Guide recommends up to 10% of a Team’s capacity per Sprint for refinement, i.e. roughly half a day per week. This is a generous amount of time to refine the Backlog rather than create separate meetings to discuss risk, these refinement events could be used to include a greater focus on risk.
Practically speaking, much of the risk identification is done while estimating the complexity of a particular Backlog item during refinement, albeit this is often implicit and not stated. An enhancement to the session, could be to explicitly record these risks as they are identified. There is a reciprocal benefit here. The estimation process highlights new risks, which then help improve the estimates. In this scenario, the experienced tester still has an important role to play, but rather than own the risk-based testing process (running the risk of misunderstanding and creating a ‘test’ functional silo), the tester uses their experience to facilitate a more collaborative approach to risk-based testing. The outcome being a broader identification and analysis of product risks, and mitigation strategies (often in the form of tests) that are understood and implementable by the whole team.