Fixing a bug in one area of the software may break something in another area. To detect whether defects have been introduced, we need to perform regression testing—executing certain test cases again to see whether a change has affected other existing features. But how do you make time for another testing cycle prior to every production release? You need to get QA involved earlier in the software development lifecycle.

Risk-based testing is an approach to testing that helps us handle our limited resources. It’s also a valid model for years to come because it focuses testing resources where they can have the most impact—regardless of whether limitations are due to budget, tight schedules, or even the uncertainty of an unexpected situation like COVID-19. Here are some practical tips, examples, and steps you can use to adopt risk-based testing.

Imagine you have X-ray vision. Instead of seeing through walls, you can see the inner structure of programs, the bugs lying inside, and how to expose them. Anyone could execute the steps you gave them to reproduce the bugs. The difficulty in testing, then, is not in executing steps; it is figuring out what steps to take. How do you find those hidden bugs? We need to be the X-ray vision.

While automation can help you save time and money in your testing activities, there are a few hidden costs that many teams overlook. Aspects that don't have a price tag initially—such as what it will take to learn, adopt, and maintain a new automation tool—will end up costing you in the long run. Think through these considerations and answer some questions before jumping into your automation initiative.