Forum Discussion

mohana's avatar
mohana
Contributor
3 years ago

Designing Test plans and Test Cycles

Hallo Zephyr Scale community, can anyone suggest / help on the following:

 

1. How do you design the Test Plans and Test cycles tab in Zephyr Scale. (what do you include under each of these tabs)

2. Where do you create components and how do you use them

3. Best practices for adding labels

4. Which of the above two (Components or Labels) is more useful when generating reports

 

Just to elaborate my understanding:

Test Cycles will have examples like Iterations, Releases, Phases (1,2 etc) - while

Test plans will include examples like Shakeout Testing, Functional testing, Regression Testing etc.

 

Can Zephyr scale gurus / MisterB confirm.

 

Thanks in advance  

 

InsideZephyrScale
  • MisterB's avatar
    MisterB
    Champion Level 3
    3 years ago

    Hi mohana, 

     

    I'm just back from a holiday.  Maybe one day I will have time to create a blog that would answer your questions in detail, but I can try to help with some tips that I find useful:

     

    1. Test plans I use to logically separate test phases, e.g. SIT, UAT, NFT, etc.  The test plan area in ZS isn't that useful in my experience but the separation is useful when it comes to reporting as you can specify a test plan (and therefore group all linked test cycles) in your reports.

     

    Test cycles are linked to test plans.  I use cycles to break down testing into the different products or business units/teams involved in testing.  I find the ZS test cycles page extremely useful as a reporting tool.  Tip: you can add custom fields into the cycle and display them on the cycles homepage, e.g. I use a field to record a text description of the status of the test cycle.  As an example: "31-Oct: this is the status with this test cycle" - I find this useful for me and for keeping stakeholders up to date

     

    2. Components I have used as a tool to further group tests by a parameter, e.g. product, domain, workstream.  The component can be displayed at the test case level and displayed for sorting or filtering (where I personally find it the most useful), e.g. filter test cases by component where component = "...".  The filter can then be saved and is a quick way to find test cases that meet your filter criteria (this is a general tip - you can filter on many data points, not just component)

     

    3. I've found that using prefixes is best to help logically group them and maintain some order and control, e.g. browser_Chrome, browser_Edge, etc.  Another thing to consider if importing test cases in bulk (and want to include labels) is whether you add some controls as I mentioned above, before you import into ZS

     

    4. You might find that they are both useful as tools in their own right.  Components can only contain 1 value and that has its uses, whereas Labels can contain multiple values and is of course also useful.

     

    And confirming that your understanding of how to structure ZS matches at least with how I use it 🙂