Joel Montvelisky, Chief solution architect at PractiTest – test management tool, and Rob Lambert, Director of cultivated management, a tech consulting company with today’s topic: Risk-based testing.

• In the software development world, and specifically in testing, we are constantly trying to figure out where should we spend our time. With the basic understanding that we can’t test everything, we need to decide what are we going to test. This is where risk-based testing enters the picture.
• A risk is something that threatens the delivery of value to the customer. It’s something that might go wrong. There are two types of risks:

Product risk – basically equals bugs, a functionality that doesn’t work as planned.    

Project risk – missed targets. Can be time targets or cost targets.

• Another possible risk is the people risk. If people feel their job is on the line, they might take actions that are counterintuitive to the project. People can avoid taking innovative and intuitive actions because of the risk for their careers.  
• The idea for testing as a risk mitigator is seeing in which areas issues might occur, and focus the testing on these areas.
• If you are a risk manager, you need to manage each one of your risks separately: Schedule a date to approach a risk by deciding when is it going to be an appropriate time to handle it.

Dictate what is the potential damage arising from the risk – if it comes true, what would be the cause.

Probability – what chances are there for the risk to become true.

What Actions Can You Take to Avoid That Risk?

Continuous suppliance – if the risks happen, what should you do.

• Brainstorming can be a good way to decide what are the risks you are facing in your project.
• You can identify potential risks by consulting an external source (developers for example), dig into historical data or by using your common sense.
• Use tools like New Relic or logz.io to identify potentially risky areas.
• Run smoke tests and focus on failed steps to discover further risks.