The Triangle Test Exercise

In this exercise, you get your first chance to build a test case. Even if you think of yourself as an experienced tester, you might want to give it a try. It’s amazing how few people — even people who have been testing for years — get this exercise right.

Exercise: The Triangle Test

Suppose you’re told to test a very simple program. This program accepts three integers as inputs or arguments. These integers represent the lengths of a triangle’s sides. The program prints “Equilateral” (three equal sides), “Isosceles” (two equal sides), or “Scalene” (no equal sides), as shown in the below Figure


Three types of triangles

Your assignment is to write an effective and efficient set of test cases. By effective, I mean that the set of tests finds common bugs. By efficient, I mean that the set of tests finds those bugs with a reasonable amount of effort. By test case, I mean tester action, data, and expected result. Here the action is usually to input some data, but it might be other actions as well.

A template is provided for your solution. I suggest you format your solution to look the same as the template. I suggest 30 minutes as a time limit. When you’re done, continue through the rest of this chapter to see my answers.

Author’s Triangle Test Solution

This exercise is a famous one, found in the first book on software testing, Glenford Myers’s The Art of Software Testing. In it, Myers gives this seemingly trivial example and then shows many possible solutions to it.

To come up with my solution, shown in the below Table, I used a combination of equivalence partitioning and boundary value analysis. We have already seen both equivalence partitioning and boundary value analysis defined in my earlier posts.



My solution focuses on testing functionality and the user interface only. There may be other risks to the system quality that might concern you which can be discussed at a later stages.

Note that my solution is only one of a large set of possible correct answers. Some generic rules for determining a good set of tests are found in Myers’s book, and you’ll look at those rules later in this book. Myers also provides solutions for this exercise. Because he wrote his book in the days of greenscreen mainframe programs, he did not have to cover some of the user interface tests that are included in my solution.

So, how did you do? What did my solution test that you didn’t? What did you test that my solution didn’t?

If you missed a few of these, don’t feel bad. If you keep practicing you will find more and more scenarios and the way you look at the application you are testing will also change.

Doing test design and implementation without reference materials often leads to gaps in testing. Doing test design and implementation under the tight, often stressful time constraints that exist during the test execution makes such gaps even more likely, even for experienced testers. This underscores the need for careful analysis, design, and implementation of tests up front, which can be combined during test execution with reactive techniques to find even more bugs.

Here are number of additional questions one would want to be addressed by the tests: “Did you worry about order dependence in the input values? Maybe it reacts differently to a negative number if it’s in the first position versus the second position versus the third position versus all positions. Maybe we could check the requirements. Did you worry about certain special characters being allowed or disallowed? What if it correctly recognizes that a ‘*’ is a special character but thinks a ‘/’ is acceptable? Did you test for all possible special characters, in all positions? Capital letters? Zeros? Nulls?” The possibilities are really almost endless, aren’t they? Risk analysis helps us recognize when we’ve covered enough.