Many people know what test design is, but not everyone can use it. To clarify the situation a bit, we offer you a consistent approach to the development of test cases using the simplest test design techniques.

As mentioned earlier, the following test design techniques exist:

• Equivalence Partitioning, hereinafter – EP
• Boundary Value Analysis, hereinafter – BVA
• Error Guessing, hereinafter – EG
• Cause / Effect, hereinafter – CE

The development plan for the test cases is as follows:

1. Requirements analysis.
2. Define a set of test data based on EP, BVA, EG.
3. Development of a test template based on CE.
4. Writing test cases based on initial requirements, test data and test steps.

Next, consider the example of the proposed approach.

Example:

To test the functionality of the application form, the requirements for which are provided in the following table:

The use case (sometimes it may not be)

1. Requirements Analysis

We read, analyze the requirements and identify the following nuances for ourselves:

• Which fields are required?
• Do the fields have length or size limits (boundaries)?
• Which fields have special formats?

2. Determination of the test data set

Starting from the requirements for fields, using the test design techniques, we begin the definition of a set of test data:

• depending on whether the field is required or not, define which fields should be checked for an empty value, as it can cause an error (in the resulting table in orange)
• since exhaustive testing is not possible due to the huge number of possible combinations of values, it is necessary to determine the minimum data set first. This can be done using such techniques as EP and BVA. (in the resulting table in blue)
• there is a field on the form that has a compound type (the numbers are used in conjunction with the symbols), has a special data format, and therefore the selection of test data for it is a rather laborious task. Within the limits of this article we shall limit ourselves to a simple verification of the formats and basic requirements described in the application form.
• After the generation of data using standard techniques, you can add a number of values based on personal experience (EG technique) – this will use special characters, very long lines, different data formats, registers in rows (Upper, Lower, Mixed cases), negative and zero values, keywords Null – NaN – Infinity, etc. This can include everything that you think can disable the application (in the resulting table in violet)

Note:

Note that the amount of test data after the final generation will be large enough, even with the use of special design test techniques. Therefore, it is worthwhile to limit only a few values for each field, since the purpose of this article is to show the process of creating test cases, rather than the process of obtaining specific test data.2.1 Выбор тестовых данных для каждого отдельно взятого поля

• The Request type field. Since all data are in the 1 equivalence class, that is, they do not change the process of receiving the application itself, any (1st) position in the sheet with the expected result of OK is taken. But since the field is realized as a sheet, it also makes sense to consider the boundary conditions (the BVA technique), i.e. the first and last elements are taken. Total: 1st and last positions in the sheet. Expected result when using – OK.
• The Contact person field. This required field length of 1 to 25 characters (including boundaries). A mandatory test adds an empty value to the test data. When analyzing the boundary conditions (BVA), we get a set of 0, 1, 2, 24, 25 and 26 characters. A blank value (0 characters) has already been added when analyzing the required field for input, so with BVA it will not be added again (if it is added a second time, duplicate test data will occur, which will not lead to finding new defects, and therefore re-adding to the domain does not make sense). Due to the fact that the values ​​of 2 and 24 characters are, from our point of view, uncritical, they can not be added. As a result, the minimum data set for field testing is lines 1 and 25 – OK, and 0 (blank), 26 characters – NOK.
• The Contact phone field consists of several parts: the country code, the operator code, the phone number (which can be compound and separated by hyphens). To determine the correct set of test data, each component should be considered separately. Applying BVA and EP, we get:
  • for numbers with plus:

By BVA we get numbers with 10, 11, 12 and 14, 15, 16 digits, where 10 and 16 are NOK, and 11, 12, 14, 15 is OK. Considering the findings with EP positions obtain that 11, 12, 14, 15 are in the same equivalence class. Therefore, when testing, we can use any of them, but as the 11 and 15 are the limits of the range, then in our opinion they cannot be skipped. Therefore, we can reduce the set of values to two, eliminating 12 and 14, and leaving 11 and 15 for checking the boundary conditions.

Total obtain:

11 and 15 digits are OK, (+12345678901, +123456789012345)

10 and 16 digits are NOK; (+1234567890, +1234567890123456)

• • for numbers without plus:

By BVA we obtain numbers with 4, 5, 6 and 9, 10, 11 digits.

Acting similarly to the example for phone numbers with plus, we will exclude the values 6 and 9, leaving 5 and 10.

Total obtain:

5 and 10 digits are OK, (12345, 1234567890)

4 and 11 digits are NOK; (1234, 12345678901)

• The Message field. We select the data by analogy with the Contact Person field. As a result, we get the values: lines 1 and 1024 are OK, and 1025 digits – NOK.

The resulting data table, for use in the subsequent compilation of test cases

Next time we’ll continue learning of practical application of test desighn techniques by developing a test pattern and writing test cases based on initial requirements, test data and test pattern.