Version-control the test cases

Question

Should the test plan be kept in the version control with the code ? That is, the test plan and the code are put under the same version control system and have the same revision numerating. I am not talking about unit test code, but a test plan document populating with manual test cases. There are some web-based test case management systems, but I doubt how the test cases are version-controlled and synchronized with the code ?

UPDATE: Acutally I am looking for a web-based test management system for my oragnization, because it allows easy access to the non-developers team members (i.e. no need to use VC to check out the test plan from the repository). However, I'd prefer to version-control these test plans, synchronized with major milestone/releases of the software. I've not found any test management system satisfying this need. Or I am looking in the wrong direction ?

Answer 1

It makes sense to me. I would expect tests (whether manual specifications or unit tests) and the corresponding code to be in lockstep. I would also expect (perhaps optimistically!) that documentation would largely be in step with the code for a particular checkin.

Perhaps if you can't keep them completely in step, you can make use of your source code tagging (or branching?) mechanisms to identify consistent version sets ? That may make more sense if your version control contains tests that you're revising/building your code base to attain (i.e. your tests lead your code - not by any means an unusual situation).

Answer 2

Personally, I like your idea. Although tests in many software development paradigms should be based off of a spec of how the system ought to work, not how it works currently, and thus could easily be developed independently of your synchronized code. Since they are essentially documents, they might work well in a document-version-control system of varying formality.

Some teams use a tool like TestDirector to manage test plans, test cases, and have them connected to the bug tracking system. Every test case, bug, etc has its history of changes stored in a database, such that you can go back and review it (and search it, with a bit of work and some jiggery-pokery, as The Doctor would say). However, we never put that in synch with code except at major milestones where we did code freezes, and at that time code + scripts went into MKS Integrity (personally, I feel we underused Integrity at our place of work... it's designed for use with the entire development team, not just code promoters).

Other teams just write up word docs and put them in a folder that gets backed up. Simple, but on small teams in not-too-big projects can work.