Risk-based testing

You never have time to test everything. So you spend your effort by risk: how likely an area is to fail, and how bad it would be if it did. This is risk-based testing.

Payments, sign-in, anything that can lose or leak data, and code that changed this sprint rank high. A settings page that few people open ranks low. Failure is more likely where code is complex or new, where it connects to many other systems, and where bugs appeared before, because bugs tend to cluster together.

Write a short risk list before you test. It makes your choices visible and easy to discuss with the team. It also shapes the next stage: which areas get detailed test cases, which get exploratory sessions and, later, which get automated first.