Should Testers use Risk-based Testing only during Regression or should they only test important stuff even in weekly QA builds?

My question is that when Production release is approaching and QA team starts the formal "Regression" suite testing, Now, is that a great time to use risk-based techniques to guide test design or should we use Risk techniques , every time, during exploratory testing sessions, even if we are testing a NEW functionality in the product for the first time?

Also, what exactly is a "risk-based" testing technique?

Thanks for the answers in advance?

  • Hi Jeffery, if you found some answer acceptable, could you mark it as accepted? It really helps the other contributors and motivates them. Apr 8, 2019 at 8:50

3 Answers 3


Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.

James Bach.

Therefore, the level of risk-based testing you will deep depends on the techniques you use to question, study, model... the product and what you want to understand about it.

Think of testing as a walk in an optimization algorithm: You use your heuristic (risk analysis) to walk towards the global optimum (a bug) - however, you may end up on a local optimum (a simple bug) - therefore, some degree of chaos (not follow the heuristic) is necessary to increase the changes of finding the global optimum (the important bugs).

Your heuristic will get better with familiarity with the product, so you can slowly rely on it more and more. While, at the beginning, it's more interested to go with more extensive strategies, trying to cover a lot of ground.

  • In many mature applications having requirements/documents in place, one doesn't need to 'learn' the application by exploring. Apr 16, 2019 at 1:08
  • 1
    Have you ever seen an application where every possible behavior, every dependency, every expectation from every kind of user was documented? Application which, additionally, this documentation was updated after every kind of change in it or in its surroundings? Apr 16, 2019 at 6:08
  • 1
    Think about documenting a Hello World - besides the behavior, you would have to talk about every possible OS in which it can run (and why it cannot run on others - and what happens if you do), about every possible compiler configuration (for every possible compiler), etc. Now extend this to complex application... People documented the conditions of the Ariane 5 accident? I guess not. If you think that others have already learned (and documented) everything about an application, therefore you don't need to explore it to learn about it, you will probably find yourself mistaken very quickly. Apr 16, 2019 at 6:11

Every software testing company performs different types of testing. Risk based testing is the type of software testing that tells about the features and functions that needs to be tested based on priority, importance and potential failures. So, it’s better to start risk based testing with product risk analysis in the beginning. In this way it reduces the level of product risk when the system is developed.

Apart from this, testers should do regression testing in weekly QA builds and should devote appropriate time for the same side by side in every QA build.


Testing is fundamentally an risk based activity so no matter which phase you are in you should prioritize what needs to be tested first based on risk associated as how much likely it may happen in production.

Testing gives you coverage in areas based on the risk of failure in the production.As risk-based activity it functions as an organizational principle used to prioritize the tests of features and functions in software, based on the risk of failure, the function of their importance and likelihood or impact of failure.

However once you select an area of importance to test, feel free to explore it in creative ways but within the realm of practical usage.

Example: I once saw an heated debate between an team member on entering negative values of Quantity in the system , application crashes. But development needs to put an important check in multiple areas but as it is not an practical scenario , they refused to fix it which business analyst supported until all other priority defects are fixed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.