Share this page
After you create a library, you can create a baseline. A baseline is a snapshot of your library at a specific point in time. You can use a baseline to mark any significant milestone in the application development lifecycle. A baseline includes all the entities defined in the library, including requirements, tests, and test resources. Baselines also include:
-
the relationships between the entities in the library, such as traceability and coverage
-
any related entities outside of the library that the tests in the library need in order to run, such as called tests and test resources
Baselines enable you to keep track of changes made to your project over time. You can use baselines in the following ways:
-
Compare baselines at all stages of the application development lifecycle. For example, you can compare two baselines in a library to assess the impact of changes made to requirements over time. You can then update the relevant tests in your project accordingly. You can also compare a baseline to the current entities in the library.
-
Pin a test set to a baseline. This ensures that when you run the test set, the versions of the tests stored in a baseline you specify are run. For details, see Pinned Test Sets.
-
Use a baseline to share the entities in a library. This enables you to reuse the library's entities within your project, or in a different project. You share or reuse entities by importing a library. The library must contain a baseline. For details and limitations on importing libraries, see Imported Libraries Overview.
ALM Editions: Imported library functionality is available for ALM Edition and LoadRunner Enterprise only. For information about ALM editions and their functionality, see ALM editions. To find out which edition of ALM you are using, ask your ALM site administrator.
The following examples demonstrate how you can use baselines:
Example: Establish content of a release - stakeholder sign off
Your organization is starting development of a new version of an application. Robert, a business analyst, presents a group of requirements to the stakeholders to review. After the requirements are reviewed and approved, he creates a baseline. Stakeholders can then sign off on the agreed upon release content.
Example: Monitor change
Kelly, a product manager, finds that product development is being implemented differently than she expected. She reviews the requirements for the product and discovers that some have changed. She compares the current requirements with the requirements in the baseline created and agreed upon at the start of the release.
Example: Evaluate the impact of changes
Michael, a QA tester, is responsible for a large group of tests that are part of the latest application release. He is updating some of the tests in accordance with the requirements for the release. Following the latest requirements review meeting, he is notified that some of the requirements have been changed. Michael compares the current requirements with the requirements in the baseline created at the start of the release. He identifies which changes affect tests he is working on, and updates the tests to reflect the changes.
