Testertools Forum

1. Davidcrp
   Member

   Reputation:291

    

   Following is a a short introduction before specifying the issue.

   In our company we use CVS as a CM tool and PVCS tracker as a defect tracking tool. We use a CM methodology that we have developed and that meets our needs. However, this process has one drawback that generates some overhead and therefore requires some improvement.

   Currently, the Head stream in CVS is used for integration versions that are being built each week. All changes (bug fixes and new features) are being inserted to this stream. At some point when there is a stable integration version we create a branch and from this branch build release versions. Only critical bug fixes are added to this branch. At this point we work on two streams in parallel. Fixes are inserted to both streams and each change has an equivalent SCR (record in bug tracking tool). The problem is that if a bug is found in release version and also exists in integration version then 2 SCRs are opened one for each stream for tracking purpose and this inflate the bug tracking database.

   Does anyone has a good idea how to overcome this issue ? how could we improve the process in such way that will not required this duplication ?

   I really hope that I made myself clear.

   Thanks

   Posted 1 year ago #

2. Maureen
   Member

   Reputation:56

    

   Thank you for a very clear and concise post, and for the fact that you gave us the requisite background on your question. A somewhat refreshing post.

   The only options I can think of involve process changes:

   1. If a tester finds a bug in one stream, immediately check to see if it is the other stream also, and enter a single bug record for both streams.

   2. If a tester finds a bug in one stream, check to see if the equivalent bug record has already been entered for the other stream, and tie that record to the new stream instead of entering a new record

   3. Have someone check daily to see if there are duplicate bug records and close one of the duplicates.

   I'm sure that others who are more knowledgeable about the tools can come up with other alternatives.

   Posted 1 year ago #

3. Davidcrp
   Member

   Reputation:291

    

   Thank you very much for your prompt response.

   The SCR duplication is being made intentionally as each one has its own bug lifecycle (The values of the fields 'Current Status', 'Version Fixed' and 'State' of each SCR are different).

   The reasons are:

   1. The fixes for both streams are not always being made at the same time
   2. Release and Integration versions usually are not built at the same time.

   Posted 1 year ago #

4. Maureen
   Member

   Reputation:56

    

   Based on the reasons that you give, don't you really have a conflicting set of requirements?

   1. Avoid duplication
   conflicts with:
   2. Intentionally track each stream separately.

   Posted 1 year ago #

5. Davidcrp
   Member

   Reputation:291

    

   We need to track each stream separately, but is our solution the best one ?

   At the time when we defined the process we couldn't figure out a better solution. The simple solution was to create this duplication and this way to track each stream sparately. The problem is that sometimes we even work on 3 streams in parallel and then we open 3 SCRs for each stream and that makes the process even more complicated.

   Our current solution is quite a burden and we thought maybe there is another way to cope with this issue. Maybe we should change the process, replace the bug tracking tool to a better one that has more capabilities in which one record can track changes in several streams and so on.

   I hope that now the issue is much more clear.

   Posted 1 year ago #

RSS feed for this topic

Reply »

You must log in to post.