News from RBCS

If you've read my books or articles, you probably know that I'm a big fan of risk-based testing. In this short article, let's consider the role of the user in risk-based testing.

Remember that risk-based testing is about tailoring your testing to allocate effort and sequence tests for potential problems based on considerations of impact and likelihood. Risk analysis and assessment helps you identify these potential problem areas and assess their levels of risk. However, the analysis and assessment is only as good as the people involved.

When identifying quality risks, we need to consider what quality means. Who knows this better than the user? When assessing the level of risk associated with a particular potential problem, we need to consider not just the technical aspects (which influence the likelihood of a bug), but also the business and operational aspects (which influence the impact of a bug should it exist). Who knows the business and operational aspects of a system better than those who will use it?

Unfortunately, project teams who employ risk-based testing do not always involve users, which leads to untested risk areas, over-testing some areas and under-testing of others, and improper sequencing of tests. Why don't project teams always involve users in risk analysis and assessment? I have seen three main reasons.

First, some project teams don't approach risk-based testing properly. They see risk-based testing solely through the lens of technical considerations. When testing is seen as mostly concerned with finding as many bugs as possible, without considering the confidence building and risk-mitigation roles of testing, then risk-based testing becomes monomaniacal.

This problem is easy to fix: Change the project team's approach to risk-based testing to consider both likelihood and impact. Training can help with this, as can reading a book like my own Managing the Testing Process or Rick Craig's Systematic Software Testing.

Second, some project teams have limited access to users. This happens when building software for mass-market sale. It also happens when users are geographically separated from the project team.

This problem is somewhat harder to fix: The project team must identify user surrogates like business analysts, sales, and marketing teams. These people must act on the user's behalf in risk analysis, and must remember to validate their assumptions with real users as often as possible.

Third, some project teams have organizational challenges to involving users in risk identification and analysis. IT stakeholders sometimes worry that user community will be alarmed by a frank discussion of risks, leading to loss of support for the project or re-opening of debates about the project's viability.

This problem is harder to fix: The users who will participate in the risk analysis must be helped to understand that the very act of analyzing and assessing risks will allow for the mitigation and management of those risks. Risk-based testing makes projects less risky, not more. Convincing and educating users requires a strong champion for risk-based testing, who can be a technical or managerial leader in the organization or an outside consultant.

The role of the user in risk-based testing is at once essential and challenging. Don't let the challenges frustrate you, though. The challenges can be overcome, and must be overcome, to achieve success in risk-based testing. The alternative is an approach too risky to consider!

To see more articles by RBCS President, Rex Black, visit the library at www.rbcs-us.com.