Translation of an article by Hans Boowaldy “Fundamentals of Test Design”
- Transfer
The guys from Luxoft Training prepared a translation of an article on test design from one of the first developers of today's popular keyword-based testing and automation methodology, Hans Boowaldy.
Hans Buwalda during his professional career has gained vast experience as a software developer, manager and chief consultant in leading companies and organizations around the world. The testing methods he proposed (based on actions and in the style of a soap opera) helped many customers develop scalable and easily supported solutions for a large volume of complex testing tasks. Hans often serves as a speaker at international conferences. He is also a co-author of Integrated Test Design and Automation .
Successful software testing primarily depends on test design. A high-quality test design not only provides good coverage, but also increases the effectiveness of testing. The design of the tests 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 system is released or updated.
Test design is a critical determinant of successful test automation, although this is not so obvious. I used to think that successful automation depends on good programming or on “buying the right tool.” It took years of work to understand: test design is the main driver of successful automation.
There are three main goals that you need 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”, one has to face enormous difficulties, as in the case of the search for the Holy Grail by knights of King Arthur . So, in this article I will introduce three “grails” that you need to find when designing tests.
The terminology used in this article is based on the Action Based Testing (ABT) methodology used by LogiGear to test and automate testing. More information on the ABT methodology can be found on the LogiGear website.
In the ABT methodology, test cases 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”, and the other columns contain arguments. ABT focuses not on automation of test cases, but on automation of individual actions that can be reused when necessary.
Three main goals of test design can be distinguished.
The first step is to break up the tests into well-managed parts, which are called test modules in ABT. At this stage, we do not yet describe the test scenarios, but simply indicate the “chapters” in which they should be included. Such a breakdown is effective if each test module received has a clearly defined and oriented content that is different from other modules. The content of the test module further determines what the test scripts should be included in it.
After the test breakdown is completed, each individual test module becomes a kind of miniproject. Based on the content of the test module, it is necessary to determine which approach will be used for its development. By approach is meant the definition of a set of testing methods used to create test scenarios (for example, analysis of boundary values, decision tables, etc.), as well as the circle of people involved in the creation and / or evaluation of tests. For example, in the case of a test module, testing the calculation of premiums on insurance policies may require the participation of employees of the insurance department.
The ability to support automated tests largely depends on the achievement of the third goal.
When creating a test scenario, you need to select only those high-level elements that are relevant to this test. For example, from the point of view of the end user, “sign in” or “change the client’s phone number” is one action; therefore, there is no need to specify any lower-level elements in the test script, 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. Thanks to this, the tests become more compact and readable, but the main thing is that they can be accompanied, since there is no need to change one low-level element in each individual test in case changes are made to the base system.
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 the insurance company’s database, we can write tests using only “high-level” actions, such as “create a policy” and “check premium”, and for testing the dialogue, you can use “low-level” actions (for example, “click a button” ) to test the OK button.
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 increase the quality and effectiveness of the tests.
On November 22, Hans Bouvalda arrives in Moscow with a master class " Five Key Factors for Successful Test Automation ."
More articles from Hans Boowaldy can be found here .
Hans Buwalda during his professional career has gained vast experience as a software developer, manager and chief consultant in leading companies and organizations around the world. The testing methods he proposed (based on actions and in the style of a soap opera) helped many customers develop scalable and easily supported solutions for a large volume of complex testing tasks. Hans often serves as a speaker at international conferences. He is also a co-author of Integrated Test Design and Automation .Successful software testing primarily depends on test design. A high-quality test design not only provides good coverage, but also increases the effectiveness of testing. The design of the tests 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 system is released or updated.
Test design is a critical determinant of successful test automation, although this is not so obvious. I used to think that successful automation depends on good programming or on “buying the right tool.” It took years of work to understand: test design is the main driver of successful automation.
There are three main goals that you need 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”, one has to face enormous difficulties, as in the case of the search for the Holy Grail by knights of King Arthur . So, in this article I will introduce three “grails” that you need to find when designing tests.
The terminology used in this article is based on the Action Based Testing (ABT) methodology used by LogiGear to test and automate testing. More information on the ABT methodology can be found on the LogiGear website.
In the ABT methodology, test cases 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”, and the other columns contain arguments. ABT focuses not on automation of test cases, but on automation of individual actions that can be reused when necessary.
Three test design goals
Three main goals of test design can be distinguished.
1. Effective test decomposition
The first step is to break up the tests into well-managed parts, which are called test modules in ABT. At this stage, we do not yet describe the test scenarios, but simply indicate the “chapters” in which they should be included. Such a breakdown is effective if each test module received has a clearly defined and oriented content that is different from other modules. The content of the test module further determines what the test scripts should be included in it.
2. The right approach for each test module
After the test breakdown is completed, each individual test module becomes a kind of miniproject. Based on the content of the test module, it is necessary to determine which approach will be used for its development. By approach is meant the definition of a set of testing methods used to create test scenarios (for example, analysis of boundary values, decision tables, etc.), as well as the circle of people involved in the creation and / or evaluation of tests. For example, in the case of a test module, testing the calculation of premiums on insurance policies may require the participation of employees of the insurance department.
3. The correct level of detail tests
The ability to support automated tests largely depends on the achievement of the third goal.
When creating a test scenario, you need to select only those high-level elements that are relevant to this test. For example, from the point of view of the end user, “sign in” or “change the client’s phone number” is one action; therefore, there is no need to specify any lower-level elements in the test script, 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. Thanks to this, the tests become more compact and readable, but the main thing is that they can be accompanied, since there is no need to change one low-level element in each individual test in case changes are made to the base system.
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 the insurance company’s database, we can write tests using only “high-level” actions, such as “create a policy” and “check premium”, and for testing the dialogue, you can use “low-level” actions (for example, “click a button” ) to test 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 increase the quality and effectiveness of the tests.
On November 22, Hans Bouvalda arrives in Moscow with a master class " Five Key Factors for Successful Test Automation ."
More articles from Hans Boowaldy can be found here .