Entity Change Management in ACCELQ

Capability Availability: Version 4.1 and higher

 

ACCELQ supports change control for Actions and Scenarios, so that users can check-out an entity and make changes without impacting other users. User can verify the changes in isolation before merging into the main repository of test assets. Once the entity is checked-in, changes are available to all the users on the Project.

ACCELQ takes an integrated approach to version control, where in the changes are reflected in the related entities in a functionally meaningful fashion. For example, changes performed in an Action may some times require changes to related Scenarios. But until the Scenario is checked-out and appropriately updated, system maintains a reasonable default behavior ensuring system consistency. This is extremely important considering inherent traceability across entities in ACCELQ.

And just like any other feature on ACCELQ, this capability is accessible to users without requiring technical background.

 

Enabling Version Control

Version Control can be enabled at a Project level in ACCELQ. With Project Admin privileges, open Project Configuration modal.

• Click on General Settings in the left-nav links.
• Select Version control checkbox to enable it and un-check to disable it.
• Click on Save Changes button.

 

 

Once version control is enabled, Actions and Scenarios are now locked for editing. You must check-out an entity to allow editing.

Note about disabling version control: You cannot disable version control while there are active checked-out entities in the project. All the previously checked-out actions and scenarios must be checked-in or undo-checkout before version control can be disabled.

 

Check-Out an Action or Scenario

When version control is enabled, a lock icon is displayed besides the name of the Action/Scenario in the top toolbar of entity page. You cannot make edits until the entity is checked out.

You can check-out an Action or Scenario in two different ways:

 

      1. Click on "Check Out" button when you open the entity. 

 

      2. Right click the Action or Scenario row in the Navigator grid and select “Check Out”

 

Provide a meaningful reason for check-out in the confirmation dialog. Make sure the purpose of check-out is clearly documented.

Check Out button in the entity page now changes to Check In and the lock icon is removed.

 

 

Navigator grid indicates checked-out entities with a badge against the name of the entity. Hovering on the badge displays further information on who checked it out and when. Blue badge indicates the entity is checked out by the currently logged in user, while the gray badge indicates the entity is checked-out by someone else.

 

 

Once an entity is checked out by a user, it is locked out for other users. It cannot be checked out by other users until the lock is released either by checking in or by undoing the checkout.

Note: If a user has read-only privilege (based on the assigned Role) for an Action or Scenario, Check Out button is not displayed.

 

Filtering Checked-out entities in Navigator Grid

You can filter out checked-out entities in the Action and Scenario grid using the "Checked Out" filter as in the screenshot below.

 

 

Editing the Action after check-out

Once an Action is checked out, user can start making changes, which may include updates to action logic, changes to Action's signature such as the destination context, parameterization etc. You can also start editing element selectors while the Action is checked out.

All the updates are applied in isolation for the checked-out user only, without affecting other users. Any Scenario which uses this Action also exercises updated action logic for the user who checked-out the Action. Same Scenario executed by other users continues to make use of existing base version (old) of Action logic. This applies even to other Actions which are using the currently checked-out action using Call Action feature.

Apart from regular updates to action logic and statements, consider the kind of changes which results in change of signature of the Action. These types of changes usually create change-impact across other entities as well.

For example, if you add a new parameter to an action, a dependent Scenario should provide values for this parameter in the test cases. You can check-out the Scenario and start editing test cases and provide values for this new parameter. Until that time, Scenario continues to work with blank values for the newly added parameter.

Here is a list of types of changes to Action logic that require corresponding change to Scenario.

• New parameter added: Scenario should provide values for these parameters in the test case.
• Existing parameter deleted: If the deleted parameter was used as a linked parameter in the Scenario, make appropriate changes to parameter linking.
• Data source of a parameter is changed: Be sure to furnish appropriate values in the test cases.
• Destination of the action is changed: This may result in missing steps in the scenario. Edit the steps to handle new flow.

For all these situations, when you open a Scenario which is dependent on this updated Action, an alert is displayed suggesting to apply appropriate changes to the Scenario. This alert is removed the moment Scenario is checked-out.

 

 

Check-In

Once the changes are ready and validated, you can check-in the entity, which makes the changes available to all the users on the project. Before deciding to check-in, you can also review the original Action by clicking on the Check In dropdown button.

 

Check-In will move the changes to the main repository. Be sure that the changes are complete and ready.

 

Undo Check-out

In case you decide to discard all the changes done in this check-out cycle, you can also select to undo check-out. Note that all the changes are reversed and the undo operation cannot be undone.

 

 

