Forum Discussion

sp54321's avatar
sp54321
New Contributor
5 months ago

How to organise and update tests

I asked this question earlier:

"What would be the most efficient way of organising tests for this scenario:

I want to have my test cycles in subfolders so that they are under the app name and then under the version name, E.g. APP NAME - V9.5.0

However, when a new version is released and I create another folder e.g. v9.5.6, what would be the best way of migrating all of the tests into v9.5.6 but would also allow me to edit them without affecting the tests in the older folder v9.5.0?

The only way I can see is if I create a new test cycle, add in all of the tests and then go into each test that I want to edit, create a new version, edit it and save it, is this the best way?"

And I got told that is the best way to do it, however if someone comes along to do a test for and older version of the app, how will they know which version of the test case they should use?

Or is there a better way in which I am not seeing?

  • MisterB's avatar
    MisterB
    Champion Level 3
    5 months ago

    Hi.  If I remember correctly, the solution I suggested was to store your test cases in Excel format, for updating/additions and importing those into Scale when new versions are released.  In my head, the way it would work is something like this:

    • Test Plans
      • Release v9.5.0
      • Release v9.5.1
      • Release v9.5.2
    • Test Cycles
      • v9.5.0
        • v9.5.0 Function A
        • v9.5.0 Function B
        • etc.
      • v9.5.1
      • v9.5.2
    • Test Cases
      • v9.5.0
        • Function A
        • Function B
        • etc.
      • v9.5.1
        • etc.

    With this structure, test cases are specific to a version, and added to test cycles categorised by function (or whatever category is relevant).  The test cycles can then be grouped (for reporting purposes) within a test plan.  If it were me, I would actually manage all test cases in an Excel file, keeping separate sheets for each release version.  When a new version is released, I would copy the last version sheet in the Excel file, add any new test cases for new functions, amend test scripts where bugs have been fixed, etc., and then import that into Scale.  As part of the import, you can specify the Test Case folder structure, so all that would be needed (I think) is to right-click on the test case folders to create your test cycles.  Having separate test cases and aligning those with test cycles by version enables you to have the ability to test/re-test test cases specific to releases, and if you spot an edit you want to make to a test case on a specific version, you can do that without it affecting the 'same' test case in another version.

    Does that help/make sense?