Replies to Proper way to use cases | sets | cycles?

Hello,

The management of cases and sets is perfect.  When the same case belongs to multiple sets, and if these sets are used to create a single cycle, the cases are added only once. So, this should not cause duplicates.

Are the sets being used to create different cycles from the sets (one from regression set and one from story set)?  Or are the cases being used as linked cases? Can you please elaborate the scenario, so that we can better understand the issue and suggest.

Regards,

Niharika

Hello Niharika,

So the workflow is something like this:

• Initially a test case will live in a "User Story" test set to represent the work being done for that User Story.
• When the work is complete, the test cases from the User Story may be added to the "Regression" test set because it is now part of the regression pack.
• The test case now lives in both test sets, meaning when it is added to a test cycle, the report shows both test sets for the one test case.

So from how I understand it, the only way to prevent this from happening may From what I understand, the only ways to prevent this would be:

1. Duplicating test cases – which isn't ideal.
2. Removing the test case from the User Story test set when adding it to Regression – which also isn't desirable.
3. All of our test cycles will include the regression pack, as well as the relevant User Story test sets to that cycle.

Regards,

Cameron

Hello Cameron,

Today, AIO Tests doesn't store a mapping between what sets were used to create a cycle. And hence the display shows all sets where the cases belong. It would also be a challenge for AIO Tests to make a decision on which sets to show or not to show. Would grouping by folder/component in reports be a better view in your scenario?

Regards,

Niharika

Hi Niharika,

So we would like to be able to display the sets in this manner because it shows the test scope of the test cycle. As the folders display the product area instead, it is less informative.

By displaying the sets, we can understand the work that went into a cycle, something like:

• Regression Set
• PR-139 Add a table UI
• PR-140 Add a table API
• PR-001 Bug fix

This gives full visibility at a high level that everything going into a release was tested. I am not sure how we can achieve this without removing things from old sets potentially.

Cheers,

Cameron