Test design techniques for dummies

Greetings to all current and future testers! My name is Halyna Zakharova and I work as a QA Engineer at Customertimes IT company. You may have already read my articles on DOU about how I was looking for a job in IT and how my first year in IT went.

Once I was also a student of courses (almost two years have passed, how time flies!), then I worked as a mentor on a testing course. Both I and the students I mentored had problems with this part of the course. That is why I had the idea to write an article about one of the most difficult topics in the course — test design techniques.

I remember watching certain videos several times to understand some of the techniques. Therefore, I painted the main ones, used most often, giving examples. I hope I can make this topic clearer. You can write in the comments how I succeeded.

For the example in this article, I took a program to calculate a person’s age. All examples are given only to understand test design techniques. If you think I used too little data or made it too simple, that is perfectly fine, because I did not put a lot of different data into context to make it as clear as possible. In practice, everything is more complicated.

Equivalence Partitioning

The Equivalence Partitioning technique is a way of creating test cases that allows you to test a program or system efficiently and economically. Instead of randomly selecting test cases, we divide the possible input data into groups that behave in the same way. These groups can be positive and negative.

Here is an example: imagine you are testing a program to calculate a person’s age based on their date of birth. You know that the program takes the date of birth as input and calculates the age. Instead of creating test cases for each individual date of birth, you apply the Equivalence Partitioning technique.

First, we need to divide the possible dates of birth into groups (let’s take the positive ones):

1. Children’s birth dates (e.g., less than 12 years of age).
2. Adolescent birth dates (e.g., 12 to 18 years of age inclusive).
3. Adult birth dates (e.g., 19 to 60 years of age inclusive).
4. Senior birth dates (e.g., over 60 years of age).

After that, you need to select one or more values from each group and test the program using these figures. This will allow you to check whether the program works correctly for each class of birth dates. If the test passes for one representative from the group, it will most likely work for other values from the same group.

Keep in mind negative scenarios, which are situations where the program must process or report an error due to incorrect or invalid input data. Here are some examples:

1. Inputting an incorrect date: entering a date of birth in an invalid format or with wrong values. For example, entering a date in ‘month/day/year’ format with an invalid day or month number (month 13, February 30, and so on).
2. Dates in the future.
3. Dates in the wrong order: for example, entering the year, then the month, and then the day, instead of the expected year-month-day order.
4. Processing of incorrect characters: checking how the program reacts to invalid characters or letters that are not related to the date of birth.

Using Equivalence Partitioning helps to reduce the number of tests that need to be performed, while effectively testing different scenarios of application use.

Boundary Value Analysis

The Boundary Value Analysis technique helps to find errors at the boundaries of data ranges, or segments. It is aimed at checking the behavior of the program at the minimum and maximum values of the input data, as well as at values that are outside the ranges.

For example, let’s take the same program for calculating age. In the picture, you can see the borders.

1. Lower Boundary: take the smallest value for the date of birth, let’s say January 1, 1930. Enter this date and check if the program calculates the age correctly. The program should get it right.
2. Upper Boundary: now let’s take some largest value for the date of birth. For example, December 31, 2050 (let’s imagine that today is December 31, 2050, let’s live a little in the future). Enter this date and make sure that the program correctly calculated the age.
3. Near the Boundaries: finally, let’s check how the program behaves with dates that are one day before the minimum date and one day after the maximum date. That is, December 31, 1929 (one day before the minimum value) and January 1, 2051 (one day after the maximum value: again imagine that tomorrow is January 1, 2051). Enter these values and make sure that the program rejects them, because everything outside the specified limits is invalid.

This approach helps to detect errors related to the processing of boundary values, because it is often at the boundaries of the ranges that programs can behave incorrectly.

Decision Table Testing

Decision Table Testing is a test design technique that helps you test different combinations of input conditions and program actions to ensure that your test scenarios are fully covered. Let’s take the same age calculation program as an example. For Decision Table Testing, you need to identify all possible conditions and actions that the program can perform.

Now we have all possible combinations of conditions and actions for the program. For example, if you enter a valid date of birth, the program will calculate the age. If you enter an invalid date, the program should display an error message. Depending on the calculated age, the program should display the appropriate messages (person is underage, person is an adult, person is elderly).

