Is it one test case, or many different?

Hey guys!

Could use some help here regarding test cases. First of all, test cases should be written for a machine that a user could dispense notes and coins from. Coins always comes from one machine, but notes could come from two different machines, or note part could be disabled. Depending on note device, the flow that user sees on screen is different. If note part is disabled the flow also would look different.

Now to my question: Could this be written as one simple test case that says "dispense money" and then have a configuration column with the different machine configurations? Or should all configurations be treated as separate test cases, since there actually are some small differences to flow etc?

Please note that I'm writing a test specification in excel, which make it hard to get a good overview, but later this year a test case management tool will be implemented, and I think/hope that it will be easier to differentiate/group test cases then...

Thanks in advance
//Michael

▶ Reply to This

Replies to This Discussion

Permalink Reply by Rsf on January 19, 2010 at 10:51am: For start I don't think there is an absolute right or wrong here.
Lately I used a similar solution when it fitted perfectly for the problem- many test cases each is different in one of two parameters and minor changes in the scenario flow. Contrary to what you said putting it in Excel made it clearer to understand and easier to get get a quick overview.; ▶ Reply to This

Permalink Reply by Ainars Galvans on January 19, 2010 at 11:12am: I'm not sure I understand your specification - how does coins and notes are connected with what you call "a flow"?
Anyway - do you really care if this is one or many test cases? Does the number of test cases matter? I think what matter is that your test documentation help you to test and report. So maybe the question is - does anyone want to see pass/fail per each "machine configuration"?

By the way - it could appear that your implemented test case management would make things harder, plain tables are so wonderful. See more in this blog - where I analyze how "Test Cases for password policy" configuration is affecting password change test case and how could it be best documented; ▶ Reply to This

Permalink Reply by Michael Persson on January 19, 2010 at 11:25am: What I'm actually looking for is an easy way to create this test specification so that it covers all relevant combinations.

Let's say that a customer buys a machine that is configured to use coin machine and note machine A. Customer has three choices: dispense coins, dispense notes or dispense both. So there is three test cases for that specific configuration. But since the note machine B also exists, same thing has to be tested there, to verify that it's possible to dispense coins, notes and both.

And what if the customer only wants a coin machine and no note machine. Then the customer could only dispense coins. That's another situation that needs testing. Then another parameter could be used: dispense a predefined mix or select amount that suits the customer then and there.

I need to verify that all those possibilities works, but how do I write this down in an easy way?; ▶ Reply to This

Permalink Reply by Ainars Galvans on January 19, 2010 at 12:31pm: Michael, I'm still confused. Do you mean note=paper money; dispense = give a customer money? Well anyway I think there is no magic solution for you. You have to take pencil and paper, write down "all those possibilities" and then think how to present them. I recommend using tables or trees.; ▶ Reply to This

Permalink Reply by Michael Persson on January 19, 2010 at 12:41pm: Ah, sorry! Think of the machine as an ATM with coins and notes (paper money). Customer walks up, put her card in machine, enter pin, choose Dispense, select an amount and the money comes out to customer...

Yeah, I guess a tree picture thing would be the easiest way to at least represent the different combinations...; ▶ Reply to This

Permalink Reply by Joe Strazzere on January 19, 2010 at 12:13pm: Interview question?; ▶ Reply to This

Permalink Reply by Michael Persson on January 19, 2010 at 12:28pm: Hehe, could be I guess :) But this is actually to structure my daily work. I have an not-up-to-date test specification that needs some serious reconstruction, that's why I'm asking for input from other testers...; ▶ Reply to This

Permalink Reply by Aaron Hodder on January 19, 2010 at 9:02pm: Yeah I'd start with a big ol' table and see where I end up.; ▶ Reply to This

Permalink Reply by Krish Jayaratne on January 19, 2010 at 10:35pm: Michael,

As others have stated, I too think that there is no right or wrong answer here, but I would create 3 different test cases.

If I re-state the question the way I understand, your system consists of one or two modules, the second, if present, is from two different types. Then the combinations are,

1. Coin dispenser
2. Coin dispenser + Notes dispenser Type A
3. Coin dispenser + Notes dispenser Type B.

Since it is dispensing MONEY, you have to be careful :-) For example, if the systems think it has Type A, but actually the module is Type B, it could dispense wrong amounts as I have seen when testing ATMs. I think you will have some tests to check those types of errors.

Then even if you create a single test case, it would include some specific information for Type A and Type B. If the company introduces another type of a dispenser, say Type C, you will have to edit the test case and include those specifics. This is true if the behavior of A or B is modified with an upgrade to firmware or software. With a single test case, all these changes could create a very complex or difficult to understand test description. But if it is 3 different test cases, you just edit the relevant one or add another one in case of a Type C dispenser.

Since the coin dispenser is common for all, you can copy the same test cases or even better, link the Excel sheet. In that way any changes to the test script would be readily reflected in the other two test cases too. Yes, when you get the test management system, it would be easier.

Hope this helps,

Krish; ▶ Reply to This

Permalink Reply by Dan Parkins on January 20, 2010 at 2:50am: Why does this sound like a classic classroom exercise :-)?
I think we need to step back and determine how many variables you are working with and how many valid scenarios can be generated. I find that the use of decision tables is an excellent way of determining how many valid and unique scenarios are possible. But that's probably another topic for another day.

Since your test cases would be derived from your scenarios, that's how you figure out how many test cases are appropriate to test your business problem. You should always end up with more test cases than scenarios; otherwise your test cases are much too complex.

In short, if you're worried about missing an important test case or two, then do a little research on the use of decision tables and try to apply what you learn to this problem.

This may sound a bit too abstract at first, but it will pay dividends later. The fact that you're unsure about the number of test cases (which is a good check for completeness on your part), indicates that you're on the right quality path.

Hope this wasn't too confusing.

Cheers

-Dan; ▶ Reply to This

Permalink Reply by Michael Persson on January 20, 2010 at 7:59am: Thanks for the reply. I don't have much knowledge in decision tables, so I will look it up right away, to see if I have some use for it!; ▶ Reply to This

Permalink Reply by Howard Fine on January 23, 2010 at 8:20pm: If you want to play around with Decision Tables, I find that LogicGem is a cool and easy decision table processor to use. You can download a free fully functional evaluation copy from the publisher here:

http://www.catalyst.com/products/logicgem/index.html

I've used it for years and love it.

Cheers,

Howard Fine
Director of IT
Ben Tobin Companies; ▶ Reply to This