Key Principles of Test Design

By Hans Buwalda, CTO, LogiGear Corporation

Introduction

Test design is the single biggest contributor to success in software testing. Not only can good test design result in good coverage, it is also a major contributor to efficiency. The principle of test design should be "lean and mean." The tests should be of a manageable size, and at the same time complete and aggressive enough to find bugs before a system or system update is released.

Test design is also a major factor for success in test automation. This is not that intuitive. Like many others, I initially also thought that successful automation is an issue of good programming or even "buying the right tool". That test design turns out to be a main driver for automation success is something that I had to learn over the years, often the hard way.

What I have found is that there are three main goals that need to be achieved in test design. I like to characterize them as the "Three Holy Grails of Test Design", a metaphor based on the stories of King Arthur and the Round Table. Each of the three goals is hard to reach, just like it was hard for the knights of King Arthur to find the Holy Grail. This article will introduce the three "grails" to look for in test design. In subsequent articles in this article series I go into more detail about each of the goals.

The terminology in this article and the three follow up articles is based on Action Based Testing (ABT), LogiGear's method for testing and test automation. You can read more about the ABT methodology on the LogiGear web site. In ABT test cases are organized into spreadsheets which are called "test modules". Within the test modules the tests are described as a sequences of "test lines", each starting in the A column with an "action", while the other columns contain arguments. The automation in ABT does not focus on automating test cases, but on automating individual actions, which can be re-used as often as necessary.

The Three Goals for Test Design

The three most important goals for test design are:

  1. Effective breakdown of the tests
    The first step is to breakdown the tests into manageable pieces, which in ABT we call "test modules". At this point in the process we are not yet describing test cases; we simply identify the "chapters" into which test cases will fall. A break down is good if each of the resulting test modules has a clearly defined and well-focused scope, which is differentiated from the other modules. The scope of a test module subsequently determines what its test cases should look like.
  2. Right approach per test module
    Once the break down is done each individual test module becomes a mini-project. Based on the scope of a test module we need to determine what approach to take to develop the test module. By approach I mean the choice of testing techniques used to build the test cases (like boundary analysis, decision tables, etc), and who should get involved to create and/or assess the tests. For example, a test module aimed at testing the premium calculation of insurance policies might need the involvement of an actuarial department.
  3. Right level of test specification
    This third goal is where you can win or lose most of the maintainability of automated tests. When creating a test case try to specify those, and only those, high-level details that are relevant for the test. For example, from the end-user perspective "login" or "change customer phone number" is one action; it is not necessary to specify any low-level details such as clicks and inputs. These low-level details should be "hidden" at this time in separate, reusable automation functions common to all tests. This makes a test more concise and readable, but most of all it helps maintain the test since low-level details left out will not have to be changed one-by-one in every single test if the underlying system undergoes changes. The low-level details can then be re-specified (or have their automation revised) only once and reused many times in all tests.
    In ABT this third principle is visible in the "level" of the actions to be used in a test module. For example, in an insurance company database, we would write tests using only "high-level" actions like "create policy" and "check premium", while in a test of a dialog you could use a "low level" action like "click" to see if you can click the OK button.

Conclusion

Regardless of the method you choose, simply spending some time thinking about good test design before writing the first test case will have a very high payback down the line, both in the quality and the efficiency of the tests.

Additional Articles in this Series

Subsequent articles in this series will explore each of these goals in greater detail.

Other Recent Articles by This Author

Download free articles, white papers, templates and more!