How annoying is it when you’re going through that pile of mail on your coffee table and you have to keep going by items that are no longer relevant or you have duplicates of. This is what regression testing with an out of date repository is like. If you just keep adding to the repository without regard for what is already in there you’re defeating the purpose of what you’ve built.
Before adding any test case to a suite you should first go through the suite to make sure that: A) all cases are up to date, and B) that the test case you want to add isn’t already being testing under a different case. This brings up naming conventions. It is very important that you keep a strict naming standard. Usually the easiest way to do this is to use the user facing term for objects in your application. If a term changes, change all your test cases.
Let’s face it, applications are made to be living. If they weren’t, people would be out of a job rather quickly. Because of this, your test cases that cover minor components are going to change quite often. The more general tests shouldn’t need to be changed nearly as often, but major releases usually require an update to these.
If you’re using an automated suite, this entire task is made easier by front loading the setup of your test application to make different steps dynamic. This will greatly reduce update and maintenance time on your repository.
Keeping on eye on the size and detail of your repository is key to making it the most efficient with the most coverage possible with the least amount of maintenance necessary.
–dez