It’s important to understand if and how version control of your QA artifacts is relevant to your test management process. If you work in a highly regulated environment then it likely that version control is very important. If you work in an environment where documentation and traceability aren’t so important then this may not be so relevant. Either way it’s useful to trace the history and modifications to your test artifacts. As most tools will do this for you in the background it’s usually worth starting off with tracking the history of changes at first.
To understand the different approaches to version control read this previous blog post on the Three Approaches to Test Case Management Version Control.
So at a basic level version control may just mean having your test management tool track all changes that you make to a testcase. At a more advanced level version control may mean:
Needless to say different test management tools deliver different capabilities when it comes to version control. In the following example we look at how QAComplete implements version control and how the QA team can use these capabilities.
With QAComplete each testcase in the library is version controlled. Any change to the record will result in the version identifier being automatically updated. Testcases are grouped into sets. Whilst a set links to the testcases it doesn’t link to specific versions of the testcases. This means that only at testcase execution time does QAComplete’s version control come into play. When you run the cases in a set QAComplete takes a copy of the latest versions of the testcases. This means two things…
1. the tests in the library can be updated without affecting the those already being run. This is important because tests already run should not be modified if the library testcase is updated. If the test already run were updated then this would invalidate the run results. This is a concept that many low end test management tools don’t deal with very well.
2. tests in the run can also be updated without affecting the library testcases. Having said this there is the ability in QAComplete to change the testcase run time. If you do this then QAComplete can give you the option to propagate that change back to the library (and in doing so incrementing the version of the testcase in the library).
There is no concept of a baseline or check in/out in QAComplete. Although, there is the capability to setup a review process so that tests can be signed off and/or approved by users.
Version control in test case management can lead to all sorts of complexities in the QA process. If you keep it at it’s most basic it can be just about tracking changes and the modification history to a record (which is pretty easy for a tool to do in the background). However, for some companies it’s more important than this and there is a requirement to trace where different versions of a testcase are executed. Add to this the process of checking in and checking out testcases for modifications, along with the need to baseline collections of testcases and you have a vastly more complex test management process.
