top of page

Data-Driven Testing

Traditional test automation requires separate scripts for each test variation - California auto, Texas auto, Florida auto, each with different drivers, vehicles, and coverages. Difficult to maintain, and difficult to scale.
CenterTest's Object-Oriented Data-Driven Testing (OODDT) architecture separates test logic from test data.

Write the scenario once, then scale coverage by adding new data, or combining different sets of shared data. Business teams can expand test coverage without touching code, and automation teams can maintain test suites while minimizing code and data bloat.

CenterTest's object-oriented, data-driven testing architecture minimizing test writing and data bloat.

CenterTest implements OODDT through a layered architecture that minimizes data bloat while maximizing coverage scalability.


Entity references replace duplicated data with logical names. Instead of repeating "John Smith, 123 Main St, San Diego CA 92101" across hundreds of tests, you define a "JohnSenior" entity once and reference it by name. Test data references logical entity names rather than raw values.


Shared data sets enable single object definitions that propagate across multiple scenarios. Define "SanDiegoCA" once in a shared sheet, reference it from Personal Auto, Commercial Auto, and Workers Comp scenarios. When California address validation rules change, update one location rather than hundreds of tests.


Override processing allow scenario-specific variations while inheriting defaults. A test can reference "StandardDriver" but override the date of birth to test age-rating boundaries. The override is explicit and visible, making test intent clear while maximizing data reusability.


Data-combination references handle the technical complexity—type conversion, null handling, validation—automatically. Scenarios focus on test logic, not data parsing.


Coverage scaling emerges directly from the architecture. A single personal auto scenario can execute as many tests as necessary to validate requirements across different states, driver profiles, vehicle types, and coverage combinations—all by manipulating the test data.


Object references use logical names that every stakeholder can understand. For automobile testing, six driver entities cover the matrix: JohnTeen, JohnAdult, JohnSenior, SusanTeen, SusanAdult, SusanSenior—two genders across three age categories. Combine JohnSenior with SanDiegoCA or SusanAdult with AustinTX, and everyone immediately understands the test conditions. Override columns clearly show which values differ from defaults. Business analysts can define new test variations, expand state coverage, or add edge cases without programming expertise.


For example:

TestID

Driver

Location

Driver·Age

PA-001

SusanAdult

SanDiegoCA


PA-002

SusanAdult

AustinTX

45

PA-003

JohnTeen

DallasTX


PA-004

JohnSenior

SanDiegoCA


Read our DDT explainer to understand more about CenterTest's reusable architecture and data-driven processing:


Learn more by exploring our FAQ below, or schedule a consultation to talk to one of Kimputing's test automation specialists.

bottom of page