How should we prioritize test cases before a release?

When testing before a release, the goal is not necessarily to execute every available test case. What matters more is running the tests first that are most likely to reveal issues that could put the release at risk. In larger systems, executing the entire regression test suite after every change can require considerable time and resources.

Risk-based testing follows the same principle. According to the ISTQB definition, testing activities are selected and prioritized based on identified risks and their levels. In practice, several types of information should be considered together when setting priorities.

First question: what has changed?

Every new release includes some form of modification. One of the most important factors in change-based testing is therefore identifying which test cases cover the parts of the code that have changed.

According to a 2026 study on commit-aware test case prioritization, combining structural information about code changes with coverage data and results from previous test executions can lead to more effective prioritization than relying on historical data alone.

Not every change carries the same level of risk

Knowing where the code has changed is not enough on its own. A modification to a simple component may involve a very different level of risk than a change to a complex part of the system that interacts with many other functions. For this reason, it is worth considering code complexity, the nature of the modification, and how critical the affected area is to the operation of the system.

Previous test executions can also provide valuable signals. A test related to an area that has failed repeatedly or shown instability may deserve a higher priority than one associated with a component that has remained stable for a long time. Test priorities can therefore change from one release to another. One of the key responsibilities of QA management is to evaluate these different risk factors consistently and use them to determine testing priorities.

Coverage reveals where the blind spots are

It is worth measuring not only how much of the overall codebase has been tested, but also how well the code changed in the current release is covered. If a modified area remains untested, it increases uncertainty when making a release decision.

A well-defined prioritization order also shows where the next available testing capacity can deliver the greatest value within a given release. This is why TestNavigator makes not only overall coverage visible, but also allows teams to easily track the coverage of changed code.

How does TestNavigator support this?

TestNavigator supports test case prioritization through the Test Advisor Score, which is based on code changes, code complexity, and previous execution data. The system ranks test cases so that QA teams can focus first on regression tests covering higher-risk areas.

TestNavigator is an AI-supported QA test management platform. It measures coverage for both manual and automated testing and also makes the coverage of changed code easy to track. Before a release, predefined Exit Criteria and Go/No-Go reports support more objective release decisions.

In this way, test prioritization serves a broader purpose: helping teams make better-informed decisions about whether a release is ready.

The goal is not simply to run fewer tests. It is to use the available time and capacity where they can reduce the greatest amount of risk. Before a release, not every test carries the same importance. Effective prioritization helps ensure that these decisions are based on measurable information rather than intuition alone.