30 Days of Automation in Testing Day 29: Share how you manage test data in your automated checks

I would like to share our data-driven management:

  1. We use excel files to store the data. Each file stores data for a component, each excel sheet stores data for a test case in the component. When the test scripts run, the data will be read like a Dictionary Object (C#), and we used it to get data to test scripts.’

  2. With the direct data that we get from the API, we will use it and store it to excel properly to reduce the time for next run

  3. We implemented a dynamic data core library, to generate new data for the excel file. We faced the issue that the data will be expired weekly, the QAs will spend the effort to find and update new data, rebuild and run again. The library will help find and generate correctly data automatically with one click and rerun the expired data test cases

2 Likes

We also use excel as data-driven in our automation project that data is external to functional tests and saved in excel file.
However I think we should change to another source formats like .properties, .csv etc because of below reasons:

  • Performance: Reading/Writing operation for excels is comparatively very slow than lightweight file formats like .properties, .csv etc.
  • Maintenance:If you are reading excel, you are most likely be using some external api to achieve this. For e.g. Apache POI or JExcel. Now, since these are external API, there may be version incompatibility in future like current version of excel files may not be compatible with older versions of APIs and vice versa. So, this means we will be having additional maintenance overheads.
1 Like

I’ve approached this in 2 ways:

  • statically - storing data in an excel file (or other such source), then calling it
  • dynamically creating data at each test run so the data is never the same - like emails, phone numbers, or dates (I even found away to generate string text for names, addresses and the like)
3 Likes

There are different ways that I have managed test data in my automation test suite:

  1. Data source like excel/ json/ xml/ csv: I’ve found this to be relatively effective and less dependent way to manage the test data as the test data could be segregated from the source code.
  2. Test data on the BDD feature file along with the scenarios with parameters and background.
  3. Pulling the data from SQL database.
  4. Creating instances of test data on DB during the run time and purge them once execution in completed!
  5. Hard code the test data on source code. This would be last choice though.

More here: https://qakumar.wordpress.com/category/automation-testing/

2 Likes

I use Keyword Driven framework so test-data is managed in Excel Sheet.

Again, from the participants on Twitter:

1 Like

Agree with best practices from @pabs616.