The triangle problem is a classic puzzle which was first presented in Glenford Meyer’s The Art of Software Testing in 1979. It is a topic which comes up in most testing books and is used in job interviews for testers. I’ll present it in the form I first encountered it:
A program reads three integer input numbers that represent the lengths of the sides of a triangle. Based on these three input values, the program determines whether the triangle is scalene, isosceles or equilateral. The program displays the result on the screen.
You are asked to test such a program. We will assume we do not have access to the source code of the program (testing will be done in a black box manner). Sounds pretty simple, right? Before reading further, please take a few moments and think of how you would test it.
As you have probably noticed, I have highlighted a few words in the statement. The first step to solving a problem is to have a good understanding of what information we have available and what is expected. I suppose that you already know what a scalene, isosceles or equilateral triangle is.
Most common tests
Let’s start with a “happy path” approach (this is what most people get right and it is usually the first test step) – you input three values (a, b, c) and have the following cases:
- If the numbers are all different (a!=b!=c), the expected output would be a scalene triangle
- If two of the numbers are equal and the third one is different (a=b!=c) we should get an isosceles triangle
- If all three values are equal (a=b=c) the triangle will be equilateral
- Variations on the above; for example for the isosceles you have a=c!=b (a lot of papers cover this in the form of decision tables)
From the above cases we can easily identify some interesting cases:
- What happens when all three values will be “0” ? Will that be equilateral? well, without the proper checks in the code, we might see that displayed as the result
- How about when one value is “0” ? Can we form an isosceles triangle with a side of length 0 ?
- What is the behavior for negative values?
Usually this is where most people run out of ideas, but we still have a lot to cover. Let’s go through the highlighted words.
Getting a better understanding of the problem
Reads: how does the program actually read the values? Are you presented with a window that just waits for you to type “1 2 3” and hit enter? Do you have to input them separately (input 1, hit enter, input 2 hit enter)? This is certainly an area that must be clarified, as there is room for interpretation.
Three: what is assuring us we can only read three values? Depending on the question raised earlier, we might be able to write more than 3 values in our program.
Integer: again, what is the filtering that’s performed to make sure we are only allowed integer values. The problem is sometimes stated without this constraint (that is also the original form). Also, remember that variables usually have a min/max value which they can store.
Using the above, we have a decent amount of directions in which we can expand our tests:
- Try inputting 4 or more values (vary this with valid cases – for example three equal values but a fourth random value)
- Unfiltered type inputs. Characters, characters combined with numbers, floating values etc
- Maximum value for integer. You don’t have to remember the value, you can always google it. What happens at max-1/max/max+1
Back to basics
Now, the real ninjas of testing will have spotted a critical condition by now. “Wait a minute …” they will say “.. not every three values can form a triangle !!”. And they are right. Imagine you have a side of 10 cm and two sides of 1cm each. Will that form an isosceles triangle? Not really, as the lines do not meet. So there must be some condition, right? Well those of you that like geometry might know the rule, however a lot of people (myself included) do not.
We would proceed by going through ancient scrolls and theorems to uncover the mysteries of the triangles. By performing a quick search on wikipedia on triangles, we will come across a condition of existence which states that:
sum of the lengths of any two sides of a triangle must be greater than or equal to the length of the third side. That sum can equal the length of the third side only in the case of a degenerate triangle, one with collinear vertices
More reading can be done on degenerate triangles but we ill pretend they do not exist for this post. This does not mean that the condition must not be clarified.
So we have a pretty critical condition, which, in my opinion, should actually be one of our first checks: a+b>c (ignoring the equal condition and of course variations on the sums). A lot of the tests mentioned above can be repeated with this new condition in mind.
We are starting to have a more robust coverage on the program. Some other various areas that can be checked are:
- Error handling
- Further messing around with the inputs (null values, spaces and/or characters before/after the values)
- A long input (over max int length)
And if you want to get technical:
- Performance (how long do we have to wait before the output is displayed)
- Testing with full memory
The last tests are pretty general, and we can apply them to almost every software.
I won’t say this is an exhaustive list of tests that can be performed, but I hope that you understood what the idea behind the problem actually is: even the simplest of questions can have a lot of hidden information which can be exploited.
Let me know of some ideas that you have for this.
Dmehra (content creator for tester’s digest) has pointed out an interesting area for this problem. The specification needs some clarifications. An equilateral triangle also counts as an isosceles one. Therefore, we should know if we are expecting a single output or two if all sides are equal.