You know this joke, right? A tester walks into a bar and orders a beer. Then he orders ten beers, negative one beer, and so on. There are many variations.
Based on the joke, let’s do an exercise to build test cases for each scenario. It will put your testing techniques through their paces, and it will be fun!
Black Box Techniques
Let’s start building the test cases using the techniques listed in Foundations of Software Testing, many people’s first book for studying software testing.
To write a reasonable number of tests, we have to assume we can order only positive integer numbers of beers, so ordering π beers is out of the question, as is negative one beer. Furthermore, let’s assume we can order only a single type of beer—let’s say a brown one. You can see what testers have to create all the time: assumptions.
The first test cases will be easy, using equivalence partitioning. The only valid partition is a range of integers, starting from one beer. But what’s the upper limit of this range? Theoretically, it can be infinite, because there are no rules printed on the wall of any bar stating how many beers you can order. Still, we have to consider real-life restrictions, like how many beers can a bar store and what’s the highest number of beers a group of friends would order at the same time. Based on this reasoning, I think a dozen would be a pretty good upper limit of the valid equivalence partition.
The chapter about partitions ends here. In practice, though, I usually add a value from somewhere in the middle of the valid partition, just to be get a mid-range test in. And hey, it’s beer, right? So we should definitely order three beers, as well.
It’s easy to calculate the boundary values to these partitions, having the limits of the equivalence classes: zero beers for the maximum of the lower invalid partition, and one beer for the minimum of the valid partition. Similarly, twelve and thirteen will be the values for the other end of the valid partition.
Rules in a decision table can help decide whether the customer can be served. Check a simple decision table containing age and drunkenness as parameters:
You can test the beer ordering process with state-transition diagrams:
The first route on a diagram like this would be the “happy path,” i.e., ordering a beer and paying for it with your credit card. Next, write test cases for when there’s not enough credit on your card so you have to pay with cash, or trying to leave without paying.
With diagrams like this, you can also build a test set to test the integration of the infrastructure. System modules like the payment service or the cash register can be involved, as can the liquor storage system.
Next, let’s consider some use cases, based on the roles people can play in this bar when ordering a beer. The most common one will be a normal customer who just wants a few beers. The expected result will be different if the owner of the bar steps in and orders; presumably, he won’t have to pay for his drink.
White Box Techniques
Let’s assume you were there when the beer tap was put together, and you have a very precise layout of the whole structure. To test that the beer tap is working properly, ask the bartender for a beer without any head, then order one with thick head. Also, test the first portion of beer in the morning, to see whether the bartender cleaned the tubes of the tap as they should.
Localization, Exploratory, and Load Testing
To test the localization, we’ll need to ask for a beer in a couple of different languages. Again, let’s assume the bar is in the US, so the bartender should understand English and maybe a little Spanish, at least. To expand the testing of this input, the tester should ask for a “asdfghj” and evaluate the result. Other negative test cases will be “pivo” and “sör” ─ while they mean beer in Czech and Hungarian, respectively, we do not expect a bartender in the US to know these translations.
Here comes my favorite: Let’s plan some time for exploratory testing of the system! For my own rule of thumb, I usually set up a third of the testing time I have available for exploratory testing. Let’s not specify any script here; I’ll leave it to your creativity to choose between your favorite exploratory methods, be it reverse order of test case execution, switching the steps in the workflow, or anything else.
It would be useful to have a stable beer ordering system working 24/7, so let’s plan a load test, too. If you invite your friends over and order beers again and again, you can get a simple load test running on parallel threads.
Collect the Test Cases
Having all the tests planned, let’s collect and group the cases. Merging and structuring them can save some time during execution.
This gives us a dozen test cases or so. Remember, they differ in length and difficulty, so be careful planning execution time and cost. Still, it seems to be a pretty good test suite to test the beer-ordering process in a bar.
Go ahead and use it to explain various test techniques. Just make sure you buy me a beer when I visit town.
Another underlying assumption, or possibly localisation issue: you are in the US. In the UK the lower age range is 18. In other countries it may be different again.
Although I'm living in Hungary, Europe, I've set up this test suite in the U.S. Thanks for adding this case!
I like the way you have come up with scenarios, simple and easy to understand. Thank you!
Have you considered to expand these scenarios or come up with a new base story around other aspects of testing (e.g. security testing)? I think it would worth to present them this way.
With these techniques one can generate dozens of test cases. Can we foretell somehow that any of them has more value (e.g. is able to catch a more serious bug) than other?
About sizing/prioritizing the test cases: I would definitely start with the "happy path" cases from each technique, then go on with the most complex cases. This way you can use the Pareto rule: 20% most important cases could cover the 80% usage of the system.
A friend of mine already mentioned the lack of security testing in this hypothetical scenario, also a deep load testing of the services of the bartender. This clearly demonstrates the principle of "Exhaustive testing is not possible"...
The state diagram is a bit incorrect, It should start with " does the bartender knows you and are you over 18 / 21. This step should not be after serving :)
The age verification should definitely happen before serving the drinks. The "Show ID" step suggests the bartender registers your data for later legal actions, if you don't have any money and don't pay your bill later. This way, you don't have to stay in the bar washing the dishes in the night :)
Sober customer is under 21 but is accompanied by a parent, guardian, or spouse who is over 21 and the owner allows serving under this condition. Serve the customer.
Sober customer is under 21 but is accompanied by a parent, guardian, or spouse who is over 21 and the owner disallows serving under this condition. Do not serve the customer.
These apply in the state of Wisconsin.
When my son was 19, we found out just how much the understanding of these varied between establishements. Some would serve, some would not serve, some would tell you they abided by the law and just refused to believe what the law actually said.
Interesting corner case, thank you for sharing!