In software quality, we talk about metrics like bugs, automating tests and code coverage etc. These are all important, but there is one topic that makes the whole difference and it is not quite measurable, it is choosing a test design technique to test the feature.
It seems a bit abstract, but let’s try to think about in a more common way. Suppose that you will create a software as a developer. You will analyze the requirement and decide on a “design pattern” that you will use based on the usage of the software, maintainability etc. The common design patterns will provide you some guidance.
It is same with the test design techniques. Sometimes you cannot just take one and use it directly. You will have to mix and match. But it is basically providing a guidance for a tester on how to approach to a testing of a feature. Because we cannot test “everything” since we do not have unlimited time, we need to find an optimum way to approach to quality verification of a feature.
There are so many test design techniques, but let’s mention the most common ones in this article.
- Boundary Value Analysis
Boundary value analysis is based on testing at the boundaries between partitions. It includes maximum, minimum, inside or outside boundaries, typical values and error values. Consider this example of testing a login functionality with boundary value analysis:
Suppose that username can only be 10 characters long.
So you can write test cases that include:
Username: 1 character, 10 characters, empty, 11 characters
So instead of writing test cases for, say 1 character, 2 characters, 3, 4 etc, you cover all of these with the boundary value analysis
2. Decision Table
Also called cause-effect table, it helps to test applications where the action is basis of multiple input combinations, which is usually the case. It also helps understand the business logic of the application. Think about the above example of logging in. We can prepare a small decision table for testing it:
Which can be base for test cases like:
Test Case 1: Username and password is incorrect. Error message is shown, login not allowed
Test Case 2: Username correct, password is wrong. Error message is shown, login not allowed.
Test Case 3: Username wrong, password correct. Error message is shown, login not allowed.
Test Case 4: Username and password is correct, login is allowed.
This decision table is similar with traceability matrix that is used for testing.
3. State Transition
In this technique, the behavior of an application is analyzed for different input conditions in a sequence. Both positive and negative input test values and record the system behavior. Think about this simple diagram for login case:
This diagram makes easier to understand what are the inputs and outputs and what will be the behavior of the system according to the inputs.
4. Error Guessing (the good old basic one)
This is a simple technique that explains itself in its name, errors are predicted where they are likely to appear, relying on previous experience, knowledge of the system, and product requirements. Test engineer is to identify spots where defects tend to accumulate and pay increased attention to those areas. This is usually used among with the other techniques. It is an experimental type of testing. Some examples for the login functionality are:
User will enter an invalid username and password, then click to login and click refresh immediately
User will click login button repeatedly, this can break the system
User will enter special characters in their language (such as Hebrew, Arabic characters)
etc.
Summary
The techniques mentioned above are just tip of the iceberg, just to give you an idea of the concept. Overall, testing techniques will only guide you on how to approach a feature for testing. In time, an experienced test engineer will use these techniques innately, but feel free to use in any time if you run out of ideas.
Happy testing!