What is a risk?

A risk is something that can impact (negatively or positively) the value of what we 're aiming aim to provide.

Usually, we talk about risks about event of events that can happen with a certain probability and can negatively impact some stakeholders (e.g., users) in at a certain level.

Risks can be handled in different waysdifferently: we can prevent/avoid them altogether, mitigate them, or simply accept them.

Testing is many times seen as a risk mitigation strategy. Still, but it's also a strategy of for preventing risks, depending on who and when is envolved involved while testing and the decisions that are taken upon the testing findings of testing.

Using risks to drive testing

We use testing to obtain quality-related information. Risks and quality have a close relationrelationship. Risks can affect the value, as seen by some stakeholderstakeholders, at a given moment. In other words, risks can impact quality. If we implement a substantial feature without listening to users or having made done 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 use risks to drive our experiments when we test, whether implicitly or explicitly, we use risks to drive the experiments we perform.Risk that....

Potential risks are: 

• the product and the feature doesndon't match user expectations and needs
• the feature claims are not met
• feature purpose is not clear and thus may not be used
• users get frustrated whenever using the new future
• users feel difficulties to use using the new future
• the feature is not consistent with other existing features within the product
• the new feature impacts other existing features somehow
• adds a considerable performance overhead
• the brand and UI guidelines are not respected
• it doesn't meet applicable law in all markets where the product may be subject to it
• it doesn't comply with regulatory requirements
• user data or the product itself can be accessed/used by non-authorized users
• the change is very hard to revert, operate, or monitor/observe
• the product or the feature will be a major success with a major spike in usage
• ...

In sum, to consider risk: 

1. Think about who are your users are, external and internal. Don't forget the unexpected users;
2. Think about what matters most to them;
3. Think about what could go wrong.

...

Contextualizing risks

There is no straightforward  straightforward and ordered "checklist" of the risks we should tackle. That requires expertise from the 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  its a journey. It has a past, a present, and a future.

This means that software has an a history that culminates in the present...

• features that exist and that are used
• features that exist and that are not used
• unintended behaviours behaviors (e.g., bugs, feature subtleties) that are used as features
• areas/features with technical and testing debt

...

1. How was it used in the past?

   • Info
     title Why?
     It gives clues about, among other: features that users were using (and not using) and to what extent flows that users were performing , and not performing

2. How is it currently used?

   • Info
     title Why?
     It gives clues about, among other: features that users are using (and not using) and to what extent flows that users are performing , and not performing if there was a change in user behaviour behavior and underlying needs if there was a change in the software that may have affected the current usage behaviourbehavior

3. How do we foresee it being used and evolving in the future?

   • Info
     title Why?
     It gives clues about, among other: concerns about performance and scaling how to monitor/track success how to quickly perform experiments with users existing features that may need to be rethought or that may be affected somehow, and thus may need tailored testing

...

Software is made to address needs. Needs can be of different types, though; they're not always "functional." . What is the purpose that are we 're trying to achieve, and to for whom? Are there any existing references we should have in mind?

In generalGenerally, we can say that a need is met if a certain goal can be achieved , effectively, efficiently, and with satisfactionsatisfactorily.

Sometimes we focus our attention around on effectiveness/correctness, which ultimately lead leading 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 will dependencies will have 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 its setup scriptable, and are those scripts prone to error handling, for example?

...

Knowing where we stand and depart from in terms of testing , tell tells 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 a history about of it?

Remember the unknowns

The risks that we are aware of, we can handle somehow, including with more or less testing depth.

...

• We can check the risks we know we know
• We can check & explore the risks we know we don't know
• We can pair with others to tackle unknown knowns , and expose our biases or things we assume or skip without knowing
• We can keep learning and exploring to uncover unknown unknowns

...

Say we have selected a risk.. how can we turn it into a test charter?

Let's consider the following test charter template as a basis; remember that this a template, ; it's not strict, so you can adapt it freely to match your needs.

...

Since we'll be performing a testing session, it will implicitly be limited in time, resources, and depth.

First, we have to think about consider 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 laterlatter, then probably you'll probably 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 Can some restrictions be used to restrict the scope of our testing or to amplify the probability of finding problems on the subject of our testing?

...

Our test charters should be around maximizing probability in on one side but also consider situations that have a with relatively low probability but still have a major impact.

...

Here are a few additional tips

• Internals
  • listen to your team, and pair with other team members, including developers, to expose risks that otherwise could escape
• Product Context & Market
  • listen to your users , to understand what's important to them, what they most value, and the things that frustrate them the most; these will give ideas of potential risks
  • listen to your business and what's important to them, to be on the same page, and don't ignore aspects that ultimately matter to your company and management
  • experiment with similar products, as you'll gain knowledge about what common and sometimes implicit expectations users may have whenever using your own product
• Success
  • try to understand what "success" means to different stakeholders
  • understand "where the money comes from" vs. "what are the common user/usage flows"
• Background Knowledge
  • learn more about quality attributes, to become aware of different aspects that people value differently; these are the different dimensions of quality that we can have in the back of our mind , that inform us about what risks can target quality aspects can be targeted by risks
  • learn more about heuristics tailored for testing, as these can be used to provide some ideas for test charters but also ideas for many diverse experiments during the test session itself

...