A Tester Walks into a Bar: Reviewing Test Techniques

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.