Undo operation will revert all the user's changes and get the repository back to the base version of the entity.

 

Order of Check-In

When related changes are performed in an Action and a Scenario, system imposes that the Action be checked-in before allowing the Scenario to be checked-in. An example for a related change is when a new parameter is added to the Action and the Scenario has defined values for this parameter in the test cases. Both the Action and Scenario are checked-out by the user and they must be checked-in. But Action must be checked-in before you can check-in the Scenario in order to make sure the integrity is maintained.

 

Element Change Management

Updates to Element identification criterion is an integral aspect of action logic development. However, Element Repository is owned and centrally managed by the Context and all Actions in the Context share the same repository. This creates a situation where an element may be updated by multiple users at the same time via their own checked out Actions. This possibility is seamlessly managed by ACCELQ.

Here are some points to remember about how element changes are managed under version control.

• If a Context does not have any Actions defined in it, elements can be freely updated from the Element Repository sidebar in the Context.
• If at least one Action is defined in the Context, then the element changes are only possible by checking out one of the Actions. Context's element side bar is in read-only view until one of the Actions is checked-out. Context's View based hover actions are also disabled until such time.
• When you update an element after checking out an Action, the element is implicitly moved to "checked-out" state. When the user checks in the Action, all corresponding element updates are also updated in the repository. 

Note the following situation. When a context consists of multiple Actions, it is possible that different Actions are checked out by different users. As part of Action updates, same element may have been updated by multiples users from their respective checked-out Action. When an Action is checked-in, it overwrites the existing copy in the Element Repository, so the last checked-in Action determines the final Selector for the element. 

 

 

Element Reconciliation

When an Action is checked-out, you can perform element reconciliation to update definition of elements in the owner Context. When you are replacing one of the existing elements with another element in the Repository, it is required that all the impacted Actions be checked-out by the user. System throws an error message indicating all the Actions where the references to the replaced element exist.

 

Overriding a Check-out

A project administrator can override a user's check-out of an entity. This may be useful in situations where the entity needs to be unlocked in the absence of the user that originally checked it out.

This operation should be performed with caution and only as a last resort, making sure the Admin has proper background of the nature of change that was performed by the user.

To override a check-out, right click on the Action or Scenario row in the Navigator grid and select “override”. This is available only if you have Project Admin on the current project. You can either choose to check-in or undo check-out.

In the screenshot below, gray badge for CHK OUT indicates the Action is checked out by some one other than the current user.

 

 

 

Running Scenarios

When you run a Scenario, systems picks up actions checked-out by you and executes latest logic. If you also checked out the Scenario and modified, then the test run reflects these modifications.

Depending on the entities checked-out and modified by different users, each user may get different result for the execution of same Scenario. Accordingly, Re-Run capability of Scenario may be influenced by the state of Scenario when it was originally run.

 

Running Test Suites

Unlike a Scenario, Test Suite always maintains System View. In other words, all the entities that are part of a Test Suite are reflected from the base version, and presents same view for all the users in the Project. Even if a user has some scenarios and actions checked out, test suite only refers to the base versions. When running the suite, test cases and logic are also picked from the base versions, ensuring same result is achieved no matter who kicks off the suite for execution. 

If you intend to have your changes reflected in the Test Suite execution, be sure to check-in the related Actions and Scenarios.

 

Operations outside the Version Control scope

Following operations related to Actions and Scenarios are currently outside the version control semantics. These operations are instantly applied in the system.

Creating a new Action or Scenario

Creation of a new Action, Scenario or Element is completed instantaneously on the system and visible to all users immediately. This is applicable for cloning and all other forms of new entity creation. If you need to make any changes to the just created entity, check-out the entity first.

Deleting a Scenario or an Action

You can delete an Action or Scenario even without checking out. Make sure to review the impact of Action or Scenario deletion and confirm. System displays the list of Actions and Scenarios that are impacted due to Action deletion.

If you perform delete operation on an already checked-out entity, system removes both the base version and the checked-out version of the Action or Scenario. If the entity is checked-out by some other user, delete operation is not permitted.

Change of Owner Context for an Action

When version control is enabled, you cannot update the Owner context of an Action from the Action sidebar. You can only achieve this refactoring from the Context Refactoring workflow. To allow refactoring, none of the Actions in the context should be in checked-out state. And when the operation is done, it is persisted immediately.

 

 

Change of Action sharing contexts

Any updates to sharing of Action with other Contexts, is instantly applied across the system. If sharing is removed, be sure to review the change impact and confirm.