How to build a quality testing merge management process methodology in your organization

 

Is your organization working in parallel with several software product versions? 

 

If the answer is yes, this is an article you should read.

 

Most of the organization works with different versions in parallel.

 

Part of them already released to customers and part still in progress by development.

 

How you manage the merge process for all those versions?

 

In what way do you verify that all fixes are updated and distributed corrected?

 

By what method do you verify that development didn’t miss any fix? 

 

This is not so simple process cause if the project works only with one version and one customer – it very easy to manage it.

 

In case the project has some customers, each of them with a different installed version, in what way development verify that fix in the master version will be merge to version branches as well and nothing missed.

 

In my career were some cases versions/patches received for testing but the fix was missed cause of developer mistakes or misunderstanding the process.

 

Cause of such human errors or process misunderstanding the all R&D waste time, here some examples why it wastes time for all development group:

1. QA can’t verify the fix

2. Require additional time by the developer to merge it

3. Creating a deployment package by Devops again

4. Package installation again

 5. QA verification additional time 

As part of the software merge process, all developers should merge code to the master version. QA should verify that all merges are including in the main version and here is exactly the problem…

After all, developers do not always remember or know what merges should be including to the released version “x” or patch “y” and not forget all this merge to master if fix still relevant to the master as well and here the gap…

 

The fact that the project often does not follow a process for the merging of code leads to disarray and pain leads to disarray and gaps.

 

Here is a simple idea to follow merge management process methodology in TFS :

> Every current version will contain “merge” work items for each latest previous version that should be included.

> Each R&D changeset that made for merging changes from the previous version must be related to the same work item as it was related to the source branch.

In addition, should manage parallel versions methodology:

> Work items that will be included in more than one current version should be duplicated to both of the versions.

The work item in TFS should be linked in the following way (Work Item-> All Links->Link to).

This simple way of managing the merge process will not be missed any fix.

 

Is this post helpful for you? Share your thoughts in comments on how it helped you. 

Join to Productive Hut Family and be part of a testing community!