Forum Discussion
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
- v9.5.0
- Test Cases
- v9.5.0
- Function A
- Function B
- etc.
- v9.5.1
- etc.
- v9.5.0
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?
Related Content
- 4 years ago
- 2 years ago
Recent Discussions
- 10 days ago