When testing table, we usually verify the Sort function. Should we cover ascending/descending into one test case? There are two functions but have the same reproduced steps. However, the ascending order can work correctly but descending order can be fail. Which solution is better? One or Two cases?
@lanhuynh,
I have some points to make:
* what is the problem if I combine two test cases into one?
* what is the problem if I keep two test cases separately?
Look like it’s a design issue not the test itself.
My point is that as long as the test ideas are good, I’m less worried with how it’s designed 😉
I don’t understand your answer. This is the Test Case design issue. My team always confuses about this. If we merge them into one case, there will be failed the all cases once only one scenario failed. If we make them as multi-test cases, the execution time will be increased due to the duplicated steps.
@lanhuynh,
I see your points.
From what you described, I’ll try to avoid “duplicated steps” because “execution time will be increased”. These days, if there’s anything increasing the time without having following benefit, it’s a waste. We should always avoid that.
I’m also not terribly worried about failed cases if we combined into one case. Counting Passed or Failed does make much sense to me in terms of test management.
Hope this helps.
So, your answer is merging test case together, isn’t it?
@lanhuynh,
Yes, merging test case looks like a better option than splitting test cases and increasing execution time 🙂
@lanhuynh,
my first question to you is, what is more important, the way you write the test case or the execution of the test case? Which one tells us something about the system under test? Personally I’d encourage you to try and move beyond the creation and execution of detailed test scripts when possible. Often this is a difficult idea to sell to your managers but stay open to the idea. I spent years in testing where the expected norm was to spend as much time writing test cases as executing them. Often to find that test cases, carefully crafted were wrong because of design changes or because functionality had been misunderstood or, because during execution of some test cases I had thought of even better test cases to run. I now work on the idea of having testers spend about 20% effort documenting and 80% executing, test execution is where the value lays. This doesn’t really answer your question. I’d go for the option that allows you to document less and test more. Just make sure your documentation meets and internal standards you need to comply with. I see little point in duplication.