Data-driven testing explained with an input form

An input form needs checks for valid values, missing fields, and different formats. If you write out the same steps for every case, each change to those steps means more editing. Data-driven testing keeps the shared steps separate from the values that change.

The key idea

Put the purpose and expected result next to each set of values. That way, someone reading the table can see what each case checks.

Keep the steps together and vary the data

For a login form, the steps are usually similar: open the screen, enter values, submit, and check the result. The email address, password, and expected result change from case to case.

Data-driven testing stores those variations as data and runs them through the same steps. You can use this structure in a manual test table as well as an automated test.

Write down what each set of data checks

This table shows a few test design examples. Your specification should determine the error messages, where they appear, and whether the form can be submitted.

Write down what each set of data checks
Perspective	Input condition	What to check
Happy path	Valid credentials	The intended user is logged in
Authentication error	The password does not match	Authentication fails and the specified guidance appears
Required input	The email field is empty	Missing input is detected and handled as specified
Format	A string that is not an email address	The format difference is handled as specified
Boundary	Values just below, at, and above the specified limit	Allowed and rejected ranges are distinguished

Try a small example with pytest

In pytest, parametrize passes different sets of arguments to one test function. In this small example, each input string is paired with the integer we expect after conversion.

import pytest

@pytest.mark.parametrize(
    "value, expected",
    [("0", 0), ("42", 42), ("-1", -1)],
)
def test_integer_conversion(value, expected):
    assert int(value) == expected

Choose cases by what they cover

Every extra input takes time to review and run. Before adding one, check what it covers: a boundary, a condition related to a past defect, or another risk you need to test.

If you ask AI for suggestions, check them against the specification. Review the expected results, remove duplicates, and decide which cases matter most. Even a long list can miss an important risk.

References

pytest documentation: parametrizing tests

QA Notebook / Test design