Branching allows testing teams to create copies (Branches) of Projects in test development to work in parallel versions. While working on the Branch, you may be retaining the original (Master) or making different changes to each.
Branching provides flexibility for multiple teams to work on test development for different features or releases without impacting each other. For example, you could create a Branch for each Sprint and then merge it with the Master project after the Sprint closure.
ACCELQ supports comprehensive capabilities to branch and then merge, in a completely codeless and functional paradigm. Test assets are managed natively, without requiring any integration with an external version control system.
All the capabilities explained here are applicable for both manual and automation testing alike.
Various activities here may require Tenant Admin or Project Admin privileges, as noted where applicable.
Creating a Branch
Creating a branch requires Tenant Admin privilege. When you create a branch from a project, you tag related test assets for merging at a later point.
- Login as Tenant Admin
- Navigate to Manage Projects tab
- Right-click required Project row or click on the row-level context menu
- Select Create Branch Project from the context menu
Once created, a newly listed branch works exactly like any other Project in your Tenant. For example, you can assign users and roles, update configuration, setup new test assets, etc. If a user is assigned multiple projects/branches, he/she can switch between these projects and branches seamlessly.
By default, a branch project inherits the same set of users and the same configuration as the parent project.
|Here is an example of how different projects may be related once you create branches and sub-branches.|
Updating test assets from related projects
In the typical course of test development for various application releases, you may create a branching hierarchy appropriate for your needs. From time to time, you may update the test assets in one project with those from another related project. For example, you may pull changes from a parent project or from one of the child projects.
Although ACCELQ provides an ability to pull changes between any two related projects (as in the figure above), it is most common to perform this activity between a project and its direct parent or a direct child.
A Project can be updated with changes from a related project either as a Project Admin or a Tenant Admin.
As a Project Admin, click on the context menu against the Branching Information section and select Pull changes from Related Project
Alternatively, as a Tenant Admin, navigate to the Manage Projects tab and right-click the project that needs to be updated.
Selecting the Project to Update from
Once you decide to update the project, you are prompted to select the project (Source project) from where the updates have to be pulled in.
You can select one of the child projects or the immediate parent project to pull changes from. You can also select any other related project in the entire hierarchy.
Merge Wizard guides you through the process of updating a project with a step-by-step review of test assets. Two separate (related) projects are involved in this process:
- Target Project: Is the project which is getting updated as part of this flow
- Source Project: Is the project from where the changes are pulled
It is important that you clearly differentiate these two projects during the merge/update process.
In the Merge wizard, you are reviewing the changes in the Source Project and accepting/rejecting to be pulled into the Target Project. Changes in the Source project are presented in comparison with the Target project with a two-column display of difference (diff-view).
Reviewing the changes
All the changes done in the Source Project are presented for review and to accept/reject into the Target Project. Note that you are reviewing the updates to the Source Project with an intent to accept (or reject) into the Target Project.
Changes happening in the Source Project are divided into modules and the review process moves from one module to the next, based on their order of dependency. For example, changes to Scenario are presented before the changes to the Action are presented, as the Scenarios depend on the Actions. Similarly, Element changes are presented after the Action changes due to the dependency order.
In a given module, you navigate through each change and accept/reject to move to the next item. Once all the items in a module are decided on, you can navigate to the next module and so on until the last module.
Categorization of changes
Changes in Source project are presented in 5 categories for each module:
- Modified: Set of entities that have changed in the Source project compared to the Target project. You may accept or reject these changes to the Target project.
- Added: Newly added entities in the Source project. You can choose to add these entities to the Target project or ignore them.
- Deleted: Deleted entities in the Source project. You can decide to either delete in the Target project also or to retain it as-is.
- Added: Auto Accepted: Explained in the dependency-analysis section below.
- Deleted: Auto Recovered: Explained in the dependency-analysis section below.
Across each of these categories, you can take bulk actions like Accept-All or Reject-All by clicking the "..." icon in the category header.
ACCELQ's Test-Asset approach is built on core concepts of modularity and reusability, which means there is cross-utilization of test assets and supporting entities. As you make selections in one module, there may be some hard dependencies in the subsequent modules.
For example, based on the Scenarios selected to be added or accepted into the Target project, there may be a hard dependency on some of the newly added Actions from the Source project. When you are reviewing changes in Action module, this set of Actions becomes mandatory to copy to Target project. ACCELQ calculates such dependencies and automatically selects them in the Actions module. These Actions are placed in the Auto-Accepted/Auto-Recovered categories. You are not allowed to change these selections.
When moving out from a module, a thorough analysis is performed to make sure the selections in this module are valid and sufficient. This avoids integrity issues when the final merge is submitted. In some occasions, there may be internal dependencies within a module such as an Action calling another Action. Depending on which modifications you accept to copy to Target project, there may be other Actions that need to be pulled in. You are prompted to add all such dependencies.
Granularity of change detection
Changes are tracked and presented at following module levels:
- Configuration changes
- Resource changes
- Test Suites (Automation & Manual)
From the list above, you can notice that a change to an individual Element is tracked independently, rather than as a change to "Element Repository". User can make a decision to accept/reject changes at the level of an Element. This approach reduces the possibility of conflicting changes when you are working in a dynamic setup with multiple Sprint teams updating respective branches concurrently.
Handling Project Configuration changes
Configuration changes are handled gracefully to ensure there is no impact on the existing entities when configuration changes are applied to the Target project. Here is how different changes are handled in the merge process
- Status fields: Newly added status fields in the Source project are automatically carried over to the Target project, while any modifications are presented for a user-decision to accept/reject.
- Custom fields: Same as the status field values above. Additions are automatic, but modifications are presented for accept/reject. Applicable-modules for custom fields are consolidated between the Source and Target project.
- Execution Parameters: All the newly added parameters are automatically added while modifications are presented for accept/reject. All the list values and multi-select options are consolidated between the two projects.
- App Environments: Newly added environments are automatically added. Updates in the existing environments are presented for accept/reject.
In all the above cases, deletion of configuration items on the Source project are automatically rejected. If necessary, configuration items can be deleted from the Target project after the merge process.
Other configuration items such as Integrations, Notifications, General Settings, User Setup, etc. are not carried over to the Target project as part of the merge process.
Merging the Views
When comparing the Views in the Source project, the following options are presented for the newly added Views and deleted Views from the Source project.
- The first option for the newly-added-views makes sure only the minimum required Views are copied over the Target project, ensuring that the Target project is not cluttered with an overload of unnecessary Views. ACCELQ runs an algorithm to optimize the number of Views automatically. It is recommended to choose this option unless there are other reasons.
- The second option below copies over all the newly added Views from the Source project to the Target.
Similarly, for the Views that are deleted in the Source project, it is a good practice to delete them in the Target project unless they are needed for other test assets in the Target project. It is a good practice to purge unneeded Views.
While reviewing the changes, specific attention must be paid if a Merge Conflict flag is displayed for a test asset in the diff-view. This flag indicates that the test asset has been updated in both the Source and Target projects independently (concurrently). So, if you are accepting the changes in the Source project to be copied over to Target, you may potentially end up losing the changes done in the Target project.
Carefully review the diff on both sides. If required, you may open these entities directly from the Merge wizard and make changes. You may refresh the diff-view by hovering on the name of the entity and clicking on the refresh icon.
Reviewing the Summary of merge operation
You can review the current status of update selections/rejections etc. by clicking on the Module dropdown in the left-nav. This brings up a summary of current selections, along with an ability to navigate back to one of the modules already completed.
You are also presented with this Summary screen just before the final confirmation button is clicked in the merge wizard. You can go back to any module for corrections and continue the progress.
Project Merge under Change Control
If change control (or version control) is enabled either on the Source or Target project, the following points must be considered. If possible, it is recommended to get all the entities checked-in on both the Source and Target projects before initiating a project update/merge.
Entity is checked-out on Target project
Since the entity is checked-out on the Target project, it cannot be overwritten. Consequently, if there is an Action or Scenario that you are reviewing in the merge wizard, Accept button is disabled.
If required, you can navigate to the entity on the Target project and release the check-out lock by either checking in or overriding. Simply refresh the entity in merge wizard after releasing the lock and accept the changes on Source project.
Entity is checked-out on Source project
If an Action or Scenario is checked-out on the Source project, the diff modal presents the base version and when you accept the changes to move to Target project, you are moving the base version. Checked-out user's version of the entity is not copied.
Viewing Update History
You can review update history either from the Project grid (Manage Projects, as a Tenant Admin) or in the Project Config home screen (as a Project Admin).