Test Data

Test Data

1. White Box Testing

   • It is desirable to cover as many branches as possible; testing data can be generated such that all branches in the program source code are tested at least once-
   • Path testing: all paths in the program source code are tested at least once - test data preparation can done to cover as many cases as possible-
   • Negative API Testing: Testing data may contain invalid parameter types used to call different methods. Testing data may consist in invalid combinations of arguments which are used to call the program's methods-

2. Performance Testing

   • An important aspect of Performance Testing is that the set of sample data used must be very close to 'real' or 'live' data which is used on production. The following question arises: ‘Ok, it’s good to test with real data, but how do I obtain this data?’ From the people who know the best – the customers.
   • The goal of this type of testing is not to find bugs, but to eliminate bottlenecks.
   • In case you are in a maintenance testing project you could copy data from the production environment into the testing bed. It is a good practice to anonymize (scramble) sensitive customer data like Social Security Number, Credit Card Numbers, Bank Details etc. while the copy is made.

3. Security Testing

   • Authorization: Tells what are the rights of a specific user. Testing data may contain a different combination of users, roles and operations in order to check only users with sufficient privileges are able to perform a particular operation.
   • Authentication: Represents the process of establishing the identity of a user. Testing data can be designed as a different combination of usernames and passwords and its purpose is to check that only the authorized people are able to access the software system.
   • Integrity: Determine that the information provided by the system is correct. To design suitable test data you can start by taking an in-depth look at the design, code, databases and file structures.
   • Confidentiality: All the information provided by clients is held in the strictest confidence and is not shared with any outside parties. As a short example, if an application uses SSL, you can design a set of test data which verifies that the encryption is done correctly.

4. Black Box Testing

   • No data: Check system response when no data is submitted
   • Valid data: Check system response when Valid test data is submitted
   • Invalid data: Check system response when InValid test data is submitted
   • Illegal data format: Check system response when test data is in an invalid format
   • Boundary Condition Dataset: Test data meeting boundary value conditions
   • Equivalence Partition Data Set: Test data qualifying your equivalence partitions.
   • Decision Table Data Set: Test data qualifying your decision table testing strategy
   • State Transition Test Data Set: Test data meeting your state transition testing strategy
   • Use Case Test Data: Test Data in-sync with your use cases.