data-design

Nailing Test Data Design

Testing uses a lot of data. It also produces large amounts of it. Test conditions are described with data. It is also of high importance to functional testing. This list may go on and one. But only one thought is brought up with these statements. That is a lot of data.

Wherever there is a lot of something there also is a lot of confusion unless large amounts of anything are designed in a proper way. Same thing here: without proper test data design tests will be nothing but chaos and trouble. First of all we are to be clear what test data is exactly. Any actual input into the software currently under test is test data. A particular module is executing some process and is affected with or affects particular data. If such data is designed poorly chances are test will not be covering all required scenarios. That is why such an important thing requires attention before testing even begins.

Test data is not the same everywhere and any environment requires a particular set of it. We have learned that designing such data has to be done before tests. But that is time and effort consuming and may result in exceeded deadlines if not done wisely.  This means it does take a special touch for all to work well, a touch that is unique to every testing session. Let’s dig in a little bit deeper.

  • Performance test data. These tests are not oriented to finding bugs. The goal of any performance testing session is in bottleneck elimination, and determining how does a system response to various loads. One important aspect of such testing sessions is that they require to be as close to a ‘live’ environment as possible. Meaning proper test data will be close to actual real life data here. How does one get some? From the customers, obviously. They may already have all the data you may require or they may provide you with necessary feedback. Production environment data will work great if your project is about maintenance testing.
  • Security testing data. Security testing is commenced to ensure system data is secured from malicious impact. There will be several sets of test data that requires to be designed: confidentiality test data that’s actually ensuring that information from the client side is protected; authentication test data that will replicate the process of a user login designed in a way that multiple options and combinations are tested; integrity test data that should determine that all info provided to and by the system is being correct; authorization test data designed to ensure particular rights of a certain user that contains various options and combinations of user roles.
  • White Box test data. This test data ought to be gathered from the code directly and is either covering all possible branches or covering all path possibilities or it may contain invalid types of parameters and consist of invalid argument combinations for Negative API testing. All that data will be required for proper testing.
  • Black Box test data. Code is not seen by a tester for proper Black Box conditions to be met hence test data design will be tricky here. Try testing without any data submitted whatsoever, then do the same with valid and invalid data, try illegal data formats, test data synchronized with your current use cases, etc.

All that sounds like a lot of work. May test data generation be automated? Sure!

Automating Test data Generation

There are plenty of automation tools available for this particular task you may and should use, hence the task is ridiculously difficult if done manually. Make sure you choose such tools wisely after careful consideration and researches though.

Tagged:


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×