When it comes to testing, there tends to be a differentiation between “production software” and everything else. But our ideas and principles about testing software are true for all software, not merely the code that will run in front of customers or the APIs that make things happen. Any software built for a purpose needs to be tested against that purpose, including the software running our test automation.

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.