If you want to know what is test data, view my video on Test Data. Now, let us see the different types of test data:
Your application likely needs test data to function (or even launch). Examples of application configuration data include the information to connect to database(s), admin user name and password and server information (e.g. email server) in order to send email notifications.
b. Application data
Other than the above, an application may require application specific data. Examples of application specific data are the menus/ links (and their hierarchies) and detail item information (e.g. item name, item details and item price).
c. Customer or user data
The users creating your application may create their own data within the application. Examples of customer or user data are user details (name, address and other personal details), user searches and user transactions (items browsed and purchased).
1. Does your application handle blank test data?
In case, your application does not find a particular test data, it should not crash. It should either display an informative (just the required information and no more; otherwise it may be security risk) message or it should display no data but working functionality. For example, if the information to connect to a database is missing, the application should throw an appropriate error message. If the user has not entered any required details, it should prompt the user to enter those details first.
2. Does your application handle invalid test data?
Data input to an application may be invalid in terms of data type (e.g. character data provided instead of the required numeric data), data size (insufficient or excessive size), outside the valid data range or just incorrectly formatted (dots instead of spaces). There are several approaches to deal with invalid test data. An application may reject the invalid test data, provide valid options for the user to select or attempt a conversion to valid data. In any case, invalid data should not be accepted by your application.
Even if the application handles new invalid data correctly, you should test the existing data for invalids. See the articles on database testing for details.
3. Does your application handle valid test data across the entire range of such data?
Of course, your application should accept valid data. However, using a single test data value for a range is not sufficient. Your test data should include the boundary values and several values (you should ask yourself how many values are reasonable) in between.
4. Does your application store confidential user data?
If you use a copy of the current production data, you could be exposing confidential user information to unauthorized persons. You could consider using only the application configuration data and application data from production. Another way to prevent exposure of confidential user information is to obfuscate the customer data from production.
5. Does the application handle the data volumes present or likely in production?
If your test data includes only a handful of data values and there are thousands of data values in production, your testing will not be realistic. You should match your test data quantity with that in production. Further, for realistic tests, your test data values should not be simple duplicates but vary as in production.
6. Is new data released into production from time to time?
You should test the data being released into production independently as well as with your application. After testing, you should update your test database with the new test data released to production.
Test data types
a. Application configuration dataYour application likely needs test data to function (or even launch). Examples of application configuration data include the information to connect to database(s), admin user name and password and server information (e.g. email server) in order to send email notifications.
b. Application data
Other than the above, an application may require application specific data. Examples of application specific data are the menus/ links (and their hierarchies) and detail item information (e.g. item name, item details and item price).
c. Customer or user data
The users creating your application may create their own data within the application. Examples of customer or user data are user details (name, address and other personal details), user searches and user transactions (items browsed and purchased).
Tips to build test data
The questions that you should consider when creating or sourcing the test data for your tests are:1. Does your application handle blank test data?
In case, your application does not find a particular test data, it should not crash. It should either display an informative (just the required information and no more; otherwise it may be security risk) message or it should display no data but working functionality. For example, if the information to connect to a database is missing, the application should throw an appropriate error message. If the user has not entered any required details, it should prompt the user to enter those details first.
2. Does your application handle invalid test data?
Data input to an application may be invalid in terms of data type (e.g. character data provided instead of the required numeric data), data size (insufficient or excessive size), outside the valid data range or just incorrectly formatted (dots instead of spaces). There are several approaches to deal with invalid test data. An application may reject the invalid test data, provide valid options for the user to select or attempt a conversion to valid data. In any case, invalid data should not be accepted by your application.
Even if the application handles new invalid data correctly, you should test the existing data for invalids. See the articles on database testing for details.
3. Does your application handle valid test data across the entire range of such data?
Of course, your application should accept valid data. However, using a single test data value for a range is not sufficient. Your test data should include the boundary values and several values (you should ask yourself how many values are reasonable) in between.
4. Does your application store confidential user data?
If you use a copy of the current production data, you could be exposing confidential user information to unauthorized persons. You could consider using only the application configuration data and application data from production. Another way to prevent exposure of confidential user information is to obfuscate the customer data from production.
5. Does the application handle the data volumes present or likely in production?
If your test data includes only a handful of data values and there are thousands of data values in production, your testing will not be realistic. You should match your test data quantity with that in production. Further, for realistic tests, your test data values should not be simple duplicates but vary as in production.
6. Is new data released into production from time to time?
You should test the data being released into production independently as well as with your application. After testing, you should update your test database with the new test data released to production.
That's really interesting but I feel here we also consider the activity of data as mentioned either it is static data or a txn data that keep on chaning heavily. If yes then we need to consider the fact if that has been changed by more then one user then how system is behaving.
ReplyDelete@Anuj,
ReplyDeleteThe Application configuration data and Application data may be more or less "static" in a given application. On the other hand, the customer or user data can be considered as transaction data. In a given application, the transaction data may be added, modified or deleted frequently. Therefore, we can say that in such a case the entire transaction data set is changing rapidly. However, please note that this post is about test data and not application behavior. If the transaction data is changing rapidly, we should have a sufficiently large transaction test data set. This is already covered in Question No. 5.
Were you implying anything else?
Thanks for your comment.