Data driven testing technique isolates test input and expected result from main test script. Test input and expected result are directly read from a data source when the main/controller script is executed. Significant benefit of this approach is same controller script can be used for testing different test scenarios. I will be explaining the same with a simple example in this post.

When to use data driven testing technique

  • You have tests which are to be executed with different data set to in order to get more test coverage
  • You need to involve any team members/Business analysts with less or no programming knowledge in automated test process

Test Scenario: Validate login page
Input data:

User Name Password Expected result
Valid Valid Login successful
Invalid Valid Login failure
Valid Invalid Login failure
Invalid Invalid Login failure
Blank Valid Login failure
Valid Blank Login failure
Blank Blank Login failure

Controller script:
Read input data source
           For each record in input data source
                  Validate login functionality by entering username and password and comparing actual result with expected result 

Well in actual implementation the controller script may not be this simple. You may need to take couple of design decisions based on your requirements. Most of the test tools available support simple implementation of data driven technique. You may need to use single or multiple data source in a single script. So making a key design decision is mandatory here. There may be situations as well when you need to change your control script as well some time along with the data source, so be ready for that. changing data values may not add overhead here until we change the logic to parse the values in control script.
Data source selection
            Always select data source as per your requirement. This can be anything like .csv file, excel file, any db (mysql, oracle etc), xml etc. I prefer  excel or cvs as data source which can be updated easily by anyone. In your script you can always convert the same to a programming language friendly format before parsing.


  • Possible to add more tests quickly with minimum effort.
  • There is no additional script maintenance effort for the second and subsequent tests.
  • Suitable for testers with less programming knowledge or for business analyst who can just update the data file with relevant test data without touching or knowing the control logic behind it.

  • Initial setup may take more time.
  • Good programming support is required to design and maintain the control script(s) carefully.
  • If your test data is very less, this may add extra overhead for maintenance.