“Can you list at least 2 test cases for testing a blank sheet of paper?” – This was a question listed on another LinkedIn discussion. There are over 80 comments (so far) that appear to be split right down the middle.
Half of the commentor’s automatically started to list out various test cases… (Some of them rather bizarre and unjustified):
- “Check that it is blank”,
- “Check that it is paper”,
- “Check the colour”,
- “Test that you can write on it”, and even
- “Check that its glossy”
- etc
I mentioned that some of these tests are “unjustified”, simply because they are based on massive assumptions about the customer’s need for the blank paper.
I have the opinion that you need to ask more questions before committing to any test cases. You might think: “you can check that the ‘paper is blank’ and ‘that it is paper'”… But can you really?!? How do you know what “blank” actually means to the customer? How do you know what “paper” means to the customer?
What I mean by this, is that “blank” could mean that the paper should have nothing on it, but it could also potentially be branded letterhead paper, with the company’s logo on it, but should simply have no printed text on it. And “paper” could mean a plain sheet of copy paper, or it could really mean tracing paper, or wrapping tissue, or wallpaper, etc.
How can we test that the “blank paper” is “blank” and that it’s “paper” if we don’t know what the customer’s requirements are for the blank paper actually are?
The only way to supply suitably accurate test cases in this instance is by investigating more about the product and its purpose. You firstly need to determine what the paper will be used for, e.g.:
- Is the blank paper going to be used in a printer to print on?
- Is it blank paper that will be folded up and used as a door stopper or to cure a wobbly table?
- Is it blank paper that someone will write on with a pen?
- Is it blank paper that will be used as toilet paper?
- Or is it blank edible sugar paper that will be used on a fresh batch of cupcakes?
- etc
Only when we know what the customer’s intentions are for a product, will we be able to adequately begin to list appropriate basic test cases for the product. I say “basic” as you will not be able to list ALL possible test cases… This is because you do not know what the customer’s expectations are of the product that they need. Knowing what the product is going to be used for will allow us to stem more questions in order to learn more about the expectations that the customer has of the product, e.g.:
- Does the toilet paper have to be of a certain thickness or have a pattern on it?
- Should the sugar paper need to have any specific flavour such as vanilla?
- Should the printer paper be glossy or matt, and of a certain thickness?
- Does the paper to be written on need to work with a special type of pen, such as a fountain pen or marker pen?
- Should the blank paper be of a certain colour?
- etc
Once we know more information, with a better understanding of what the product should be/do, then we can then supply accurate and suitable test cases.
And with a question such as: “list test cases for blank paper”, the best way to gain the knowledge needed of the product in order to be able to create suitable test cases is to ask questions.
Dan Ashby 
Great blog post, seem to remember Michael Bolton and James Bach pounding on testers to learn to ask these types of questions during their RST-course.
Although a tester also have to be careful as to not ask indefinitely so they become known as the tester who doesn’t test until they have “all the requirements and inputs”.
LikeLike
One way to get around the problem from the main post is to relax on the notion of test cases, and start thinking more in terms of “how would you test this”? I’m growing to believe that test cases as commonly construed are a kind of formal mechanism: specific things that you want checked, or checks that should be performed in a specific way. But the formal is always rooted in the informal. To get to the formal test cases, you need to do a fair amount of informal testing–and maybe that informal testing will suffice for the mission.
To get around the problem posed by Kristoffer: start with the question, “Is it okay if I ask you questions? And if so, can I get help from you in making sure I don’t ask you too many questions for your purposes?”
LikeLike
Also let’s remember, asking questions is testing.
Not important if the questions are towards the SW, the customer, the devs and so on.
By asking questions we are in effect testing.
LikeLike
Yes, thats a good point! Testing is asking questions.
But I dont think we can we ask questions of the SW before we have asked questions to the customer to discover what the software should be doing. Can we? (I know /technically/ we can, but it doesnt seem very lean to me to do that).
LikeLike
I agree with thinking more along the lines of “how would you test this”, but the problem with test cases is that some customers request that the documentation be created. I’ve managed to get round this somewhat by discovering if it’s just evidence of testing that they are looking for, which I can supply mind maps and testing notes for. But some of them still want test cases in case they need to repeat the tests at a further date.
LikeLike
There’s another debate to be had as to whether the tests are really repeatable, and how much they’d need to know to perform what is necessary to repeat everything that is important to what the test is supposed to find.
LikeLike
I agree.
I think my first question would be “who are you and what am I doing here?”. After that I need to know what the client needs to know about their product and why.. I need to understand the product, and the aim of the company (basically the context). When I know enough about that (the “why”) I can make my own decisions on the answer to the test case question posed above, and more importantly how to test.
I think the split in answering this question comes in the motives of the person answering. The academic answers, which we could spit out at a rate of knots (“check that it is blank”, etc) and the practical answers which are of some actual use to someone who matters (your blog post). If we’re being academic AND pedantic then the answer to the question is “Yes, I can.”
LikeLike