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.

Pros:

• 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.

Cons:

• 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.

Image Source: https://smartbear.com/learn/automated-testing/introduction-to-data-driven-testing/

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.