Nowadays, testing is one of the basic elements of any software program development. It doesn’t matter what methodology you’re using software testing is an integral part of web product development.
In recent years, testing has become a separate field that is constantly changed and improved.
Further, we will talk about a manual tester’s work and how he/she should deal with the basics of test design.
The Concept of Test Design and Problems of Its Usage
A lot of specialists from this field heard about such a concept as test design. But a few use these methodologies of software testing in their daily working life.
You can wonder why this is so. Indeed, test design techniques are a basic component of test scenario development (it’s like a traffic code in driver’s education). So why do testers rarely use this knowledge in their work?
It’s simple! When future tester attends specialized courses, he/she studies how to practically use test design techniques with simple examples. And the main disadvantage of such education is that testers cannot apply all this knowledge on real projects. In other words, they don’t have an opportunity to use test design techniques daily.
Also, we can note that this process is maximally formalized and it seems like a tester must formalize completely everything in his/her work. Usually, no one needs these things and, besides, there is always no time for that.
Now we can proceed with the basic concept, namely what is test design. So, test design is a set of rules and strategies that allows correctly using the requirements list for software testing.
But the most important thing is to correctly and intuitively implement these rules. That is the ability to analyze accurately that differs a good tester from an ordinary one!
Basic tasks of any test design are:
- Analysis of requirements and risks;
- Ability to set main checks for testing;
- Basics of test formalization in a test scenario type;
- Ability to prioritize tests;
- Analytics of approaches to the testing process.
Realization of Test Design Techniques on Practice
Let’s start with the two most common techniques that are well-known for all testers who use them intuitively. We are talking about equivalence classes and requirements.
In our case, of the most interest are equivalence classes. Further, we will talk about them.
An equivalence class is a special set of software value parameters that are processed by a program by one algorithm or lead to one desired result.
In simple words, this is some special value that can be processed by a program and can give the same result. Such a result can be not only particular definitions and parameters of the program but a field of use.
It means that the simplest equivalent classes that tests can be divided into are positive and negative scenarios. Any project always has it. Every tester divides all his/her tests into these classes. But, unfortunately, not everyone knows why he/she does it.
The answer is simple – the equivalent classes. Any equivalent class can be divided into helper classes until the test leads to accurate and specific test results.
Let’s Take a Look at an Example
We have to test a system of scoring of interest rate on credit depending on the client’s age.
There are such data from customers:
- From 18 to 25 y.o. – 18%;
- From 25 to 45 y.o. – 16%;
- Over the age of 45 – 20%.
Our task is to identify 2 basic equivalent classes – negative and positive test scenarios.
Positive scenarios will be all values that lead to the specified result. Negative scenarios will be values which results aren’t described as expected ones.
Then, we can divide the class of positive scenarios into 3 helper classes by input values 18 – 24, 25-44, and over 45.
In the class of negative results, we can create a value based on a need to test the software failures. Hence, we have 0,1-17 – a negative value and input of incorrect characters.
The result of such decomposition will be a value or range of some values where you need to perform only one test with a random value from a data span. It may happen that there is only one value in a range. This is an equivalent class too. And this also needs to be tested.
In the end, we have such groups of tests:
- Positive tests – values of 19, 30, 48 (there can be any numbers from that range of class);
- Negative scenarios – 0, 3, a value with a minus.
It is significantly important that all test design techniques aren’t used independently of others! Moreover, there are three levels of using the test design techniques while preparing for the testing:
- Basic level – system element testing;
- The second level – testing the performance of system logic;
- The third level – testing the business processes of a system and logic of software functioning.
This can be visually displayed as follows:
To sum up, we’d like to say that test design techniques can cover only some part of software tests. Namely, they can show the correctness or incorrectness of system parts performance and results of their combinations during the functioning.
Test design is a very important part of any manual testing since QA specialists test exactly this thing in their daily working life.