ORCANOS | ALM versions and baseline management have similar behavior as a source control, thus provides powerful and intuitive tools to manage, reuse and track data records accorss versions, offers a complete change history, prevent duplication, and allows reuse, using pointers (copy as link). 
Overview
Rather than manage versions manually, ORCANOS | ALM has a built-in versions management engine, thus allows storing multiple versions views for single test case or group of test cases and handle each version separately and this without duplicating information.
Comparing to the common practice of using MS OFFICE tools, the use of basline prevents the duplications of documents from one product release to the next one. Think of it like a building blocks; in order to get to the 2nd floor, you have to go throw the 1st one. You may look down at the 1st floor, but you do not need to build it again. The image above illustrates the use of data records in version 1.0 and ability to drift it to future versions while protecting the base line it is based on.
Requirement Management
Orcanos system have three layers of incopsolution around the data record. The first layer is the solution level layer, the second layer is the project layer, and the 3rd layer is the data records item layer. This structure allows the user to encapsolte the data in project and have the option to include the project in several solutions (enhance allowing reuse of the data record accorss solutions). The basline management infrastructure gives the necessary production to the data record as required by the 21 CFR Part 11 but, simultaneously, the ability to reuse the data as needed.
Test Execution
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 must be identified quickly 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 the development team provides a new software release. A test run contains all information from the related test case and 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 reflect 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 throughout 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 want 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 and allowing you to identify and manage changes easily.
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 manage and search through different versions of test cases easily. 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.
The post Effective baseline management for ORCANOS | ALM Requirements, Test, Defect (Bug) Management appeared first on Orcanos: Quality Management System: ALM Software Solution Tool.