When should you update, mark as obsolete, or retire a test case?

Software is constantly evolving. New features are introduced, existing workflows change, and some functionality is removed entirely. The test suite needs to keep pace with changes that affect the behavior, requirements, or risks being tested. Otherwise, test cases may accumulate over time that no longer reflect how the software works, yet still require time and attention to maintain and execute.

Maintaining test cases is therefore much more than an administrative task. A well designed test management platform can help teams track changes to their test suites and clearly identify which tests remain relevant to the current software version. This directly affects testing efficiency and the reliability of test results.

Test cases need to evolve alongside the software

A test case is typically associated with a specific requirement, feature, or workflow. When these change, three situations may arise: the test is still needed but must be updated to reflect the new behavior; it is no longer relevant to the current release but remains valuable for historical purposes; or the functionality it verifies has been permanently removed, making the test unnecessary.

These situations should be handled differently. If every change results in a new test case, the test suite can quickly become difficult to manage. On the other hand, deleting old tests without preserving their history may make it impossible to reconstruct exactly what was tested and how in a previous release.

When should you update a test case?

A test case should be updated when the functionality it verifies still exists, but its behavior or expected results have changed.

For example, an order processing workflow might introduce an additional approval step, a business rule might change, a new field might be added to a form, or an API response structure might be modified. In these situations, the purpose of the test remains the same, but its execution steps, test data, or expected results need to be adjusted to reflect the updated functionality.

However, there is also an important historical consideration. A test case in its current form may not accurately describe how the system behaved three versions earlier. For software products with long development lifecycles, preserving previous versions of test cases can therefore be particularly valuable. This makes it possible to trace which version of a test case, including its conditions and expected results, was applicable to a specific release or software version.

When does a test case become obsolete?

An obsolete test case is not necessarily incorrect or poorly designed. It simply verifies functionality or behavior that is no longer relevant to the current software version.

Consider an application that previously supported two authentication methods, one of which was removed in a later release. The test cases associated with the discontinued method no longer belong in the current regression test suite. Nevertheless, they may still contain valuable information when reviewing or interpreting test results from previous releases.

Marking these tests as obsolete can therefore be more appropriate than deleting them immediately. This keeps the active test suite relevant while preserving the ability to trace historical behavior.

This distinction also matters when optimizing regression testing. Rather than assuming that every previously created test must be executed with the same priority before every release, teams should determine their testing priorities based on current changes and associated risks.

When should a test case be permanently retired?

Retiring test cases may be appropriate when redundant tests can be consolidated without losing relevant test coverage.

Duplication is a common example. In software that has been developed over several years, multiple test cases may verify the same functionality simply because they were created at different times or by different teams. In such situations, it is worth evaluating whether all these tests are necessary or whether a single, well designed test case could replace several existing ones.

A similar decision may be justified when the functionality being tested has been permanently removed from the product and there is no longer an auditing or traceability requirement to retain the test.

Before permanently retiring a test case, however, teams should ensure that previous test results and other necessary historical information remain accessible.

A larger test suite is not necessarily better

It is easy to assume that the more test cases a project has, the more thoroughly its software is tested. However, the number of test cases alone says very little about testing quality.

A suite containing thousands of test cases may include duplicates, obsolete tests, or tests that provide limited value, while a recently modified, business critical section of code receives insufficient attention. In such cases, the number of tests does not indicate whether the latest changes have been adequately verified.

It is therefore important to examine which features and requirements are covered by active tests and, in the case of automated testing, what code coverage information is available.

Requirements coverage indicates whether appropriate test cases exist for defined requirements. Code coverage, on the other hand, shows which parts of the source code were actually executed during testing.

In addition, risk based test prioritization helps teams determine where to focus their testing efforts by considering factors such as the business importance of a feature, recent changes, historical defects, and other relevant risks.

Releases provide the context needed to understand test cases

As software evolves, its associated test cases are continuously updated. This makes it important to track which versions of individual test cases were valid for a particular release, which tests were newly introduced, which were modified, and which became irrelevant.

When preparing a new release, teams should not simply rely on a static collection of tests. Instead, they should consider what has changed in the product and how those changes affect testing requirements.

TestNavigator supports test case versioning and release baselines. A release baseline records which test cases and which versions of those cases were relevant to a particular release.

Coverage information and change based testing insights also help teams assess release readiness using more than test execution statuses alone. They provide a clearer understanding of how thoroughly the latest software changes have been tested.

A well maintained test suite supports better release decisions

The value of a test suite does not necessarily increase as more test cases are added. What matters more is whether it accurately reflects the current state of the product, preserves relevant historical information, and helps teams identify where testing is actually needed after a change.

Managing the test case lifecycle is therefore about more than keeping the test management system organized. A properly versioned, regularly updated, and well maintained test suite provides a clearer picture of what has been tested, what has changed, and how ready a particular release is for deployment.