Mid-level automation techniques

1. Page Object Model (POM)

Locators belong in one place. A page object wraps the locators and actions for a page behind a clean API — tests call loginPage.loginAs(user), not driver.findElement(...).

• Tests read like scenarios — no selectors in the test body.
• UI change → one fix — update the page object, every test benefits.
• Actions, not just fields — expose business verbs (addItemToCart), not raw setters.

2. API test automation

Most business rules live in the API, not the UI. API tests are faster, more stable, and more focused. At mid-level you should own the API layer.

• Tools — REST Assured (Java), requests + pytest (Python), supertest (JS), Postman/Newman for collections.
• Schema validation — assert the response shape against a JSON schema, not just a single field.
• Status codes & headers — check the contract, not just the body.
• Auth — know how to obtain a token, refresh it, and share it across a suite without leaking into test bodies.
• Negative paths — 400/401/403/404/409/422 deserve tests too. UI rarely exposes all of these clearly.

Full API testing reference →

3. Data-driven testing

One test body, many inputs. Parameterisation turns a single flow into systematic coverage — and turns your EP / BVA / decision tables into tests.

• JUnit 5 — @ParameterizedTest with @CsvSource, @MethodSource.
• pytest — @pytest.mark.parametrize.
• Mocha/Jest — test.each([...]).
• Sources — inline, CSV, JSON, or a generator function. External files are easier for non-devs to edit but harder to refactor.

Name each parameterised case so failures point straight at the bad input. login[user=alice, expect=success] beats login[0].

4. Test isolation & data setup

Flaky suites almost always fail here. Every test must:

• Create its own data (via API/DB), not rely on what a previous test left behind.
• Run in any order — enforce this by running with --random / --shuffle.
• Clean up or use disposable data (unique IDs, per-test users, teardown via API).
• Not share state through global variables, singletons, or files on disk.

Prefer API/DB setup over UI setup — it’s orders of magnitude faster and less fragile. Use the UI only for the thing the test is actually asserting.

5. Fighting flakiness

A flaky test is worse than no test — it erodes trust. At mid-level you’re expected to diagnose, not just retry.

• Sync, not sleep — every Thread.sleep/time.sleep in the framework is a bug waiting to happen.
• Deterministic data — freeze time, fix random seeds, use fixed fixtures.
• One concept per test — long end-to-end tests that hit every layer flake for unrelated reasons.
• Quarantine, don’t ignore — move flaky tests to a separate lane, fix them within a sprint.
• Measure — track pass rate per test over time. The top offenders are where you focus.

6. Contributing to the framework

Mid-level engineers start giving back:

• Add a new page object / API client when you hit the second copy-paste.
• Extract a reusable helper (date builder, unique-ID generator, auth fixture) when three tests do the same thing.
• Improve a failure message so the next person doesn’t need to read the stack trace to know what broke.
• Write a short README when you add a capability — your future team-mate needs it.

Rule of thumb: leave the framework cleaner than you found it, but don’t refactor unrelated code in a test-fix PR.

7. Choosing the right layer (the test pyramid)

Before writing a UI test, ask: could this be an API test, or a unit test? Each layer up the pyramid is slower, more brittle, and more expensive to maintain.

• Unit — fast, many. Pure logic, edge cases, error paths.
• Integration / API — business rules, contracts, persistence.
• UI / end-to-end — a small number of critical journeys.

A good mid-level heuristic: if a test would work at the API layer, do it there. Save UI tests for things that only matter in the UI (rendering, accessibility, interaction).

Technique mapping

Problems:
1. Assertions live inside the page object. A page object should expose actions and state, not decide pass/fail — the test owns assertions. submit() asserting the title couples the page to one scenario.
2. Thread.sleep(2000) is a fixed sleep inside the framework. Use an explicit/auto-wait for the "Transfer complete" state instead; the sleep is both slow and flaky.
3. Brittle locator: '#frm input.acct-from-v3' mixes an id with a versioned class — it will break on the next restyle. Prefer a stable id or data-testid.
4. submit() returns nothing. It should return the next page object (e.g. a ConfirmationPage) so navigation is explicit and chainable.

A clean version would:
- Hold locators in one place, expose business verbs (enterAmount, transferTo), keep zero assertions.
- Wait on a real condition (confirmation banner visible) rather than sleeping.
- Return the next page object from submit() so the test reads like a scenario and the test — not the page object — asserts the outcome.

Parameterised test (pytest example):
import pytest

@pytest.mark.parametrize('gst, expected', [
    pytest.param('123-456-789', True,  id='valid_9_digit'),
    pytest.param('123-456',     False, id='too_short'),
    pytest.param('12A-456-789', False, id='contains_letter'),
    pytest.param('',            False, id='empty'),
], )
def test_gst_validation(gst, expected):
    assert validate(gst) == expected

Why this is better:
- One test body, many inputs — adding a case is one line, not a new function.
- Each case has a readable id (valid_9_digit, too_short…) so a failure points straight at the bad input, unlike test[0].
- I added an empty-string case the originals missed.

The dataset should come from equivalence partitioning and boundary value analysis: one representative per valid/invalid partition (valid 9-digit, too short, non-numeric, empty), plus the length boundaries of the format. Parameterisation is simply how those design techniques become executable tests.

Setup (Arrange):
- Create a unique test user (or use a per-worker user) via the API.
- Create a listing via POST /listings with a unique title, e.g. "QA-bike-{uuid}". Capture the returned listingId.
- Log in via an API-obtained session/token, not by driving the login form.

UI action (Act):
- Open the "My listings" page in the browser for that user.

Assertion (Assert):
- await expect(page.getByText('QA-bike-{uuid}')).toBeVisible();  // auto-waits, no sleep
- Optionally assert the listing count or that the row links to the captured listingId.

Teardown:
- DELETE /listings/{listingId} (and the test user if created) via the API, in a finally/afterEach so it runs even on failure.

Which steps use the API and why:
- User creation, listing creation, login, and cleanup all go through the API: it is far faster and less fragile than driving forms, and it keeps the test isolated — the unique title/uuid means parallel workers never collide.
- Only the one thing under test (does the listing render on My listings?) goes through the UI. Synchronisation is handled by Playwright's auto-waiting assertion on the unique title, so there is no fixed sleep and the test runs safely in any order.

Self-Check