Error Danger: Communicating Risk

Communication as a tester is a difficult balance. Bringing an awareness of risk is one of the reasons that we are a valuable part of our teams, but no one wants to hear why their creation doesn’t fully deliver what the customer needs. As a result, we are treated sometimes as the bearers of nothing but bad news. We try to focus our team's awareness on what might happen if something is changed with every component created. We have no way to measure the number of times that awareness has prevented an unfortunate outcome: a computation that could actually be useful for the future.

The risk of something going wrong needs to be balanced with constructive progress, neither of them overlooked nor focused on too tightly. Being aware of situations we don’t think will happen in the real world (but often do!), and making sure that we learn from these experiences is simply a good practice. There is no perfect software, so we must accept that anything we release will have bugs. But the teams work together, making our products closer to that error-free goal daily. That collaboration needs different communication methods that stay updated, so all levels of decision-making people can use them.

Naming your risks

Risk can be a difficult thing to define. The variables that make something a large risk in one product make it smaller in another. A few things are always a high priority - such as ensuring that the product will function - but who your customers are, and how and where they will use the product, has an effect on what level of risk needs to be assigned to each feature. Ideally, this is first done when imagining the product, and looked at repeatedly as it moves closer to release.

Naming these risks is a habit that should have input from many levels: those that own or commission the product, and are most involved in an overall vision; those that have the skills to produce the code and are aware of the limitations of both tools and time; and those that are users or their proxies who will be the ones that determine the level of use and success. All of these inputs can be combined into a risk assessment, and used going forward in the project. And there are tools that can make this easier for everyone to remain aware of them.

Working within risks

Risk needs to be looked at as the teams grow and change, along with the product and the company. A simple typed wiki with a few photographs may serve well for a while, but later it may need a workflow board with visual or spoken items to accommodate the changes, or it may change focus to the product's users. Having someone do an internal talk or demonstration about the product - and archiving them to refer to later - keeps the information relevant and accessible. Updating your risk assessments this way keeps all involved aware of what can be done to further reduce risk - and what the trade off might be.

It is important to focus on balancing the risk with the ability to use the product for someone totally unfamiliar with it. Along with legal and security requirements, a product may need to balance what it is able to offer (such as historical data or audit logging) and the risk to both the company and the individual user if that information is available too readily. The user needs to be at the center of these balances - they anticipate a certain level of both privacy and ease. Being able to offer both may not be easy; however, communication and awareness of these challenges may help both sides reach a compromise that works.

Effects and communication

All of the product changes - code, features, ideas, and experiments - should be available, and in a format that is able to be accessed by anyone working on the product. Knowing when a change was made, and seeing the effects (code changes, user responses and test results, and discussions around the change) will be a history lesson, and may prevent errors in the future. Having updated ideas and experiments planned to make changes, combined with the security of both testing and cultural willingness to let an experiment fail, will give a firm basis for moving forward in a particular direction.

Making use of the tools that we have - familiar ones that everyone accepts as valid - is important to ensuring the best potential communication at all levels of business. We can leverage these tools to share information, and make sure that future issues can be addressed in the same fashion, so we don't have repeats of mistakes. The use of these aids has to be a cultural priority: teams can encourage, support, and maintain these documents, plans, and other artifacts to build the best product as it grows and changes. And having the high-level view, where you can see how this affects people on a daily basis, keeps the excitement and innovation for useful changes in the forefront of development.