Properties of Test Data:
The test data should be selected precisely and it must possess the following four qualities:
1. Realistic: By realistic, it means the data should be accurate in the context of real life e.g. in order to test ‘Age’ field, all the values should be positive and 18 or above. It is quite obvious that the candidates for an admission in the university are usually 18 years old (this might be defined in requirements).
2. Practically valid: This is similar to realistic but not the same. This property is more related to the business logic of AUT e.g. value 60 is realistic in age field but practically invalid for a candidate of Graduation or even Masters Programs. In this case, a valid range would be 18-25 years (this might be defined in requirements).
3. Versatile to cover scenarios: There may be several subsequent conditions in a single scenario, so choose the data shrewdly to cover maximum aspects of a single scenario with minimum set of data, e.g. while creating test data for result module, do not only consider the case of regular students who are smoothly completing their program. Give attention to the students who are repeating the same course and belong to different semesters or even different programs. The data set may look like this:
| Sr# | Student_ID | Program_ID | Course_ID | Grade |
| 1 | BCS-Fall2011-Morning-01 | BCS-F11 | CS-401 | A |
| 2 | BCS-Spring2011-Evening-14 | BCS-S11 | CS-401 | B+ |
| 3 | MIT-Fall2010-Afternoon-09 | MIT-F10 | CS-401 | A- |
| … | … | … | … | … |
There might be several other interesting and tricky sub-conditions. E.g. the limitation of years to complete a degree program, passing a prerequisite course for registering a course, maximum no. of courses a student may enroll in a single semester etc. etc. Make sure to cover all these scenarios wisely with finite set of data.
4. Exceptional data (if applicable/required): There may be certain exceptional scenarios that are less frequent but demand high importance when occur, e.g. disabled students related issues.
Test data preparation techniques:
We have briefly discussed the important properties of test data and it also elaborates how test data selection is important while database testing. Now let’s discuss the ‘techniques to prepare test data’.
There are only two ways to prepare test data:
Method 1. Insert New Data:
Get a clean DB and insert all the data as specified in your test cases. Once, all your required and desired data has been entered, start executing your test cases and fill ‘Pass/Fail’ columns by comparing the ‘Actual Output’ with ‘Expected Output’. Sounds simple, right? But wait, it’s not that simple.
Few essential and critical concerns are as follows:
- Empty instance of database may not be available
- Inserted test data may be insufficient for testing some cases like performance and load testing.
- Inserting the required test data into blank DB is not an easy job due to the database table dependencies. Because of this inevitable restriction, data insertion can become difficult task for tester.
- Insertion of limited test data (just according to the test cases needs) may hide some issues that could be found only with the large data set.
- For data insertion, complex queries and/or procedures may be required, and for this sufficient assistance or help from the DB developer(s) would be necessary.
Above mentioned five issues are the most important and the most obvious drawbacks of this technique for test data preparation. But if there are some advantages as well:
- Execution of TCs becomes more efficient as the DB has the required data only.
- Bugs isolation requires no time as only the data specified in test cases present in the DB.
- Less time required for testing and results comparison.
- Clutter-free test process
Method 2. Choose sample data subset from actual DB data:
This is the feasible and more practical technique for test data preparation. However it requires sound technical skills and demands detailed knowledge of DB Schema and SQL. In this method you need to copy and use production data by replacing some field values by dummy values. This is the best data subset for your testing as it represents the production data. But this may not be feasible all the time due to data security and privacy issues.
This strategy deserves one separate post which we’ll discuss in next article ‘Database gray-box testing’ and precautions to take while testing database.