A risk is something that can impact (negatively or positively) the value of what we're aiming to provide.
Usually we talk about risks about event that can happen with a certain probability and can negatively impact some stakeholders (e.g., users) in a certain level.
Using non-encrypted protocols can expose sensible information, including credentials, to attackers. |
Risks can be handled in different ways: we can prevent/avoid them altogether, mitigate them, or simply accept them.
Testing is many times seen as a risk mitigation strategy, but it's also a strategy of preventing risks, depending on who and when is envolved while testing and the decisions that are taken upon the findings of testing.
We use testing to obtain quality related information. Risks and quality have a close relation. Risks can affect the value as seen by some stakeholder, at a given moment. In other words, risks can impact quality.If we implement a substantial feature without listening to users or having made some preliminary research, then there's a risk of that feature not addressing the needs of our users. If we use external libraries, then there's a maintenance and dependency risk that can expose us to more problems ahead.
When we test, whether implicitly or explicitly, we use risks to drive the experiments we perform.
Risk that...
In sum,
There is no straightforward and ordered "checklist" of the risks we should tackle. That requires expertise from tester and... context!
It's impossible to tackle all risks; it's impossible to test "everything". Therefore, whenever testing we have to think about where we will invest our effort in, so that we cover aspects that can give us valuable information about quality.
Software and the overall development process is not a localized event; its a journey. It has a past, a present, and a future.
This means that software has an history that culminates in the present...
It's important to understand...
It gives clues about, among other:
|
It gives clues about, among other:
|
It gives clues about, among other:
|
Software is made to address needs. Needs can be of different types though; they're not always "functional". What is the purpose that we're trying to achieve and to whom? Are there any existing references we should have in mind?
In general, we can say that a need is met if a certain goal can be achieved, effectively, efficiently, and with satisfaction.
Sometimes we focus our attention around effectiveness/correctness, which ultimately lead us to look at written specifications, acceptance criteria, or claims. While correctness may be crucial for banking and financial products, it's not as much relevant for a social kind of application, where UI and UX matter most.
But needs exist not only for external users but also for internal stakeholders and even for the team supporting and developing the product. Are we using deprecated dependencies or dependencies will well-known security issues, for example? Can a component or a service provider easily be replaced by another one? Is our infrastructure properly tracked, is it's setup scriptable, and are those scripts prone to error handling, for example?
Is testing currently just implemented at the surface? Are areas/features covered with automated test scripts? What level and type of tests (e.g., unit, integration, system, functional, performance, security)?
Knowing where we stand and depart from in terms of testing, tell us a bit about potential risks that can exist.
What are we covering already? To what extent? Do we have quick feedback loops about it? Do we have an history about it?
The risks that we are aware of, we can handle somehow, including with more or less testing depth.
We can group risks in a matrix, knowledge related, to give us a better understanding of the risks that exist and how we can approach them:
Say we have selected a risk.. how can we turn into a test charter?
Let's consider the following test charter template as basis; remember that this a template, it's not strict so you can adapt it freely to match your needs.
Explore <area, feature, risk> with/using <resources, restrictions, heuristics, dependencies, tools> to discover <information> |
Adapted from Maaret Pyhäjärvi, Elisabeth Hendrickson
Since we'll be performing a testing session, it will implicitly be limited in time, resources, and depth.
First, we have to think about the scope of what we aim to test broadly speaking, i.e. the subject of our testing. Do we want to perform the testing around a specific feature? About a subset of an existing feature? Around a flow? The whole product? If the later, then probably you'll need to refine your scope and limit it further.
Second, what will we bring to the testing session? Are there any resources, tools or heuristics that can help us? Are there are restrictions that can be used to restrict the scope of our testing or to amplify the probability of finding problems on the subject of our testing?
Third, what kind of information do we want to find? Do we want to find problems around the risk in general that we have identified? Won't that be too broad? Maybe we need to refine it.
Remember that we're talking about risks. As such, there's a probability of them occurring and the impact if they occur.
Our test charters should be around maximizing probability in one side but also consider situations that have a relatively low probability but still have a major impact.