Test Cases / Cycles / Plans Best Practices

Hi Bob,

I finished a project recently that shares some similarities with what you're describing. The service had scenarios with multiple test cases that needed to be executed multiple times.  Due to the nature of the service, it was important to be able to evidence the number of tests executed.

Using your scenario in this example, my solution was to create 1 version of each test case that needed to be executed multiple times, so 1 for option A, 1 for option B, 1 for option C.  Each test case however had a final test step that said "execute this test a further 10 times by clicking the "Start a new test execution" button at the top left-hand corner of this frame" (or something like that).  This resulted in us having 10 executions of option A, 10 of option b, 10 of option C.  If any of those 30 tests failed or blocked they were recorded and an Issue created.  This approach was a win-win: it was quicker and easier for testers to re-execute multiple tests (vs. moving between 10 different test cases with the same test steps), and we were still able to evidence how many tests had been executed.

Another thing I sometimes do, depending on the project and stakeholders, is to demonstrate where the testing effort has been spent, functionally speaking, i.e. we tested this functionality 'x%', etc.  This is another benefit of logically organising test cases and test cycles by a function/team, etc.  With that structure in place, I can export test case data (or test execution data) from Scale and place it into another tool where I can create some visuals, e.g. Excel + Charts (sadly we cannot report the same in Scale at present):

An example: each slice is a function that was tested.  I've left some generic ones un-blurred.  I can then use the same data and chart and change the values from '%' to 'n' to show the number of tests executed per function - particularly useful if you need to demonstrate how thoroughly a specific function has been tested

Cheers, Andy