Risks, who has not heard this word in IT projects? In the different phases of our projects, it is recurrent to hear about possible problems or situations that, if they occur, will have an impact on the project (whether positive or negative), our Software Testing area is not exempt from it and it is there where the frameworks propose approaches for them to be considered.
Motivated by the above, we find Risk Based Testing (RBT) where the features and functions to be tested are based on priority, importance and possible failures.
Our initial goal will be to identify the risk for the project and thus analyze the risk associated with the potential cost to it.
Our projects not only face risks, but also have different limitations such as time, resources, quality requirements in terms of organization standards, as well as factors such as: new technologies, lack of knowledge, lack of experience, to list a few, that generate a scenario where RBTs work really well in this regard. In other words, given the possibility of undesirable result events with a significant impact on the project and based on the fact that the tests are not totally exhaustive, we will direct our efforts to test the functionalities that have the greatest impact and probability of failure.
To start with our RBT, we can start from the risk analysis of the product, for this we can rely on:
- Clear understanding of software requirements specification, design documents, and other documents.
- Brainstorm with project stakeholders.
Once the risks have been weighted and prioritized, we will seek to reduce the level of risk found through the execution of the tests, where we can rely on any of the following techniques:
- Route flow tests.
- Exploratory tests.
- Limit value analysis.
- Equivalence partition.
- Decision tables.
Through this methodology we will obtain an improved quality, mitigating risks with more efficient tests in scenarios of limited resources and time.
