Education
Test Automation Example: Practical Use Cases & Code Samples
A practical test automation example shows exactly how to turn a repetitive manual check, such as a multi-page regression pass that takes hours, into a repeatable script with clear assertions.
Test automation replaces manual execution with code that runs the same steps every time, records outcomes, and reports failures quickly enough to fit into daily development cycles.
Key Facts at a Glance
- Test automation uses scripts to automatically execute test cases and compare actual results with expected results, as described by TestDevLab.
- Test automation examples span smoke testing for quick health checks, regression testing to prevent breaking changes, and data-driven testing to validate multiple input scenarios efficiently.
- Selenium WebDriver and Robot Framework are popular tools for browser automation examples, including form submission, calendar selection, and login workflows in web applications.
- Choose test cases for automation based on repetitiveness, stability, and business impact, then start with a small smoke or regression suite to show ROI quickly.
- TestDevLab’s “When to Use Test Automation” article is dated February 11, 2026, which helps when aligning your approach with current industry guidance (source).
- TestMu AI defines automation testing as running tests programmatically with a tool or framework instead of executing cases one by one, which frames the shift from manual to scripted execution (source).
What Is Test Automation and Why Use Examples
Test automation is a software testing method that uses test scripts to automatically execute test cases, according to TestDevLab’s definition. In practice, you encode a workflow, run it on demand or on a schedule, and let the tool report whether the software behaved as expected.
Automated tests execute predefined steps and compare the actual results with the expected results, as described in the same TestDevLab article. That compare step is the key difference between automation that simply clicks around and automation that actually verifies quality.
TestMu AI frames automation testing as a strategy where a tester programmatically runs tests using a tool or framework instead of manually executing test cases one by one (TestMu AI definition). This is the mindset shift most teams need: automation is not a recording, it is an executable specification with assertions.
Examples matter because test automation is full of tradeoffs that become obvious only when you see code and structure. A team can agree that “login should work,” but still build brittle tests unless they see how selectors, waits, test data, and assertions are implemented.
This article walks through automation testing examples in eight categories: smoke test automation, regression test automation, data-driven testing, performance and load testing, and a Selenium automation example focused on UI interactions. Each section includes a concrete scenario, plus a code sample or pseudocode you can adapt in 30-60 minutes to your own application.
Smoke Testing Automation Example
Smoke testing is a quick health check on a new build that verifies the application is stable enough for further and more detailed testing, as defined by TestDevLab. TestDevLab also notes that test automation is commonly used for smoke testing and sanity testing to verify critical functionalities quickly after a build (source).
Smoke tests focus on core functionalities, including application launch, login, and logout, according to TestDevLab. In an e-commerce application, a practical smoke suite often targets 5-10 flows that represent revenue and access control.
Scenario example (e-commerce smoke suite)
- Launch home page and verify the primary navigation renders.
- Log in with a known test account and verify the account menu appears.
- Search for a known product SKU and verify results contain that SKU.
- Add the first result to cart and verify cart count increases by 1.
- Log out and verify the login button returns.
Implementation tip: keep smoke tests short enough to run on every build. A common engineering constraint is a time budget of about 10-15 minutes in CI for the entire smoke pack, because it needs to block broken builds without delaying development.
# Pseudocode for smoke test structure
suite “smoke”:
test “can login and logout”:
open(“/”)
click(“#login”)
type(“#username”, ENV.SMOKE_USER)
type(“#password”, ENV.SMOKE_PASS)
click(“button[type=’submit’]”)
assert visible(“[data-testid=’account-menu’]”)
click(“[data-testid=’logout’]”)
assert visible(“[data-testid=’login-button’]”)
test “can add item to cart”:
open(“/”)
type(“[data-testid=’search’]”, “SKU-123”)
click(“[data-testid=’search-submit’]”)
click(“[data-testid=’product-card’]:first-child”)
click(“[data-testid=’add-to-cart’]”)
assert text(“[data-testid=’cart-count’]”) == “1”
Use a single tag, such as smoke, so the suite can be executed separately from longer test groups. That separation prevents the smoke suite from inheriting slow tests over time.
Regression Testing Automation Example
Regression testing checks that existing behavior still works after changes. Automation is especially valuable here because it can rerun the same coverage after every merge. TestDevLab states that automation plays a key role in regression testing by ensuring that new updates do not accidentally break existing functionality (source).
Scenario example (web app feature update)
A team updates the checkout flow to add a required “delivery instructions” field. The risk is that returning users, saved addresses, and guest checkout paths now fail at different points. A regression suite should include both the new validation and the unchanged steps around it.
- Guest checkout with a new address.
- Logged-in checkout with a saved address.
- Payment method selection and order confirmation page rendering.
Regression test design pattern: treat regression as a collection of stable user contracts. Each contract should end in a single assertable business outcome, such as “order confirmation number is displayed,” rather than a long chain of UI checks.
# Pseudocode using a page-object style
test “guest checkout creates an order”:
home.open()
home.search(“SKU-123”)
product = results.open_first()
product.add_to_cart()
cart.open()
cart.checkout_as_guest()
checkout.fill_shipping(
name=”Test User”,
address=”1 Main St”,
city=”Riga”,
zip=”LV-1001″,
instructions=”Leave at reception”
)
checkout.choose_payment(“card”)
checkout.submit_order()
assert order_confirmation.has_order_number()
Maintenance practices that keep regression suites usable:
- Review failures weekly and remove or rewrite tests that fail because of selector drift rather than product defects.
- Prefer stable attributes like data-testid over CSS class selectors that change with redesigns.
- Split the suite into layers, such as API checks for core rules and UI checks for a small number of end-to-end paths, so UI churn does not stall releases.
When selecting regression candidates, start with a small set of high-impact flows, then grow coverage incrementally after each release cycle.
Data-Driven Testing Automation Example
Data-driven testing means applying the same test logic to multiple data sets, increasing coverage without duplicating test code. Instead of writing separate login tests for each user type, you keep one login test and feed it different usernames and password combinations, expected outcomes, and edge cases (locked users, expired passwords, empty fields).
Step-by-step example: automate login with external test data
- Store test cases externally, for example, in login_cases.csv:
username,password,expected
valid_user,correct_pass,success
valid_user,wrong_pass,error
- locked_user,correct_pass,locked
- Load the file in your test runner, parsing each row into a test input.
- Run the same steps for every row: open the login page, enter credentials, and submit.
- Assert by expectation: success means a dashboard element is visible, error means an error banner appears, and locked means a specific message is shown.
How frameworks handle parameterized data
With Selenium-based stacks (often paired with a test runner like pytest or JUnit), parameterization typically happens at the test runner layer, which supplies one row of data per test invocation. Robot Framework provides built-in tabular test case styles and variable files, making data-driven tests feel natural.
*** Settings ***
Library SeleniumLibrary
*** Test Cases ***
Login cases from data file
[Template] Login Should Result
valid_user correct_pass success
valid_user wrong_pass error
*** Keywords ***
Login Should Result
[Arguments] ${user} ${pass} ${expected}
Open Browser https://app.example/login chrome
Input Text id=username ${user}
Input Text id=password ${pass}
Click Button css=button[type=”submit”]
Run Keyword If ‘${expected}’==’success’ Page Should Contain Element css=[data-testid=”dashboard”]
… ELSE Page Should Contain Invalid credentials
Performance and Load Testing Automation Example
Performance and load testing rely on automation because you must simulate large volumes of users, repeat actions consistently, and collect timings and resource metrics over many iterations. Manual testing cannot reproduce concurrency patterns or sustain traffic long enough to reveal bottlenecks like connection pool exhaustion, slow database queries, or queue backlogs.
Example scenario: automated load test for an API endpoint
Assume you need to validate POST /api/orders under peak demand. The automated test should ramp virtual users, send realistic payloads, and measure response times while watching error rates.
- Define a workload model: ramp from 10 users to 500 users in 5 minutes, then hold for 10 minutes.
- Automate request generation: include auth headers, representative JSON bodies, and unique ids to avoid caching artifacts.
- Capture results: record latency percentiles, throughput, and failures, then compare against SLOs.
- Run in CI or on demand: schedule the test nightly or before releases, using the same script for repeatability.
Common tools and what to measure
Popular performance automation tools include JMeter, Gatling, k6, and Locust. Key metrics to track are response time percentiles (p50, p95, p99), requests per second (throughput), error rate, timeouts, and server-side signals (CPU, memory, GC, database latency). A good practice is to treat pass/fail as a combination of latency and reliability, not just average response time.
Selenium WebDriver Automation Example
Selenium WebDriver is a widely used browser automation tool for testing real user flows in real browsers. It is commonly applied to smoke tests, critical path end-to-end checks, and UI regression tests, where you must validate that the interface behaves correctly across browsers and releases.
Example: automate a date selection and form submission
Imagine a booking form that requires selecting a date from a calendar widget, entering contact details, and submitting. The core challenges are stable element location, waiting for dynamic UI updates, and asserting the business outcome (confirmation displayed).
# Python + Selenium example (simplified)
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
def test_booking_form_selects_date_and_submits(driver):
wait = WebDriverWait(driver, 10)
driver.get(“https://app.example/booking”)
# Locator examples: id, css, xpath, and stable data-testid
date_input = wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, ‘[data-testid=”date-input”]’)))
date_input.click()
# Select a day in the open calendar (example uses an attribute set by the app)
day_15 = wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, ‘[data-date=”2026-06-15″]’)))
day_15.click()
driver.find_element(By.ID, “fullName”).send_keys(“Test User”)
driver.find_element(By.ID, “email”).send_keys(“test.user@example.com”)
driver.find_element(By.CSS_SELECTOR, ‘button[type=”submit”]’).click()
# Assertion: confirmation banner appears with a booking reference
confirmation = wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, ‘[data-testid=”booking-confirmation”]’)))
assert “Reference” in confirmation.text
What this shows in a typical Selenium test
- Element locators should prefer stable attributes like data-testid over fragile CSS class chains.
- Actions include clicks and typing, performed after explicit waits to avoid race conditions.
- Assertions focus on a user-visible outcome (confirmation element and text), not incidental UI details.
When to Automate: Choosing the Right Test Cases
Not every test belongs in an automation suite. The best candidates share a few traits that make them reliable, valuable, and cost-effective to run repeatedly.
- Repetitiveness, tasks executed every build or every release (smoke checks, regression paths, cross-browser sanity).
- Stability, flows, and UI elements that do not change weekly, or have stable hooks like data-testid and contract-backed APIs.
- Business criticality, features tied to revenue, compliance, or core user journeys (login, checkout, booking, payments, account recovery).
- Clear pass/fail outcomes, deterministic assertions (status codes, database state, confirmation messages) rather than subjective judgment.
- High-risk or high data variation scenarios that benefit from running multiple datasets, roles, and edge cases.
Ideal for automation includes API regression tests, authentication flows, create-read-update-delete workflows, permissions checks, and happy-path end-to-end smoke tests that confirm the system is usable. Performance baselines and contract tests are also strong automation examples because they catch changes early and cheaply.
Better suited for manual testing are exploratory sessions, first-time testing of new UI concepts, highly visual checks (layout, typography, subtle animations), and rapidly changing areas where locator churn would dominate maintenance. Usability and accessibility audits often need human judgment, even if you automate parts of them.
Cost-benefit comes down to ROI: estimate the time to build plus ongoing maintenance, then compare it to the cost of running the test manually across releases. Automate when you expect the test to run often, catch expensive defects, or reduce cycle time. If a test changes frequently, fails intermittently, or provides a low signal, the ROI drops fast.
Getting Started with Your Own Test Automation Examples
The examples in this article point to a practical pattern: automate repeatable, high-signal checks first, keep assertions focused on business outcomes, and design for stability with good locators, explicit waits, and clear test data.
Actionable next steps
- Pick a framework that matches your stack: Playwright or Selenium for web UI, Cypress for JavaScript-heavy front ends, and a REST client plus your unit test runner for API coverage. Prioritize team familiarity, reporting, and CI compatibility over novelty.
- Build a small pilot suite (5-15 tests) that covers a critical journey end-to-end. Include a smoke test that validates the app loads, a login path, and 2-3 core actions (for example, search, add item, checkout, or booking confirmation).
- Integrate into CI early so tests run on every pull request or nightly. Track pass rate, duration, and failure reasons so you can spot flakiness and maintenance hotspots.
- Iterate based on results: refactor flaky tests, improve test data management, and add coverage where defects actually occur. Retire tests that are low value or too costly to keep stable.
If you are unsure where to begin, start small with high-value automation examples like smoke and regression tests. Once they run reliably, expand into broader workflows and edge cases with confidence.
Frequently Asked Questions
How should I pick the first tests to automate when following the examples?
Start with repeatable, high-signal checks such as a smoke suite, a login path, and 2 or 3 core actions like search or add item. The article recommends a small pilot suite of about 5-15 tests so you can show ROI quickly. Prioritize stability, business impact, and ease of maintenance.
What practical steps reduce flaky tests when applying the Selenium WebDriver example?
Use explicit waits, robust selectors, and controlled test data as the article emphasizes. Treat tests as executable specifications with clear assertions rather than simple recordings. Refactor or retire tests that remain unreliable after these changes.
When is data-driven testing the better choice over a single scripted scenario?
Choose data-driven testing when the same workflow must be validated with many input permutations, as the article shows, which saves time. Use parameterized test cases to iterate inputs without duplicating code. This improves coverage while keeping suites compact.
Which tools should I consider first for the web UI examples described here?
The article suggests Playwright or Selenium for general web UI work, and Cypress for JavaScript-heavy front ends. It also mentions Robot Framework as a popular choice for some browser automation examples. Pick a tool that matches your stack and team familiarity.
How do I integrate the example test suites into continuous integration so they run on every change?
Hook the pilot suite into your CI pipeline so tests run on every pull request or nightly build, as the article advises. Track pass rate, duration, and failure reasons to detect flakiness early. Keep the suite small at first to limit pipeline time.
What does the article mean by treating automation as an executable specification?
It means encoding expected behavior with assertions so tests verify outcomes, not just click through workflows. The article contrasts this approach with simple recordings and cites TestMu AI to frame the mindset shift. Well-written assertions increase signal and reduce maintenance.
How soon should I expand beyond smoke and regression examples in a real project?
Expand once the initial suite runs reliably and shows value, which the article recommends after a stable pilot. Then add broader workflows and edge cases guided by where defects actually occur. Retire low-value or high-maintenance tests as you iterate.
