In test automation, there are often cases where you might have multiple data sets for which you need to run the same tests on. This approach has been described with several names, including data-driven testing, parameterized testing, or table-driven testing. In mabl, we call it data-driven testing, or DDT. This is the process of loading data that is external to your functional tests to strengthen and extend your automated test cases. It is now possible to create journeys that you then parameterize to run across several different inputs.
A data-driven test performs the following operations several times:
- Retrieves a portion of testing data from data source.
- Enters and utilizes data in an application form.
- Verifies the actual results with the expected results.
- Repeats this test with the next set of input data.
There are a number of benefits of making your tests data-driven. Some include:
- Reusability: any test script can be written and re-executed hundreds or thousands of times, with different inputs each time
- Versatility: a data-driven test is usually associated with a single test or procedure, but can be used in several test cases
- Efficiency: data-driven tests can generate test scripts with less code
- Separation of logic: data-driven tests allow for the clean distinction of test case logic from the actual test data
- Stronger test coverage: you can continually change the input test data and cover a broad scenario of inputs