Software Testing Battle #2: Risk-Based VS. Regression

You are here

Risk-Based VS. Regression testingRegression Challenges

Many software QA testing companies build their regression test beds accumulating test cases of several releases. Test beds’ execution is based on available time, data and test environment. While the testers running such regression test sets gain skills from practice, they don’t have any specific regression testing skills get in trainings intended to help with advanced testing methods’ adoption. This can results in such gaps as:

  • No clear strategy of building, maintaining and running test suites
  • No business criticality-based test case prioritization
  • No requirements for test case traceability needed updates with every release
  • No specific regression testing environments and data strategy
  • No impact assessment because of release-specific changes

Addressing these challenges requires undivided attention paid to each point. Still, if such challenges exist, the question arises how companies today should manage regression testing needs. Most of them adopt the risk-based testing approach with limited risk assessment which suggests regression testing is done based on resource and time availability. Such approach raises the chances to miss some regression defects and therefore increases the cost of production support just as well. If you have no efficient regression testing strategy, this will mean:

  • No business domain knowledge
  • Greater size of the tested app
  • Greater size of your app-level strategy for regression testing

Risk-Based Role

Risk-based testing methodically addresses regression testing complexity and size. Everybody knows there are theoretically infinite possible ways the product may fail. Practically, it’s the same about apps as well. However, most testers and business users tend to test their apps for each practical use which ends up in a set of challenges as given above. However, these complexity and size issues can be solved by risk-based testing means like:

  • Encouraging prioritizing test cases according to the clearly defined feature or functionality importance
  • Encouraging impact assessment for identifying failure risks and addressing a requirement’s testability
  • Improving testing efficiency by ensuring the testing of every critical functionality most often used
  • Improving test case efficiency by excluding test cases which are not productive
  • Identifying the needs of test data at the planning stage.

Despite the above positives, this type of software QA testing is used across companies in a rather limited manner because of two reasons:

  • No clearly defined methods of measuring risk-based testing success
  • No stake holder engagement in test planning

Heading for Success

Test managers have already known about the risk-based testing concept for a while. Though, its usage is still limited despite its helpfulness for more quantitative quality risk measurement and reduction of regression testing effort.