Translation of Hans Buvald’s article “Basic Test Design Principles”

The guys from Luxoft Training prepared a translation of an article about test design from one of the first developers of the key testing and automation methodology that is popular today, based on keywords - Hans Buvald.

For his professional career, Hans Buwalda (Hans Buwalda) has gained vast experience as a software developer, manager and chief consultant at leading companies and organizations in different countries of the world. His proposed testing methods (action-based and soap opera-like) have helped many customers develop scalable and easily supported solutions for a large number of complex test tasks. Hans often speaks at international conferences. He also co-authored the book Integrated Test Design and Automation .

Successful software testing primarily depends on test design. High-quality test design not only provides good coverage, but also improves test efficiency. Test design should be based on the principle of “compactness and efficiency”, and the amount of testing should be easily manageable and at the same time sufficient to detect errors before the release of the system or update it.

Test design is the most important factor determining successful test automation, although this is not so obvious. I used to think that successful automation depends on high-quality programming or on “buying the right tool.” It took years of work to understand: test design - the main driver of successful automation.
')
There are three main goals to strive for in designing tests, as in the legend of King Arthur and the Knights of the Round Table, “The Three Holy Grails of Test Design”, we face enormous difficulties, as is the case with the search for the Holy Grail by the knights of King Arthur . So, in this article I will introduce three “grails” that need to be found when designing tests.

The terminology used in this article is based on an Action Based Testing (ABT) methodology used by LogiGear to test and automate testing. More information about the ABT methodology can be found on the LogiGear website.

In ABT, test scripts are grouped into tables called test modules. In them, tests are described as sequences of “test lines”, each of which begins in column A with some kind of “action”, while the other columns contain arguments. ABT does not focus on automating test scenarios, but automating individual actions that can be reused when necessary.

Three test design goals

There are three major objectives of the design tests.

1. Effective test decomposition

The first step is to break down the tests into well-managed parts, which in ABT are called test modules. At this stage, we do not yet describe test scenarios, but simply designate “chapters” in which they should be included. Such a breakdown is effective if each test module received has clearly defined and oriented content that is different from other modules. The content of the test module further determines what the test scripts included in it should be.

2. The right approach for each test module

After the test breakdown is completed, each individual test module becomes a kind of mini-project. Based on the content of the test module, it is necessary to determine which approach will be used for its development. The approach refers to the definition of a set of test methods used to create test scenarios (for example, analysis of boundary values, decision tables, etc.), as well as a circle of people involved in the creation and / or evaluation of tests. For example, in the case of a test module for testing the calculation of premiums on insurance policies, the participation of employees of the insurance department may be required.

3. The correct level of test details

From the achievement of the third goal depends largely on the ability to support automated tests.
When creating a test scenario, you need to select only those high-level elements that are relevant to this test. For example, from the end user's point of view, “logging in” or “changing the customer’s phone number” is one action; therefore, it is not necessary to specify any elements of a lower level in the test scenario, for example, pressing a button and entering data. At this stage, these low-level elements should be “hidden” in separate, reusable, automated functions common to all tests. Due to this, the tests become more compact and readable, but the main thing is that they can be maintained, since there is no need to change one low level elements in each individual test in the case when changes are made to the base system. After that, low-level items can be re-specified (or the order of their automation can be revised) only once, so that they can be reused in all tests.

In the ABT methodology, this (third) principle is manifested at the “level” of actions that are supposed to be used in the test module.
For example, for an insurance company database, we can write tests using only “high level” actions, such as “create a policy” and “check premium”, and to test the dialogue, you can use “low level” actions (for example, “press a button” ) to test pressing the “OK” button.

Conclusion

Regardless of the chosen methodology, if you spend some time thinking about the design of the tests before writing the first test script, then in the future this will significantly improve the quality and effectiveness of the tests.

November 22, Hans Buvalda arrives in Moscow with a master class " Five key factors for successful test automation ."

More articles from Hans Boovalda can be found here .