Data-Driven Testing Clarified
The drawbacks of DDT outweigh its benefits for most testing needs.
This article is one of the “IT Terminology Clarified” series.
Data-Driven Testing (DDT) is one type of functional test automation that loads test data stored in a table or spreadsheet format. Over a decade ago, DDT was often a highlighted feature in commercial test automation tools. Though it is still the case for some, I see it less now. Why? DDT looks good in the demonstration but has little value in practice. In this article, I will share my experience with DDT.
The core concept of DDT is that the test data is separated from test scripts.
- Can use the same test script for the different data sets
- Non-technical staff, such as business analysts, may get involved in managing test data.
- Test scripts (with test data) are easily outdated, as scripts and data are tightly coupled but they may be changed independently.
- More difficult to debug
- The introduction of GUI tools often makes things more complex
- DDT is often unnecessary
Over my 15 years in software testing, there is only one case I could remember that DDT was actually useful.
Overall, I recommend avoiding DDT. I will dive in more about DDT and some of its shortcomings.
Table of Contents:
· DDT in Commercial Tools
· How to do Data-Driven Testing with raw Selenium WebDriver
· A Sample DDT (Selenium) execution
· DDT is difficult to maintain or debug
· DDT Reporting
DDT in Commercial Tools
The below screenshot is taken from SmartBear’s TestComplete documentation.
From the highlighted text, such as “Data-Driven Loop”, “Variables.DBTable (“Credit Card”)…” and “OrderForm”, we decipher that the GUI utility tries to create a loop of filling data (from a DB table) into a form on the application.