Using Decision Table Testing helps to test all possible combinations of conditions and actions, ensuring that the program is fully tested in various scenarios. It also makes sure that the program behaves correctly for different input data or incorrectly if one uses invalid values, such as special characters, for example: !(%#”;), letters, incorrect date format.

State Transition Testing

State Transition Testing is a test design technique that helps to verify the behavior of an application in different states and transitions between them. To test the date of birth using State Transition Testing, we will define the states of the program and the conditions that cause a transition between these states.

States:

1. ‘Initial’ state: when the program is just starting or has not yet received input data (date of birth).
2. 2. ‘Age calculated’ state: when the program has successfully calculated the age after entering the date of birth.
3. ‘Invalid date’ state: when the user has entered an invalid date of birth (for example, February 30).
4. ‘Minor’ state: when the age has been calculated and it was found that the person is underage.
5. ‘Adult’ state: when the age is calculated and the person is considered an adult.
6. ‘Elderly’ state: when the age is calculated and the person is considered elderly.

Transitions:

1. From the ‘Initial’ state, the program switches to the ‘Calculated’ age state if you enter a valid date of birth.
2. From the ‘Initial’ state, the program switches to the ‘Invalid date’ state if you enter an invalid date (for example, February 30).
3. From the ‘Calculated Age’ state, the program switches to the ‘Minor’, ‘Adult’, or ‘Elderly’ state, depending on the calculated age.

Now for State Transition Testing, you need to test each state and the transition between them.

1. Check the ‘Initial’ state by making sure that the program correctly moves to the next state when you enter a valid date of birth.
2. Check the ‘Initial’ state to ensure that the program displays the correct error message if you enter an invalid date of birth.
3. Check the ‘Age calculated’ state, verifying that the program correctly determines the age based on the correct (existing) date of birth.
4. Check the ‘Age calculated’ state to check that the program identifies minors, adults, and seniors with the correct age ranges.
5. Check the ‘Invalid Date’ state to assure that the program correctly displays an invalid date message.

Thus, the use of the State Transition Testing technique helps to detect errors related to transitions between program states and provides comprehensive testing of various scenarios that may arise when working with the date of birth in our case.

Use Case Testing

Use Case Testing is aimed at testing various scenarios of using an application based on interaction with the user or external systems. To test the date of birth, we need to define different cases that can occur when interacting with the program. Let’s take the following scenarios as an example.

1. Entering the correct date of birth: enter the correct date of birth, and the program successfully calculates the age and displays the result.
2. Entering an invalid date of birth: enter an invalid date (e.g., February 30 or April 31), which results in an error message and no age calculation.
3. Entering the wrong date format: enter the date in the invalid format (for example, only year or month), in which case the program should display an error message.
4. Entering a date of birth that will be in the future: enter a date of birth that will be in the future, as a result, the program should show an error message.
5. Entering the date of birth of a minor: once you enter the date of birth of a juvenile (for example, January 1, 2007), the program should display a message stating that the person is underage.
6. Entering the date of birth of an elderly person: enter the date of birth that corresponds to the age of the senior person (for example, January 1, 1950), the program should display a corresponding message that the person is aged.
7. Entering the date of birth of an adult: enter the date of birth that corresponds to the age of the grown-up (for example, January 1, 1990), the program should show a corresponding message that the person is an adult.

Each of these scenarios represents different situations of interaction with the program and helps to make sure that the program correctly handles all possible cases of using the date of birth.

The following two test design techniques are based on experience in testing.

Error Guessing

Error Guessing is an informal approach (a test design technique) when a tester uses his or her knowledge and experience to guess possible errors in a program. Let’s use the example of a date of birth to imagine what mistakes might be made.

1. The program may not process dates in the correct format. For example, instead of ‘day/month/year’, data will be entered in the format ‘month/day/year’ or without any separators at all, i.e. without the ‘/’ sign.
2. The program may not check the entered data for correctness. For example, if you enter non-existent dates (February 30, April 31, 13th month, year in the future), special characters, letters, and so on, the program will skip ahead.
3. The program calculates the age incorrectly.
4. The program may not provide error messages when we enter incorrect data.

These are just a few examples of mistakes that can be detected with Error Guessing. The technique is not based on formal rules, but your experience in testing can be valuable in identifying potential weaknesses in the program. It is worth remembering that this technique does not guarantee full coverage of all possible errors, it is only an additional technique that is better used in combination with others.

Exploratory Testing

Exploratory Testing is a test design technique that involves detecting errors and incorrect program behavior on the fly. In exploratory testing, there are no pre-written test cases, and we have to actively study the program, looking for errors and random scenarios that can lead to incorrect operation, based on our experience and knowledge.

Using the date of birth as an example, exploratory testing can include the following steps.

1. Check whether the program calculates the age properly if the date of birth is entered correctly.
2. Check the response to invalid dates.
3. Limit values. I wrote about this technique above, so you already know what kind of data you need to enter.
4. Incorrect formats. For example, the correct format is ‘day-month-year’, but you are trying to enter:

· ‘month-day-year’;

· ‘year-day-month’;

· ‘day-year-month’.

5. Testing the interaction with other parts of the system: for example, how the calculated age is used in other parts of the program.

This approach provides more flexibility when exploring an application and identifying issues that may go unnoticed with other testing methods.

Checklist-based Testing

Checklist-based Testing is a test design technique in which testers use pre-prepared checklists or lists of critical points to check to make sure they have not missed anything important and have covered critical scenarios.

These checklists can be created based on specifications, customer requirements, technical documentation, or your own experience.

An example of Checklist-based Testing for a date of birth might include the following checks:

1. Correctness of age calculation.
2. Program behavior when the date format is incorrect.
3. Program behavior when entering invalid dates, for example, February 30.
4. Displaying an error if the data is incorrect.
5. The behavior of the program when entering dates that belong to the future.
6. The behavior of the application when entering dates that indicate minors or elderly users.
7. Check the processing of special dates: make sure that the program correctly treats special dates, such as February 29 of a leap year or the date when the user was born on a transitional day.
8. Test how multiple date entries are processed: Try entering a lot of birth dates at once using different browsers.
9. Localization check.
10. Program behavior when no date is entered (leave the fields blank).
11. Check that the program requires the date of birth in the correct format (for example, ‘day/month/year’ or ‘year-month-day’).
12. Check interaction with other form fields if there are additional fields in the form.

These are just a few examples, as everything depends on the project specification, requirements, and so on. Also, this technique should only be used as a supplementary one because it cannot cover all test scenarios.

I hope that test design techniques are now clearer to you and not as scary and complicated as they seem at first glance. Sometimes you need to re-read a few times, or watch the video again, to make things fall into place.

Each technique has its own advantages and can detect different types of defects, so combining them helps to ensure effective and in-depth testing of the program. However, those experience-based test design techniques cannot be used as independent ones, only as additional ones.