Continuing with our look at the complexities of test management with Quality Center we’re looking at version control this time. At a basic level version control means tracking which changes have been made to a testcase, who made them and when. Furthermore version control can mean tracking which version of a testcase was run against which release of a product and within which cycle. This is where version control starts to get complicated.
Within Quality Center we have 3 different areas of version control that we can apply to our test management process:
In this video we look at each of these test management versioning concepts in turn.
Audit Logs – When we view a testcase in the plan area we can see the history tab and Audit log which contains a list of all changes (who made the change, what was changed and when the change was made). Notice that this only applies to certain fields though. Tracking changes to other fields means customizing Quality Center and marking the fields as history tracked.
From a test management perspective the limitation with this approach is that it’s difficult to work out which version of the case was executed with the lab area. Quality Center takes a snapshot of the latest version of the case when you execute it, but there’s no indication of which version was used for the run. This limitation can be overcome with the baselines and versioning features.
Baselines – With baselines we can define a library and then take a snapshot at a point in time of the current versions of the contents of that library. If you’re familiar with source code control It’s a similar concept to ‘tagging’ a release.
A library identifies a list of requirements, resources, components and tests. At a particular point in time we’ll baseline that library and in doing so identify the versions of the library contents at the point where we take the baseline.
Where this comes into play is when we view records that are contained in the baselines library. Under the baseline tab we can select 2 instances where the record was baselined and compare them. Thus we can see changes made from one baseline to the next.
Also in the Lab area we can pin a set to a baseline. When we do this the set will ONLY contain testcases which are included in the particular baseline. Finally when we view the results we can see which testcases were executed from which baselines.
Versioning – when you set up a new project, or modify an existing project, you can enable a feature called versioning. With this enabled every time you make a change to a record you will need to add a change comment and check out the record before modifying. After making any modifications you then check the record back in. In this way Quality Center keeps a full track of changes to the record.
When you check in your changes QC gives the record a unique version id and records the check in comments along with all changes. Under the history tab you’ll see the new sub tab ‘versioning and baselining’.
In the test lab / test sets area we’ll have a Version number id which shows the version of the test case executed. The same is true under the runs area where we have the version id shown too.
With the versioning feature we now have the capability to track which version of a test is run against which version/release of a project. Whilst there is an overhead with the check-in/check-out workflow this does give us traceability beyond that of most test management tools.
