The risk of not communicating
Risk is something that we face in every moment of our waking lives. From simple acts such as walking down the street, turning on the TV, or driving in our cars. The risks that we face are endless and require constant assessment for us to mitigate successfully.
To assess risk and decide upon the appropriate action to avoid negative consequences. We rely on several factors such as whether something has occurred previously. The likelihood of something occurring in the future. Or outside variables that could increase potential circumstances taking place.
For example, we can avoid the risk of potentially contracting certain types of diseases by washing our hands and practising good hygiene.
Of course, any risk mitigation is not perfect. In the above example, if the handwashing technique is flawed. Then our risk aversion strategy would need reviewing.
When planning your software testing strategy, I always advise using risk as the framework to design your tests around. This ensures that not only are the critical parts of your software targetted. But it also gives you the unique perspective of your end-users. Which allows for unique insights, perspectives and experiences.
But first of all. Let’s take a look at what risk is.
How do we define risk?
Simply put. A risk is the possibility of an outcome that is negative, undesirable and is never certain to occur.
For example, if I crossed a busy road without looking. A risk would be that I am struck by a car, bicycle, or some other hazard. I may not be hit by anything, but the risk is still there.
The key to identifying risk is asking yourself if something is truly possible, the likelihood of it occurring and the negative consequences of it happening. Risk is never certain because it would instead be labelled as a constraint and fall outside the boundaries of the definition.
On the flip side of the word possible is impossible. And anything impossible should receive a low probability score. Because the risk of a piece of software turning into a toaster, for example, is practically zero. So we don’t need to worry about it.
Additionally, the other key part of risk is that it should always be negative in nature or have an undesirable outcome. The possibility of you receiving a phone call to notify you that you have won a fortune in a competition isn’t a risk. Even if you don’t want the money, or even if you do. There is no possible bad outcome.
Some risks may never materialise and this is the hard thing about planning for any risk. It is the unknown in software, projects and everyday situations. The best we can do is identify the possibilities. Rank them in order of their likelihood to occur. And plan our testing to mitigate the risk factor.
How do we handle risk in software testing?
Once you have identified the potential risks to your software. You need to implement a strategy that will tackle these problems head-on. And enable you to release software to your clients on-time, error-free and with all potential flaws investigated.
It can be easy at this point to think that there is risk in everything in software features and everything needs the maximum amount of testing applied to it. Which I can kinda understand. None of us wants to release something to a client with potential errors lurking within. Not only because it’ll look bad on us, but it’s also really embarrassing.
The problem with this approach is that not all risk is born equal. As you can see in the above line graph. The smaller the risk. The less testing you need to perform on it. On the opposite end, the greater the risk involved, the greater the amount of testing that is required.
Communicating risk
While most software testers will usually be able to identify some of the risk involved with your software product. Not everyone has the same level of experience, product knowledge or understanding as everyone else on the team.
Let’s say a bug in the previous release of the software has now been fixed in the latest release. The tester assigned to test the fix might not have a broad understanding of the impact that the change will introduce.
For instance, changes to an input box on a registration form may impact the way the data is stored, how it is displayed in other parts of the program, as well as affect other areas which use that data.
Now, these changes may not have serious consequences for the end-user. But as a tester. I would always advocate for communicating with other members of your team or the programmers involved. And then get a sense of what the change impacts and ask inquiring questions to discover.
Learn from others
When you don’t communicate your testing ideas, concerns, or questions about the risks you face to other testers or programmers. You are leaving yourself in a very vulnerable position. The unknowns surround you from all sides and your knowledge about the program is quite small.
I recently attended an online workshop in which we were given an example application and had to explain to other members of the group how we would test it.
After everyone explained their process and how they would perform their testing. It became clear that while there were differences in backgrounds, experiences and viewpoints about the best testing approach. It was apparent that we all saw something different.
Combined, we had an effective test strategy that would be able to test the system thoroughly, as well as any potential risks that were identified.
Don’t be afraid to listen
You’ve probably heard the quotes:
Alone we can do so little; together we can do so much.
or…
There is no “I” in “Team,” but there is an “E” for “Everyone.” A team achieves more when everyone contributes.
But when it comes to testing software. It is crucial to not only learn from others, bounce ideas off when needed. But to also listen.
You will rarely be the most experienced person in the room and although your ego might be bruised by hearing it, you probably don’t know everything.
The risk of bad software can be catastrophic. Where that’s financial, peoples reputation, or even death. Can you afford the risk of releasing bad software over not asking a question?
