Can you relate with this experience:

It’s the beginning of a release cycle, which includes a change to a feature which has existed in your application since before you were on the team.  From the first release of the application, your team has continued to develop and save test cases for regression testing, with the intent of keeping them updated.  The ever growing library of test cases are filed by release and feature.  After browsing through the library for some time without locating the tests for this feature, and with a deadline looming, you decide to develop your test cases from scratch, filing them as new feature tests for the current release.

The result of this approach is an unwieldy library of test cases, rarely referenced or reused.  I’ve come to believe the primary cause is the way in which test cases are organized and archived.  In most cases they are aligned by release.  This alignment favors and supports program and project management, over release and regression testing.  In comparison, the cost of testing is far higher than the cost of managing the overall release effort.

Beginning with the end in mind, the end-goal of any requirement and development effort is a feature utilized by an end-user.  That feature is most often part of a service or user interface.  The feature will be delivered as part of a release, but once delivered the feature is part of an interface.  So, the destination (the end) is the interface, NOT the release.

Since that is the case, what would the previous experience be like if the tests were developed and archived by interface rather than release:

It’s the beginning of a release cycle, which includes a change to a feature which has existed in your application for since before you were on the team.  From the first release of the application, your team has continued to develop and save test cases for regression testing, with the intent of keeping them updated.  The ever growing library of test cases are filed by interface.  After briefly browsing through the library to the interface being updated, with a deadline looming, you have plenty of time to review the existing test cases, make the necessary updates to align them with the new requirements, and annotate each with the current release and the requirement verified.

The result of this approach is an efficiently reusable library of tests suitable for both release and regression testing.  Each file will contain a history of each requirement verified, and release supported.  Accounting for the testing of all changes in a release will take locating and reviewing test files, but with this organization even that effort will be efficient.

Reconciling your current test library with this approach is best done over a period of time, starting with your current release.  The cost of transferring all existing tests to this new approach in one effort will be far higher than any benefit you may experience.  Instead, draw a line in the sand, leave the past behind, and develop just enough testing to support your current release effort.  For a time there may be need to reference previous tests during regression efforts, but this need will fade.

Be reconciled!