Forum Discussion

navsta's avatar
navsta
Occasional Contributor
3 years ago

What is the best way to set up tests?

Hi All

 

Just about to start using zephyr scale and before that, wanted to know whats the best way to start?

Create tests from the main view and sort in folders on the left?

 

What other ways/structure works to display different systems test cases under one project?

 

Open to ideas

 

Cheers

  • Hi there,

    We have been in a similar situation... We just started using Zephyr Scale in anger recently, having moved from another test too.

    What we did (and seems ok so far!) is:

    • We have concentrated all our tests within a single Jira project. Otherwise it was too confusing to find things sprinkled around.
    • Define a consistent folder structure for the Test Library repository of reusable tests. The value here is being able to find a test afterwards. Zephyr Scale seems quite good at finding things within folders so the tree hierarchy helps us. My fear is we may have too many folders / subfolders caused by having a folder for each variant of testing - eg testing something by web interface, command line, API...  
    • We then defined an Active Projects area where we hold test cases just for the "in progress" project that are new. Idea is to make them easier to find, and then sweep them into the reusable Test Library when we complete a new release.
    • We then build Test Cycles comprised of picking reusable tests from the Test Library, and new tests from the Active Projects area. 

    Hope this helps...

     

  • Hi Navsta,

     

    What worked for me was to use the folder structure to file Test Cases into a logical order to make it easier to locate the TCs when required.  An example of the folder structure I used, is: "Test Phase + Test Team" > Product > Function.  Including the Test Phase and Test Team at the top level was useful to easily store test cases that were being used in a specific test stage (e.g. SIT E2E), and which test team (internal, vendor, partners) were responsible for its execution.  The labels feature in a Test Case enables a further way of logically grouping tests and you may find that useful too.

     

    After the Test Cases were created, I then setup a hierarchy of Test Plan(s) with Test Cycles, where the Test Cycles once again include the testing team + the name/function/product.  I found this approach was useful for reporting and using the Test Cycles page as a dashboard (this is an excellent page for an overview of testing progress).

     

    In scenarios where the same Test Cases were to be executed multiple times, e.g. for different browser platforms, I preferred to add those test cases into separate Test Cycles, using the Test Cycle name (and adding the platform) as a way to logically group tests.  For example: the Test Cycle Names might be "SIT-E2E Test Function A on Edge", "SIT-E2E Test Function A on Chrome", "SIT-E2E Test Function A on Firefox".  The main reason I use this approach is to make dashboarding and reporting easier.

     

    Hope that helps.

     

    Andy

  • julian_palmer's avatar
    julian_palmer
    Occasional Contributor

    Hi there,

    We have been in a similar situation... We just started using Zephyr Scale in anger recently, having moved from another test too.

    What we did (and seems ok so far!) is:

    • We have concentrated all our tests within a single Jira project. Otherwise it was too confusing to find things sprinkled around.
    • Define a consistent folder structure for the Test Library repository of reusable tests. The value here is being able to find a test afterwards. Zephyr Scale seems quite good at finding things within folders so the tree hierarchy helps us. My fear is we may have too many folders / subfolders caused by having a folder for each variant of testing - eg testing something by web interface, command line, API...  
    • We then defined an Active Projects area where we hold test cases just for the "in progress" project that are new. Idea is to make them easier to find, and then sweep them into the reusable Test Library when we complete a new release.
    • We then build Test Cycles comprised of picking reusable tests from the Test Library, and new tests from the Active Projects area. 

    Hope this helps...

     

    • navsta's avatar
      navsta
      Occasional Contributor

      appreciate your reply Julian!

  • MisterB's avatar
    MisterB
    Champion Level 3

    Hi Navsta,

     

    What worked for me was to use the folder structure to file Test Cases into a logical order to make it easier to locate the TCs when required.  An example of the folder structure I used, is: "Test Phase + Test Team" > Product > Function.  Including the Test Phase and Test Team at the top level was useful to easily store test cases that were being used in a specific test stage (e.g. SIT E2E), and which test team (internal, vendor, partners) were responsible for its execution.  The labels feature in a Test Case enables a further way of logically grouping tests and you may find that useful too.

     

    After the Test Cases were created, I then setup a hierarchy of Test Plan(s) with Test Cycles, where the Test Cycles once again include the testing team + the name/function/product.  I found this approach was useful for reporting and using the Test Cycles page as a dashboard (this is an excellent page for an overview of testing progress).

     

    In scenarios where the same Test Cases were to be executed multiple times, e.g. for different browser platforms, I preferred to add those test cases into separate Test Cycles, using the Test Cycle name (and adding the platform) as a way to logically group tests.  For example: the Test Cycle Names might be "SIT-E2E Test Function A on Edge", "SIT-E2E Test Function A on Chrome", "SIT-E2E Test Function A on Firefox".  The main reason I use this approach is to make dashboarding and reporting easier.

     

    Hope that helps.

     

    Andy

    • navsta's avatar
      navsta
      Occasional Contributor

      thanks for your insight MisterB!