1.1The Problem with Traditional Test Automation

Traditional test automation is imperative. You write step-by-step scripts that execute deterministically:

# Traditional Selenium test -- rigid, step-by-step
def test_user_login():
    driver.get("https://app.example.com/login")
    driver.find_element(By.ID, "email").send_keys("test@test.com")
    driver.find_element(By.ID, "password").send_keys("password123")
    driver.find_element(By.ID, "submit").click()
    assert driver.current_url == "https://app.example.com/dashboard"

This test works perfectly -- until it does not. Here is what breaks it:

• A designer changes the button ID from submit to login-btn. The test fails.
• A popup appears ("Accept cookies?") that the script does not expect. The test fails.
• The page loads slowly and the element is not ready when the script clicks. The test fails.
• A new field is added (two-factor authentication). The test fails.
• The test environment is dirty -- a previous test locked the account. The test fails with a misleading error.

Every one of these failures produces the same outcome: a red build with a confusing error message that a human must debug. The test told you what happened ("Expected dashboard URL, got login URL") but not why it happened.

This is the fundamental limitation of imperative testing: scripts cannot adapt to the unexpected.