ORCANOS | ALM versions and baseline management have similar behavior as a source control, thus provides powerful and intuitive tools to manage and track versions, provides a full change history, prevent duplication, and allows reuse, using pointers (copy as link).
Rather than manage versions manually, ORCANOS | ALM has a built-in versions management engine, thus allows storing multiple versions views for single text case, or group of test cases, and handle each version separately, and this without duplicating information.
For instance, the historical steps results can be viewed at the point the execution of the test was performed. ORCANOS | ALM “Execution Set” is used for grouping test for execution. Once executed, the execution set stores historical data throughout each test cycle, and the full change history can be viewed in the “Execution History” tab.
Version views and baseline
As opposed to the common use of other test management tools, that physically duplicating test cases when project version advances, ORCANOS | ALM system maintains pointers of the previous version (which would act as a baseline), and track the changes in the current baseline. Test Cases information from older versions are kept, and once a test needs to be updated, Orcanos provides a BRANCH option that splits the test case to 2 instances. One in the previous version and one in the current. both instances are linked, so tracking changes is easy.
So, in summary, BRANCHING Test Cases creates an instance of the test cases on the new version while preserving the original as a baseline. BRANCHING also easily manages and searches through test case versions, by setting up a multiple views to query the data.
Preserving Test Case Base Line as Test Runs
ORCANOS | ALM uses both test cases and test runs. Test cases define the set of conditions, actions, expected results, and other criteria used to determine if a product component works correctly and meets its traced, specified requirements. Test cases can change over time to reflect functional changes in your product requirements. Such changes need to be identified easily and reflected on the correct baseline, which goes under testing.
Execution Runs on the other hand, are snapshots of test cases that are generated at a milestone in the testing cycle, such as when a new software release is provided by the development team. A test run contains all information from the related test case, in addition to the results of a specific instance of the test.
So while the test case may change in the future to reflect new user logic modifications, the test run steps that were executed in the past, remain in the history of the execution run, and will never change according to most restricted regulation standards for electronic systems, such as 21 CFR Part 11. By saving test runs, managers and auditors can look back on the exact steps followed during testing years, long after the tests have been completed.
A single test case can have one or more related execution runs such as Functional, Progression, Regression, Load and Stability to mention a few; depending on the test variants defined by test parameters selected when test runs are being executed. For example, should an application support multiple browsers, such as Chrome, Edge, and Firefox variants, these variants can be selected when you execute the test, creating a separate test run for each selected variant. The test runs include identical information, except for the test variant value, which indicates the browser used in testing.
Viewing the Full Change History
As noted, test cases change over the course of the development cycle. Should you want to view these changes, you may select a test case, and then click the Execution History tab to view a detailed change report, including who made the change, when it was done, and what was changed.
Change reports display details of content added to and removed from a test case (or any item, for that matter), each time it is saved. ORCANOS | ALM keeps audit logs of changes according to best practices of regulated design change management. These reports identify the specific changes made to a test case over time. Change reports are ALWAYS turned on and available for both historical item information logging, and detailed audit trail loggings for test cases.
Once you are in the Change Report window, you will see content which has been added or removed from the test case. You can also view the electronic signature in cases where changes are made and signed (in ORCANOS | ALM 2.0 and later), and you have permission to view the audit log, If there is an attachment, a link to it will be visible.
Reuse Test Cases
Should you want to add test cases that share the same basic information, ORCANOS | ALM saves time by taking the test to the next baseline automatically. You can then decide if you would like to keep it as it is, make changes, or just make deletions from that next baseline version. There is no need to duplicate an existing test case and then edit the new test case. Simply select the test case from the next baseline version on the product tree module, followed by selecting Edit Test Case by pressing the Edit button.
ORCANOS | ALM gives you the option to link the altered test case with the original test case into a new execution set. You can also specify the traceability between those test cases to a requirement, and any change to already existing traceability will be managed, based on the baseline it has been associated with.
For example, you might create a “Baseline Test Case” on version 1.0 traced to a requirement in 1.0, then you make changes to that test case in version 2.0. ORCANOS | ALM will alert you that there is a suspicious link needing attention. Allowing you to easily identify and manage changes.
BRANCHING test cases also “copies” information you select from the original test case. Besides the results, all other information including attachments, are always included in BRANCHED test cases. The newly BRANCHED test case now has a new baseline for Execution Run that is kept in tandem with the previous version results. In such cases, you can measure the Feature Maturity by looking at the history of the test over executed version, and see that it gets stable. History of the test will be kept through both version 1.0 and 2.0 at the same audit log, as well as file attachments, links, and more, from the original test case.
Original Test Case
Test Case after Branch
For more information about duplicating test cases, along with step-by-step instructions, see ORCANOS | ALM online help.
Querying Using Views
The ORCANOS | ALM view designer can be used to easily manage and search through different versions of test cases. In the View dialog box, simply select “test case” from the dropdown list, to add specific criteria to the view by selecting the field VERSION, and use the operands to search the data as you wish.
The end result should look something like this:
You can use this field criteria to identify the test case version for which each test case is valid, and make it visible at a glance in the test case list window. In the example below, you can see test cases and their version, as well as identify whether they were BRANCHED or not. You can also see the traced requirement of that test case.
In this example, the user has also displayed the column for Version Baseline Test Case Traceability relations links, enabling you to see which test cases are linked. Clicking on the blue bar links directly to that traced item.
When the 3.0 update is released, ORCANOS | ALM will advance the project, and automatically all test cases from version 1.0 and 2.0 will be available and will be managed separately. Any current test case that does not change, or does not need an update, will keep its original version. If a test case does need an update, the user would add that test case to Execution Run built into version 3.0, without duplicating the test case, Execute the test cases, and it will be marked as valid for 3.0.
Creating a general custom field, allows you to filter by many other attributes and creates KPI measurement on your overall productivity. ORCANOS | ALM enables email notifications about changes based on product version, enabling field-level security, and more.
Again, for more information about creating custom fields, see ORCANOS | ALM online help.
Folders are another option for managing test case versions in ORCANOS | ALM. Check out the online support and learning resources at www.orcanos.com for more information.