If Fail, skip the rest of the steps?

Suppose we have a product that has 3 items and 4 functions. Each functions are applicable to each items. So, it will be like:

Item 1 – Feature W
Item 1 – Feature X
Item 1 – Feature Y
Item 1 – Feature Z
Item 2 – Feature W
Item 2 – Feature X
…and so on…

How should the test cases be written? We can have 1 big test case for an item, like this:

Test Case 1 – Features in Item 1

1. Test Feature W in Item 1
2. Test Feature X in Item 1
3. and so on…

Or 1 big test case for each function, like this:

Test case 1 – Feature W

1. Test Feature W in Item 1
2. Test Feature W in Item 2
3. and so on…

Then, suddenly a bug is discovered for Feature W. What happens next is, if we use Approach A, all test cases for Item 1, 2, and 3 will fail, because all test cases consists of testing Feature W. But if we use Approach B, only 1 test case, i.e. test case for Feature W only will fail.

But, how do we know either it’s an item, or a feature that will fail?

Also, to add salts onto the wound, there’s a possible tendency for testers to rush up testing, will lead them to skip the testing of the rest of the test cases that are not failing. For instance, if a tester found out that a bug can fail a third step of the test case, he/she may just skip executing the rest of the steps and just failed the test case. That’s why it’s no good to rush our testers to complete their tests quick :P

Of course, some may argue, maybe it’s better to use Approach C instead:

Test Case 1 – Feature W in Item 1
Test Case 2 – Feature X in Item 1
Test Case 3 – Feature Y in Item 1

That will translate to much higher number of test cases, i.e. number of features x numbers of item!

So, the remedy? Use Approach C if you want.

Or, what we can do is, make sure that the testers still execute the rest of the test steps, although the first part of the test is failing due to the discovered bugs.

How do we know the tester still execute the rest of the test steps? Relatively, we can judge from the execution time. That is, if your team have it recorded. If the execution time is much much shorter, than an average execution time of that same test, that could be something fishy.

Another positive reinforcement would be to motivate the testers themselves, about how major a bug that they could miss if they just fail a test because of a previous bug, for the sake of completing their tasks for the day.

That also means, the management should not be too pushy about us completing our tests faster.

Fast, cheap, good. These three attributes don't co-exist together. You can pick any two of them, but not all three.