Handling Test Data, to seed or not to seed?


(Paul) #1

Hello all,
Just after some opinions. I’ve recently taken to entering my database data in the set up of my automated tests, and then remove it again in the teardown. I really like the fact in one screen I can see what my test data is, the steps and the asserts (using Specflow). Also I can really easily port my tests to a new environment is required. Is this considered good practice? And is there any situations I really should/shouldn’t be doing this?

Thanks in advance,
Paul


(Ellen Dares) #2

Hi,
I will share my thoughts. Kindly follow these steps.

1 Identify the need for test data early. Raise the issue of test data as early as possible, as early as the test planning phase.
2. Thorough surveys during test design. Analysing the potential test data should happen early in the test design phase.
3. Create test data.
4. Execute tests.
5. Save data.
6. Conclude with confidence.

Hope these steps will help you.


(Stefan) #3

What’s the problem? whats the purpose of the testing that you’re doing?

When I was testing the data I wanted to know something like:

  • how the data gets in a particular way in the database
  • what distinct kinds of data are there saved in the database
  • are there differences between data type/processing in frontend entry points, api middle ones, db endpoint?
  • how is the data reused by other systems…is it the same type, same configuration, reaches the frontend of the others; fits in other frontends?
  • looking for unused fields/values from the db that could be deleted;
  • investigating frontend handling of data by inserting test data based on thought scenarios/risks, that’s not available to be modified by an available application;
  • corrupting the data in the database to see a mishandling in frontend;
  • how is the data handled by each sub-system, can a data set be wrongly processed by a sub-system?