Data-driven testing (DDT) is an approach to test design where the test data (input and output values) is separated from the actual test case. The test data can be stored in one or more central data sources and shared across different test cases. By storing your test data in a central repository (local storage, Excel spreadsheet, XML file, or SQL database), you can run the same test with a new set of data each time, avoiding redundant design and execution of repetitive tests cases. Toward the end of the test cycle, you can store test data to provide a clear audit trail of what was and wasn’t covered by a test.
Test cases are commonly designed using variables in test steps. Variable placeholders receive values from a data source instead of using hard-coded or fixed values. Each time you execute the test case, the variable is replaced with the test data in the corresponding data source, reducing the time and effort necessary to create new test cases. With this approach, a new test case simply requires a new row of test data in the data source. Additionally, this approach provides a clear separation of testing logic from the actual test data, which reduces maintenance efforts (i.e., any changes to test steps do not affect the test data and vice-versa).
In a nutshell, DDT can be visualised as follows:
When designing test cases using the DDT approach, the focus should be on mapping the test data and the different combinations and variations (negative and positive) to properly meet the business requirements and ensure adequate test coverage. By doing so, when executing test cases using Zephyr Scale, the variable placeholders in test steps are replaced by the values available in the test-data table, ensuring complete reusability of the test steps.
DDT can be used with manual test scenarios, enabling manual test scripts to run together alongside their respective data sets. In DDT, the following operations are performed in a loop for each row of test data in the data source:
-
Test data is retrieved
-
Test data is input into the system under test (SUT) and simulates other actions
-
Expected values are verified
-
Test execution continues with the next set of test data