Practical Application of Test Design Techniques When Developing Test Cases. Part 1.
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:
 Requirements analysis.
 Define a set of test data based on EP, BVA, EG.
 Development of a test template based on CE.
 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:
Unit 
Type of unit 
Requirements 
Type of request  combobox  Data set:
1. Consultation 2. Conducting the testing 3. Advertising 4. Error on the site * – on the process of performing the operation of receiving applications is not affected. 
Contact person  editbox  1. Required
2. Maximum of 25 characters 3. Numbers and special characters are not allowed. 
Contact number  editbox  1. Required
2. Acceptable “+” and digits 3. “+” can only be used at the beginning of the number 4. Acceptable formats: • starts with a plus – 1115 digits +31612361264 +375291438884 • without plus – 510 digits, for example: 0613261264 2925167 
Message  text area  1. Required
2. The maximum length is 1024 characters 
Send  button  Condition:
1. The default is Disabled. 2. After filling in the required fields, it becomes active (Enabled) Actions after clicking 1. If the entered data is correct – sending a message 2. If the entered data is NOT correct – the validation message 
The use case (sometimes it may not be)
 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?
 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 readding 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
Field 
OK/NOK  Value 
Comment 
Type of request  OK  Consultation  First in the list 
Error on site  Last in the list  
NOK  
Contact person  OK  qwertyuiopqwertyuiopqwert  25 digits, lower case 
a  1 digit  
QWERTYUIOPQWERTYUIOPQWERT  25 digits UPPER case  
QWERTYUIOPqwertyuiopQWERT  25 digits MiXeD case  
NOK  Empty field  
qwertyuiopqwertyuiopqwerty  Longer than the maximum (26 digits)  
@#$%^&;.?,>\/№”!()_{}[<~  Special symbols (ASCII)  
1234567890123456789012345  Only numbers  
adsadasdasdas dasdasd asasdsads(…)sas  Very long line (~1Mb)  
Contact number  OK  +12345678901  With a plus – the minimum length 
+123456789012345  With a plus – the maximum length  
12345  Without a plus – the minimum length  
1234567890  Without a plus – the maximum length  
NOK  Empty field  
+1234567890  With a plus, less than minimum length  
+1234567890123456  With a plus, more than maximum length  
1234  Without a plus, less than minimum length  
12345678901  Without a plus, more than maximum length  
+YYYXXXyyyxxzz  With a plus, letters instead of numbers  
yyyxxxxzz  Without a plus, letters instead of numbers  
+###$$$%^&^&!  Special symbols (ASCII)  
1232312323123213231232(…)99  Very long line (~1Mb)  
Message  OK  qwerqwerrrrtqwer(…)rty  Maximum length (1024 digits) 
NOK  Empty field  
qqqwertqwerewrr(…)rty  Longer than the maximum (1025 digits)  
adsadasdasdas dasdasd asasdsads(…)sas  Very long line (~1Mb)  
@##$$$%^&^&  Only special symbols (ASCII) 
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.