Share this page
Pinning a test set to a baseline associates the tests in that set with the versions stored in the baseline.
When you pin a test set to a baseline:
- Only the versions of the tests stored in the specified baseline are run
- Tests that are not a part of the baseline are removed from the pinned test set
- All test runs are deleted from the pinned test set
- Only tests that are included in the baseline can be selected when adding tests to the pinned test set
When you clear a pinned test set:
- The tests in the test set are then associated with the latest version of the tests in the Test Plan module
- All test runs in that test set are deleted
Why is this useful?
Pinning test sets to a baseline is useful in a testing environment where there is a time lag between the development of tests for a particular version, and the running of these tests. While one team is running tests on the current stable version, another team may already be updating the Test Plan module with tests for future versions. Pinning a test set to a baseline helps to ensure that the correct versions of the tests are run during test set execution.
The team running tests creates test sets in the Test Lab module by selecting and adding tests from the Test Plan tree. However, due to the time lag between the development and execution of tests, the Test Plan tree may already include tests that relate to future versions of the application - new tests or updated tests with new steps. If the latest versions of the tests are run, the tests will fail. By pinning a test set to a baseline associated with a particular version, testers can ensure that tests or test steps that are not part of the version being tested are removed from the test set.
Pinning is particularly useful for automated functional testing, where function libraries are used. If a specific function library is included in many tests (for example Test 3 through to Test 100) but the function is still in development, running non-pinned versions of tests 3 through to 100 causes all these tests to fail.
Example:
Jack, a test engineer, is designing tests to check the flight booking feature of the Mercury Tours website. In the Test Plan module, he creates the BookFlight test consisting of two steps (step 1 and step 2).
As part of the next stage, the development team begins adding more functionality to the flight booking feature. To test this new functionality, Jack must update the BookFlight test with two more steps (step 3 and step 4.) Before updating the test, Jack creates a baseline (Baseline 1). In Baseline 1, BookFlight consists only of steps 1 and 2. Jack then proceeds to update the test with the two additional steps. The test with 4 steps will be saved in Baseline 2.
At the same time Alice, a QA tester, is testing the earlier version of the website that does not include the new functionality, as the development team is still working on this. The test set that she has created in the Test Lab module includes the BookFlight test that Jack has been updating. If she runs the latest Bookflight test with steps 3 and 4 included, the test will fail. To make sure that she runs the correct version of the test, Alice pins Bookflight to Baseline 1 before running the test. This removes steps 3 and 4 from the test.
For user interface details, see Select Baselines Dialog Box.
