SDET Career Path Guide

Manual regression of 50 flows
  Per release:  16 hours / human
  10 releases:  160 hours
  Bug-escape rate: ~12% (fatigue + skipped flows)

Automated regression of 50 flows
  Build time:    ~40 hours one-time
  Per release:   ~10 minutes (CI)
  Bug-escape rate: ~3% (when paired with manual exploratory)

• Pick one manual flow your team runs every release. Time it. Multiply by # of releases per year.
• Estimate the build cost of automating it. Compute payback period in releases.
• Identify one flow that should NOT be automated yet (too volatile, low value, hard to stabilize) — explain why.

• Count tests in your current project at each level. Sketch the actual shape.
• Find one E2E test that asserts a business rule. Could it move to unit/integration? Try it.
• Pick one bug from the last sprint. At which level should it have been caught?

Question to answer                        Best test type
────────────────────────────────────────  ─────────────────
"Does this discount calc round correctly?" Unit
"Does the order service write to the DB?"  Integration
"Does v2 of /orders break the iOS app?"    Contract
"Does POST /orders return 422 on bad SKU?" API
"Can a user actually buy something?"       E2E
"Did the homepage layout shift?"           Visual
"Can a screen reader complete checkout?"   Accessibility
"Does it hold up under 5k req/s?"          Performance / Load

• Take 5 recent bugs in your tracker. Match each to the type of test that would have caught it earliest.
• Identify one type your team isn't doing at all. Sketch the smallest first investment (one tool, one test).
• Run an accessibility scan (axe-core or Lighthouse) on a page you own. Triage the top 3 findings.

// load.js — k6
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
    vus: 200,           // concurrent users
    duration: '5m',
    thresholds: {
        http_req_duration: ['p(95)<500'],   // SLO
        http_req_failed:   ['rate<0.01'],
    },
};

export default function () {
    const r = http.get('https://api.example.com/orders/42');
    check(r, { '200 OK': r => r.status === 200 });
    sleep(1);
}

• Pick one critical endpoint. Write down its SLO (latency target, error budget, target RPS).
• Run a 1-minute k6 test against it locally. Read the P95 line.
• Run a Lighthouse audit on a page you own. Capture Performance, Accessibility, Best Practices, SEO scores.
• Run an axe-core scan; file the top 3 a11y issues as tickets.

// API test — proves the rule, runs in 80ms
test('cannot order more than stock', async ({ request }) => {
    const r = await request.post('/orders',
        { data: { sku: 'X1', qty: 9999 } });
    expect(r.status()).toBe(422);
    expect((await r.json()).code).toBe('OUT_OF_STOCK');
});

// E2E test — proves the user sees a clear error, runs in 8s
test('out-of-stock toast appears', async ({ page }) => {
    await page.goto('/product/X1');
    await page.fill('#qty', '9999');
    await page.click('#buy');
    await expect(page.locator('.toast--error')).toBeVisible();
});

// Same rule, two angles — and you don't need 50 E2Es to cover qty edge cases

• Pick 5 E2E tests in your suite. Mark which ones could be replaced or shortened by API tests.
• Convert one E2E business-rule check into an API test. Measure the speed difference.
• Identify the smallest set of E2E tests that prove "the UI itself works" — that's your real E2E budget.

YES — automate as E2E
  ✓ Sign up → verify email → first login
  ✓ Add to cart → checkout → payment success → order confirmation
  ✓ Admin creates a tenant → user from that tenant logs in
  ✓ Password reset round-trip

NO — push these down
  ✗ Every form-validation message on every field
  ✗ Every error code from /api/orders
  ✗ Pixel-perfect rendering of a marketing page
  ✗ Discount math on every coupon code

  → Validation errors → component test
  → API error codes   → API test
  → Pixel diffs       → visual snapshot test
  → Discount math     → unit test

• List your product's "if this breaks we lose money or trust" flows. That's your E2E budget.
• For each flow, write down what makes it flaky today, and one specific stabilisation you'd apply.
• Configure your E2E job to capture trace + screenshot on failure and upload as a CI artifact.

// Playwright
await page.goto('/login');
await page.fill('#user', 'admin');
await page.click('button[type=submit]');
await expect(page).toHaveURL(/dashboard/);

// Selenium (Java)
driver.get("/login");
driver.findElement(By.id("user")).sendKeys("admin");
driver.findElement(By.cssSelector("button[type=submit]")).click();
new WebDriverWait(driver, Duration.ofSeconds(5))
    .until(ExpectedConditions.urlContains("/dashboard"));

// Cypress
cy.visit('/login');
cy.get('#user').type('admin');
cy.get('button[type=submit]').click();
cy.url().should('include', '/dashboard');

• Implement the same login test in two of the three. Time the run, count the lines.
• Note what each one does automatically that the other doesn't.
• Write a 1-paragraph rationale for which you'd choose for your current product.

// Modern locators (preferred)
page.getByRole('button', { name: 'Save' }).click();
page.getByLabel('Email').fill('a@x');
page.getByTestId('cart-count');

// CSS — readable, fast
page.locator('input[name="email"]');

// XPath — when CSS can't reach (text matching)
page.locator('//button[normalize-space()="Save changes"]');

// Validate
expect(await page.locator('#total').textContent()).toBe('$42.00');
expect(await page.locator('#submit').isEnabled()).toBe(true);

• On the-internet.herokuapp.com: automate a checkbox, a dropdown, a JS alert.
• Find the same element via id, css, xpath, and getByRole — compare brittleness.
• Extract a table's row count and assert it equals 4.

// BAD
Thread.sleep(5000);

// GOOD — Selenium
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.visibilityOfElementLocated(By.id("result")));

// Playwright auto-waits
await expect(page.locator('#result')).toBeVisible();

• On the-internet.herokuapp.com/dynamic_loading: solve once with sleep, once with explicit wait. Run each 10x — count flakes.
• Set a deliberately short timeout; read the failure message.
• Find one Thread.sleep in your codebase; replace it with a wait and write a 1-line PR description.

// playwright.config.ts
use: {
  screenshot: 'only-on-failure',
  trace:      'retain-on-failure',
  video:      'retain-on-failure',
}

// Selenium — manual hook
try { test.run(); }
catch (Throwable t) {
    File shot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
    Files.copy(shot.toPath(), Paths.get("failure.png"));
    throw t;
}

• Trigger each of the three exceptions deliberately, then fix each one.
• Add screenshot-on-failure to your runner config; verify a deliberate failure produces one.
• In DevTools Console, validate one CSS and one XPath selector live.

// Playwright — auto-retrying matchers
await expect(page.locator('#cart-count'),
    'cart should show 3 items after add').toHaveText('3');
await expect(page).toHaveURL(/\/checkout/);

// JUnit (Java)
assertEquals("3", cart.getCount(),
    "cart should show 3 items after add");

• Add assertions for: title, URL, an element's text, an attribute.
• Force each to fail; rewrite any vague messages.
• Replace one if/else+log block with an explicit assertion.

// pages/LoginPage.ts
export class LoginPage {
    constructor(private page: Page) {}
    user   = () => this.page.getByLabel('Email');
    pass   = () => this.page.getByLabel('Password');
    submit = () => this.page.getByRole('button', { name: 'Sign in' });

    async login(u: string, p: string) {
        await this.user().fill(u);
        await this.pass().fill(p);
        await this.submit().click();
    }
}

// tests/login.spec.ts — only intent
test('valid login', async ({ page }) => {
    const login = new LoginPage(page);
    await page.goto('/login');
    await login.login('admin', 'pw');
    await expect(page).toHaveURL(/dashboard/);
});

• Refactor any 3-test suite into a Page Object.
• Change a selector in the page object only; verify all 3 tests still pass.
• Lift two reusable methods into a BasePage.

// Volatile id — avoid
//div[@id="row_8c7f23"]/button

// Anchor on label, walk to control
//label[normalize-space()="Email"]/following::input[1]

// Cell by row content
//tr[td[normalize-space()="Ada"]]/td[contains(@class,"actions")]//button[@aria-label="Edit"]

// Data attributes the dev team commits to
//*[@data-testid="cart-checkout-btn"]

• On a real app, find an element with no stable id. Build an XPath anchored on its label.
• Build an XPath that finds a button by row's text content (table cells).
• Negotiate data-testid on the 3 most-tested components in your app.

// Playwright — first-class
await page.route('**/api/feature-flags', route =>
    route.fulfill({ json: { newCheckout: true } })
);

// Network throttling
const client = await page.context().newCDPSession(page);
await client.send('Network.emulateNetworkConditions', {
    offline: false, downloadThroughput: 50_000,
    uploadThroughput: 20_000, latency: 500,
});

• Mock a single API response in a test; verify the UI renders the mocked state.
• Throttle network to "Slow 3G" and run a critical flow; observe what breaks.
• Capture all console errors during a test; fail if any appear.

// Custom wait helper
async function waitFor<T>(
    fn: () => Promise<T | null>,
    { timeout = 10_000, interval = 200 } = {}
): Promise<T> {
    const deadline = Date.now() + timeout;
    while (Date.now() < deadline) {
        const v = await fn();
        if (v) return v;
        await new Promise(r => setTimeout(r, interval));
    }
    throw new Error('waitFor timed out');
}

// Retry at the right level — the API call, not the whole test
await retry(() => api.getOrder(id), { times: 3, backoffMs: 500 });

• Write a waitFor helper. Replace 3 ad-hoc polling loops with it.
• Find a test that retries the whole flow on flake; move the retry to the actual unstable call.
• Quarantine 1 known-flaky test in a separate suite; track it until fixed.

// iFrame — Playwright
const stripe = page.frameLocator('iframe[name^="__privateStripe"]');
await stripe.getByLabel('Card number').fill('4242424242424242');

// Shadow DOM — Playwright pierces by default
await page.locator('my-button >> button').click();

// Selenium 4
WebElement host = driver.findElement(By.tagName("my-button"));
SearchContext shadow = host.getShadowRoot();
shadow.findElement(By.cssSelector("button")).click();

• Automate a Stripe Elements card form using frame locators (use Stripe's test card 4242…).
• Find a shadow-DOM component in your app; build a stable selector.
• Dismiss a cookie banner that lives in a shadow root.

Question                                  Best fit
────────────────────────────────────────  ────────────
Java team, Selenium Grid in place         Selenium
Modern web app, want fast onboarding      Playwright
Pure FE team, component + e2e in one DX   Cypress
Need cross-browser real-device cloud      Selenium / Playwright (BrowserStack/Sauce)
Need auto-waits + tracing out of box      Playwright

• Port one Playwright test to Cypress (or vice versa). Note what each does naturally vs awkwardly.
• Read each tool's "best practices" doc — make a 1-page cheat sheet of differences.
• Write a 1-paragraph tool recommendation for a hypothetical greenfield project.

public class User {
    private final String email;
    private String password;
    private boolean active = true;

    public User(String email, String password) {
        this.email = email;
        this.password = password;
    }
    public String getEmail() { return email; }
    public void deactivate() { this.active = false; }
}

• Build a TestUser class with email, role, fullName().
• Make all fields private; expose only what tests need.
• Instantiate two users; pass them into a login test.

public abstract class BasePage {
    protected WebDriver driver;
    protected BasePage(WebDriver d) { this.driver = d; }
    public abstract String url();
    public void open() { driver.get(url()); }
}
public class LoginPage extends BasePage {
    public LoginPage(WebDriver d) { super(d); }
    @Override public String url() { return "/login"; }
}

• Define a BasePage with open() and title(); subclass twice.
• Override title() in each; assert per page.
• Try the same with an interface — note where reuse breaks.

try {
    api.placeOrder(order);
} catch (TimeoutException e) {
    api.placeOrder(order);   // expected → retry once
} catch (PaymentDeclinedException e) {
    assertEquals("INSUFFICIENT_FUNDS", e.getCode());
} finally {
    cleanup.removeOrder(order.getId());
}

• Wrap a flaky API call in a single retry; log the first failure.
• Define a TestDataMissingException with a useful message.
• Find one empty catch in a real codebase; fix it.

List<User> users = List.of(new User("a@x"), new User("b@x"));

Map<String, String> baseUrls = Map.of(
    "dev",  "https://dev.api",
    "prod", "https://api");

Set<String> seen = new HashSet<>();

• Build a TestDataProvider returning a list of 5 users.
• Replace an if/else env-URL block with a Map lookup.
• Use a Set to detect duplicates in generated emails.

# npm
npm install -D @playwright/test

# Maven
<dependency>
  <groupId>com.microsoft.playwright</groupId>
  <artifactId>playwright</artifactId>
  <version>1.50.0</version>
</dependency>

# NuGet
dotnet add package Microsoft.Playwright

• Add and import 3 libraries; run them.
• Read the lockfile — find one transitive dep you didn't install directly.
• Bump a library by a major version. Read the changelog. Decide.

my-tests/
├─ tests/
│  ├─ login.spec.ts
│  └─ checkout.spec.ts
├─ pages/
│  ├─ BasePage.ts
│  ├─ LoginPage.ts
│  └─ CheckoutPage.ts
├─ fixtures/
│  └─ users.json
├─ utils/
│  └─ apiClient.ts
├─ playwright.config.ts
└─ package.json

• Reorganise a flat scripts/ folder into the layout above.
• Find a 60-line function; split into 3 helpers.
• Delete every comment that just restates the code.

// JavaScript (fetch)
const res = await fetch('https://api/orders/42', {
    headers: { Authorization: 'Bearer ' + token }
});
const data = await res.json();
console.log(data.total, data.items.length);

// Java (RestAssured)
Response r = given().header("Authorization", "Bearer " + token)
    .when().get("/orders/42");
System.out.println(r.jsonPath().getDouble("total"));

• Save a Postman request; convert via Code button. Run it.
• Print only 3 specific fields from the response.
• Add one dynamic header (e.g., a generated request ID).

test('create then read user', async ({ request }) => {
    const created = await request.post('/users', {
        data: { name: 'Ada', role: 'admin' }
    });
    expect(created.status()).toBe(201);
    const { id } = await created.json();

    const got = await request.get(`/users/${id}`);
    expect(got.status()).toBe(200);
    expect((await got.json()).name).toBe('Ada');
});

• Against reqres.in: GET asserting status + 1 field.
• POST that creates and asserts non-null id.
• Chain POST → GET to prove the resource is retrievable.

// playwright.config.ts
use: { baseURL: process.env.API_URL ?? 'https://dev.api',
       extraHTTPHeaders: { 'X-Tenant': 'qa' } }

// fixtures/users.csv
email,role,expectedStatus
ada@x,admin,200
guest@x,guest,403

• Move base URL out of every test into a single config.
• Build a request wrapper that auto-attaches auth.
• Externalise one POST body to JSON; load it from the test.
• Drive the same test from a 3-row CSV.

# 1) Postman: Collection → ⋯ → Mock collection
# 2) Get a URL like https://<id>.mock.pstmn.io
# 3) Define examples (200 success, 500 error)

baseURL: process.env.USE_MOCK === '1'
    ? 'https://abcd.mock.pstmn.io'
    : 'https://api.dev';

• Spin up a Postman mock for GET /users/{id} with 200 + 404 examples.
• Write tests that pass against the mock for both cases.
• Add a 500 example; verify your test surfaces it cleanly.

// TypeScript with zod
import { z } from 'zod';
const Order = z.object({
    id: z.number(),
    items: z.array(z.object({ sku: z.string(), qty: z.number() })),
    total: z.number(),
});

const raw = await (await request.get('/orders/42')).json();
const order = Order.parse(raw);   // throws if shape changed
expect(order.items).toHaveLength(3);

• Define a schema/POJO for a real endpoint; deserialise the response.
• Break the schema deliberately; observe the failure message.
• Test a nested array endpoint — assert against typed sub-fields.

async function getToken(role: string) {
    const r = await request.post('/oauth/token', {
        form: { grant_type: 'password',
                username: users[role].email,
                password: users[role].password }
    });
    return (await r.json()).access_token;
}

for (const [role, expected] of [['admin', 200], ['guest', 403]]) {
    test(`admin endpoint as ${role}`, async ({ request }) => {
        const token = await getToken(role as string);
        const r = await request.get('/admin/users',
            { headers: { Authorization: `Bearer ${token}` } });
        expect(r.status()).toBe(expected);
    });
}

• Drive a test from a 5-row JSON dataset.
• Implement OAuth2 password-grant token retrieval; cache for the suite.
• Write a role matrix (admin/user/guest × 3 endpoints) and assert correct codes.

// k6 — concurrent ordering
export const options = {
    scenarios: {
        burst: { executor: 'shared-iterations',
                 vus: 50, iterations: 50 }
    }
};

export default function () {
    const r = http.post('https://api/orders',
        JSON.stringify({ sku: 'X1', qty: 1 }),
        { headers: { 'Content-Type': 'application/json' } });
    check(r, { '201 created': r => r.status === 201 });
}

• Pick one critical endpoint; write a k6 SLO test (P95 latency at target RPS).
• Fire 50 concurrent POSTs to a "create unique resource" endpoint; assert no duplicates.
• Add a perf job to CI that runs nightly, not per-commit.

// Ajv (Node) against a schema generated from OpenAPI
import Ajv from 'ajv';
const ajv = new Ajv();
const validate = ajv.compile(orderSchema);

const body = await (await request.get('/orders/42')).json();
if (!validate(body)) throw new Error(JSON.stringify(validate.errors));

• Generate a JSON Schema from your OpenAPI spec (or write one for a small response).
• Add schema validation to one existing test; deliberately break the response shape.
• Compare schema validation to typed deserialisation — when do you want both?

tests/
└─ api/
   ├─ orders/
   │  ├─ create.spec.ts
   │  ├─ list.spec.ts
   │  └─ delete.spec.ts
   └─ users/
      └─ login.spec.ts
clients/
   ├─ OrdersClient.ts
   └─ UsersClient.ts
fixtures/
   └─ test-tenant.ts

• Reorganise a flat api-tests/ folder by resource.
• Build one client class for the most-used resource.
• Tag 5 tests as @smoke; configure a CI job that runs only them on PR.

jobs:
  api-smoke:
    runs-on: ubuntu-latest
    env: { API_URL: ${{ secrets.QA_API_URL }},
           TOKEN:   ${{ secrets.QA_TOKEN }} }
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --grep @smoke --reporter=junit,html
      - if: always()
        uses: actions/upload-artifact@v4
        with: { name: api-report, path: playwright-report/ }

• Add a smoke job that runs on every PR (< 2 min target).
• Add a nightly full-regression job; set up notifications on failure.
• Configure a status badge for the API suite in your README.

CREATE TABLE users (
    id          BIGINT      PRIMARY KEY AUTO_INCREMENT,
    email       VARCHAR(255) NOT NULL UNIQUE,
    role        VARCHAR(32)  NOT NULL DEFAULT 'guest',
    created_at  TIMESTAMP   NOT NULL DEFAULT CURRENT_TIMESTAMP
);
ALTER TABLE users ADD COLUMN active BOOLEAN NOT NULL DEFAULT 1;

• Spin up SQLite or use DB Fiddle. Create users + orders with FKs.
• Add a column with ALTER; drop the column.
• Read your project's schema; sketch the ERD on paper.

-- INNER: users who placed orders
SELECT u.email, o.id FROM users u
INNER JOIN orders o ON o.user_id = u.id;

-- LEFT: every user + orders if any
SELECT u.email, o.id FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

-- SELF: each employee with manager's name
SELECT e.name, m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

• SQLZoo JOINs tutorial end-to-end.
• Same query 3 ways: INNER, LEFT, RIGHT — compare row counts.
• Find users with NO orders (LEFT JOIN + IS NULL).

SELECT * FROM orders
WHERE status IN ('paid', 'shipped')
  AND total BETWEEN 10 AND 100
  AND (country = 'US' OR country = 'CA');

SELECT email FROM users
WHERE id IN (
    SELECT user_id FROM orders WHERE status = 'unpaid'
);

• Write a 3-condition query; rewrite with parentheses to flip meaning.
• Replace an OR chain with IN.
• Solve "products never ordered" using a subquery.

SELECT u.email, COUNT(o.id) AS orders, SUM(o.total) AS spent
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid'
GROUP BY u.email
HAVING COUNT(o.id) > 5
ORDER BY spent DESC;

• Compute total revenue per month.
• List products ordered fewer than 3 times.
• Find each customer's largest single order with MAX.

try (Connection c = DriverManager.getConnection(url, user, pass);
     PreparedStatement ps = c.prepareStatement("SELECT email FROM users WHERE id = ?")) {
    ps.setLong(1, 42L);
    try (ResultSet rs = ps.executeQuery()) {
        if (rs.next()) System.out.println(rs.getString("email"));
    }
}

• Connect to local SQLite or Postgres from your test project.
• Run SELECT; read 1 column.
• Write a teardown that deletes the test rows you created.

// BAD — vulnerable to '; DROP TABLE users;--
Statement s = c.createStatement();
s.execute("SELECT * FROM users WHERE email = '" + email + "'");

// GOOD
PreparedStatement ps = c.prepareStatement(
    "SELECT * FROM users WHERE email = ?");
ps.setString(1, email);

• Convert one concatenated query to a prepared statement.
• Try injecting ' OR 1=1 -- against both versions; observe.
• Explain to a teammate why parameter binding stops the attack.

c.setAutoCommit(false);
try {
    insertUser(c, "ada@x");
    insertOrder(c, ada.id, 42.00);
    runTest();
} finally {
    c.rollback();
}

• Wrap inserts in BEGIN/ROLLBACK; confirm rows don't persist.
• Force a failure mid-flow; verify nothing committed.
• Read up on isolation levels; identify your DB's default.

record UserRow(long id, String email, String role) {}

List<UserRow> rows = new ArrayList<>();
while (rs.next()) rows.add(new UserRow(
    rs.getLong("id"), rs.getString("email"), rs.getString("role")));

-- Discover schema
SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'public';

• Query information_schema; list every table and FK.
• Sketch the ERD on paper from the FK list.
• Write a helper mapping a ResultSet row to a typed record.

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;
-- Seq Scan on orders ... (10 ms)

CREATE INDEX idx_orders_user ON orders(user_id);
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;
-- Index Scan ... (0.2 ms)

• Run EXPLAIN on a query against a 100k-row table; note "seq scan" vs "index scan".
• Add an index; re-run EXPLAIN; observe.
• Insert 1k rows on the indexed table; note the (small) write cost.

-- Top 3 customers by spend per country
SELECT * FROM (
  SELECT country, email, spent,
         ROW_NUMBER() OVER
            (PARTITION BY country ORDER BY spent DESC) AS rn
  FROM customer_totals
) ranked
WHERE rn <= 3;

• Find each customer's most-recent order using ROW_NUMBER + PARTITION BY.
• Use LAG to compute time between consecutive orders per user.
• Compute a running total of daily revenue.

WITH recent_orders AS (
    SELECT user_id, MAX(created_at) AS last_at
    FROM orders GROUP BY user_id
)
SELECT u.email, r.last_at
FROM users u JOIN recent_orders r ON r.user_id = u.id;

-- Recursive: manager chain
WITH RECURSIVE chain AS (
    SELECT id, name, manager_id FROM employees WHERE id = 42
    UNION ALL
    SELECT e.id, e.name, e.manager_id
    FROM employees e JOIN chain c ON e.id = c.manager_id
)
SELECT * FROM chain;

• Rewrite a nested subquery using a CTE; compare readability.
• Write a recursive CTE for a category tree.
• Chain 3 CTEs to express a multi-step transformation.

-- Correlated
SELECT u.email FROM users u
WHERE (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) > 5;

-- EXISTS — short-circuits
SELECT u.email FROM users u
WHERE EXISTS (SELECT 1 FROM orders o
                WHERE o.user_id = u.id AND o.status = 'unpaid');

• Rewrite an IN(subquery) as EXISTS; compare EXPLAIN plans.
• Find one correlated subquery; rewrite as a JOIN; compare.
• Identify a case where IN and JOIN return different counts (duplicates).

@Container
PostgreSQLContainer<?> pg = new PostgreSQLContainer<>("postgres:16");

@Test
void migrationsApplyCleanly() {
    Flyway.configure()
        .dataSource(pg.getJdbcUrl(), pg.getUsername(), pg.getPassword())
        .load()
        .migrate();
    // then assert against the migrated schema
}

• Spin up a Postgres container in a test; run migrations against it.
• Write a test asserting a NOT NULL constraint actually rejects NULLs.
• Add a test that round-trips a stored procedure with sample input.

-- Relational
users(id, email)
orders(id, user_id, total)
SELECT o.* FROM orders o JOIN users u ON u.id = o.user_id WHERE u.email = 'a@x';

// Document (Mongo) — orders embedded in user
{ "_id": "u1", "email": "a@x",
  "orders": [{ "id": "o1", "total": 42 }] }
db.users.find({ email: 'a@x' }, { orders: 1 })

• Run MongoDB locally (Docker). Insert and query a document.
• Model a small domain twice — relational vs document. Compare query patterns.
• Identify one place in your product where NoSQL would simplify, and one where it would hurt.

git clone https://github.com/me/my-tests.git
cd my-tests
echo "new test" > tests/login.spec.ts
git add tests/login.spec.ts
git commit -m "add login happy-path test"
git push origin main
git pull

• Clone any public repo, add a file, commit, push to a fork.
• Inspect .git/; see commits as files in objects/.
• Compare centralized vs distributed in a 1-paragraph note.

git status
git diff
git diff --staged
git add -p              # interactive hunk staging
git commit -m "fix flaky login wait"
git log --oneline -10
git log --oneline --graph --all

• Make 3 commits with messages that pass the "would I understand this in 6 months?" test.
• Use git add -p to stage half a file's changes.
• Run git log --graph on a multi-branch repo.

git switch -c fix/login-flake
# ... edit, commit ...
git switch main
git pull
git switch fix/login-flake
git rebase main
git switch main
git merge fix/login-flake

• Create two branches that edit the same line. Merge → resolve → commit.
• Try the same with rebase. Note when each is more readable.
• Read 5 random merge commits in a real repo; rate the messages.

git switch -c feat/cart-pom
# ... commits ...
git push -u origin feat/cart-pom
gh pr create --fill --base main
# review comes in...
git commit -m "address review: extract helper"
git push

• Fork a small open-source repo, fix a typo, open a PR.
• Read 3 well-reviewed PRs in a real repo; note what made the discussion productive.
• On your next PR, write the description before the code.

Trunk-based daily flow:
  main ─●─●─●─●─●─●─●─
            \   \   \
            f1  f2  f3   // each merged within hours

Gitflow:
  main    ─●───────●───────●─
  develop ─●─●─●─●─●─●─●─●─●─
              \  \      \  \
              f1 f2     f3 release/1.2

• Identify which workflow your team uses; document it in 1 paragraph.
• For one feature, sketch how it would flow through both workflows.
• Set up a feature-flag library; gate a small change behind it.

git revert <sha>                   # safe undo on shared branch
git reset --soft HEAD~1            # un-commit, keep changes staged
git reset --hard HEAD~1            # nuclear; lose changes
git reflog                         # find "lost" commits
git cherry-pick <sha>              # apply one commit elsewhere
git rebase -i HEAD~5               # squash/reorder last 5

• Revert a commit on a branch; observe the new "Revert ..." commit.
• Use git reset --hard to discard local work, then recover with reflog.
• Squash 4 WIP commits into 1 with interactive rebase.

## Why
Login intermittently fails on CI when the auth service responds slowly.
The current test asserts on URL before the redirect completes.

## What
- Replace fixed sleep with auto-retrying URL matcher
- Add screenshot+trace on failure
- Linked: TICKET-1234

## Test plan
- Ran the test 50x locally with throttled network — 0 flakes
- CI run: <link>

• Take your last PR; rewrite the description in the format above.
• Review one open PR in your repo with the lens "what's the smallest blocker?".
• Resolve a merge conflict on a branch end-to-end without using the GitHub UI.

git tag -a v1.2.0 -m "Release 1.2.0 — adds CSV import"
git push origin v1.2.0

# GitHub release with notes
gh release create v1.2.0 --generate-notes

# List by semver
git tag --sort=-v:refname | head

• Tag a commit; push the tag; verify it appears on GitHub.
• Create a GitHub Release with auto-generated notes.
• Add a CI step that tags on merge to main using a SemVer tool (e.g., release-please).

# .github/workflows/ci.yml
name: ci
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

• Read a real CI YAML in your repo. Identify trigger, jobs, steps, caches.
• Explain CI vs CD vs continuous deployment to a non-technical friend in 60 seconds.
• Sketch which stage each test type lives in (unit/integration/e2e).

on:
  push: { branches: [main] }
  workflow_dispatch:
    inputs:
      env: { type: choice, options: [dev, qa, prod] }

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: npm test
        env:
          TARGET_ENV: ${{ github.event.inputs.env }}

• Trigger a workflow manually with an input. Read the output.
• Find one failed run; classify: runner / build / test failure.
• Add a step that runs only on PR (if: github.event_name == 'pull_request').

jobs:
  e2e:
    runs-on: ubuntu-latest
    env:
      API_URL:    ${{ secrets.QA_API_URL }}
      AUTH_TOKEN: ${{ secrets.QA_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --reporter=junit,html
      - if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report
          path: playwright-report/

• Add a secret; reference it; print only its length to logs (never the value).
• Configure a JUnit-format report; upload as artifact; download and open it.
• Add a deliberately-failing test; verify the build goes red and the report shows the failure.

// Android
{
  platformName: 'Android',
  'appium:deviceName': 'Pixel_7_API_34',
  'appium:app': '/abs/path/app-debug.apk',
  'appium:automationName': 'UiAutomator2',
}

# Useful ADB
adb devices
adb install app.apk
adb shell pm list packages | grep myapp
adb logcat | grep MyApp

• Install Appium 2 + Android Studio. Boot an emulator. Run adb devices.
• Launch a sample app on the emulator via Appium with capabilities.
• Use adb logcat to find the package name of an installed app.

// Find by accessibility-id
await driver.$('~login-button').click();

// Swipe up (W3C actions)
await driver.performActions([{
    type: 'pointer', id: 'finger', parameters: { pointerType: 'touch' },
    actions: [
        { type: 'pointerMove', x: 500, y: 1500, duration: 0 },
        { type: 'pointerDown', button: 0 },
        { type: 'pointerMove', x: 500, y: 300, duration: 600 },
        { type: 'pointerUp', button: 0 },
    ],
}]);

• Open Appium Inspector against a running app; identify 3 elements by accessibility-id.
• Automate a tap, a long-press, and a swipe.
• Negotiate stable accessibility-ids with your dev team for the 5 most-tested screens.

// Switch to webview inside a hybrid screen
const ctxs = await driver.getContexts();
const webview = ctxs.find(c => c.startsWith('WEBVIEW'));
await driver.switchContext(webview);

// Simulate offline (Android)
await driver.setNetworkConnection(0);
// run a flow, assert offline UI shows
await driver.setNetworkConnection(6);  // wifi+data

• Toggle airplane mode mid-test; assert the offline state shows.
• Switch to webview in a hybrid screen; click an element inside it.
• Trigger an interrupt (incoming SMS via emulator command); verify the app recovers.

export class LoginScreen {
    constructor(private driver: WebdriverIO.Browser) {}
    user   = () => this.driver.$('~login-username');
    pass   = () => this.driver.$('~login-password');
    submit = () => this.driver.$('~login-submit');

    async login(u: string, p: string) {
        await this.user().setValue(u);
        await this.pass().setValue(p);
        await this.submit().click();
    }
}

• Refactor a flat mobile test into a Screen Object.
• Add a platform branch for one element that differs between iOS and Android.
• Build a scrollUntilVisible(label) helper in BaseScreen.

afterEach(async ({ driver }, info) => {
    if (info.status === 'failed') {
        await driver.saveScreenshot(`fail-${info.title}.png`);
        const source = await driver.getPageSource();
        fs.writeFileSync(`fail-${info.title}.xml`, source);
        // Android: pull logcat buffer
        execSync(`adb logcat -d > fail-${info.title}.log`);
    }
});

• Add screenshot + page source + logcat capture on failure.
• Configure video recording for one suite run.
• Trigger a deliberate failure; verify all artifacts upload to CI.

export class LoginPage extends BasePage {
    async login(u: string, p: string): Promise<DashboardPage> {
        await this.fill('#user', u);
        await this.fill('#pass', p);
        await this.click('button[type=submit]');
        return new DashboardPage(this.page);
    }
}

// Test reads like prose
test('admin sees user list', async ({ page }) => {
    const dashboard = await new LoginPage(page)
        .open()
        .then(p => p.login('admin', 'pw'));
    await expect(dashboard.userTable()).toBeVisible();
});

• Refactor 3 page objects to return the next page object on success actions.
• Extract a NavBar component object and reuse it across pages.
• Move shared waits to BasePage; delete duplicates.

actor.attemptsTo(
    Open.url("/login"),
    Enter.theValue("ada@x").into(LoginForm.EMAIL),
    Enter.theValue("pw").into(LoginForm.PASSWORD),
    Click.on(LoginForm.SUBMIT)
);
actor.should(seeThat(TheUrl.current(), containsString("/dashboard")));

• Read one Screenplay test aloud — verify it reads as English prose.
• Convert one POM-based test into Screenplay; compare lines & readability.
• Write a custom Task for "complete checkout".

public class DriverFactory {
    private static final ThreadLocal<WebDriver> DRIVER = new ThreadLocal<>();

    public static WebDriver get() {
        if (DRIVER.get() == null) DRIVER.set(new ChromeDriver());
        return DRIVER.get();
    }
    public static void quit() {
        if (DRIVER.get() != null) {
            DRIVER.get().quit();
            DRIVER.remove();
        }
    }
}

• Implement a thread-local driver holder; run 4 tests in parallel; verify isolation.
• Build a Config singleton that loads config.<env>.json once.
• Identify one singleton in an existing project that should be a fixture instead.

public class LoginPage {
    @FindBy(id = "user")     private WebElement user;
    @FindBy(id = "pass")     private WebElement pass;
    @FindBy(css = "button[type=submit]") private WebElement submit;

    public LoginPage(WebDriver driver) {
        PageFactory.initElements(driver, this);
    }
    public void login(String u, String p) {
        user.sendKeys(u); pass.sendKeys(p); submit.click();
    }
}

• Convert a manual Selenium-Java POM to use Page Factory annotations.
• Trigger a stale element scenario; observe and fix.
• Compare line count vs the manual approach; decide which you prefer.

# features/checkout.feature
Feature: Checkout
  Scenario: Successful purchase
    Given Ada is logged in
    When  she adds "X1" to her cart
    And   she completes checkout with a valid card
    Then  she sees an order confirmation

• Write 3 scenarios for a feature you own — read them with a non-engineer; iterate.
• Implement step definitions for one scenario.
• Decide for one team: is BDD paying for its overhead? Document the answer.

// 1. RED — failing test
test('discount of 10% on orders > $100', () => {
    expect(applyDiscount(120)).toBe(108);
});

// 2. GREEN — minimal code to pass
function applyDiscount(total: number) {
    return total > 100 ? total * 0.9 : total;
}

// 3. REFACTOR — extract a constant, add type, etc.

• Pick a small utility function. Write it TDD-style — test, code, refactor.
• Next bug you fix: write the failing test reproducing it before you fix.
• Try one Kata (e.g., Roman Numerals, FizzBuzz) entirely TDD.

@ParameterizedTest
@CsvSource({
    "100, 100",
    "120, 108",
    "200, 180"
})
void applyDiscount(int input, int expected) {
    assertEquals(expected, Cart.applyDiscount(input));
}

• Set up JUnit 5 in a Maven project; run a parametrised test from @CsvSource.
• Configure parallel execution; verify thread isolation.
• Write a custom JUnit 5 Extension that takes a screenshot on failure.

@pytest.mark.parametrize("input,expected", [
    (100, 100),
    (120, 108),
    (200, 180),
])
def test_apply_discount(input, expected):
    assert apply_discount(input) == expected

• Pick the framework matching your project's language. Set up a parametrised test.
• Configure parallel/sharded execution.
• Add one fixture (pytest) or hook (Mocha/Jest) that captures a screenshot on failure.

import { Given, When, Then } from '@cucumber/cucumber';

Given('Ada is logged in', async function () {
    await this.loginPage.login('ada@x', 'pw');
});

When('she adds {string} to her cart', async function (sku) {
    await this.productPage.addToCart(sku);
});

Then('she sees an order confirmation', async function () {
    await expect(this.page.locator('.confirmation')).toBeVisible();
});

• Set up Cucumber + Playwright (or SpecFlow + Selenium for .NET); run one scenario.
• Reuse a step definition across two scenarios; verify ambiguity warnings if regex collides.
• Generate an HTML/Allure report; share with a non-engineer for feedback.

// Prompt
"Write a Playwright test for a login page with email,
 password, and a submit button. Assert the URL
 changes to /dashboard."

// LLM output (sketch)
test('login redirects to dashboard', async ({ page }) => {
    await page.goto('/login');
    await page.fill('input[type=email]', 'a@x.com');
    await page.fill('input[type=password]', 'pw');
    await page.click('button[type=submit]');
    await expect(page).toHaveURL(/\/dashboard/);
});
// You verify selectors match the real page.

• Read the linked Anthropic intro. Define ML / DL / LLM in your own words.
• Ask an LLM to write a test for a real page you control. Run it. Note what it got wrong.
• Identify one task where AI saved you 20+ minutes this week.

// Copilot (inline): you type a JSDoc, ghost-text completes
/** Click each row's edit icon and assert it opens a modal */
test('edit row opens modal', async ({ page }) => { /* ... */ }

// Cursor / Copilot Chat: select code, /test, "add a test"
// Claude Code (CLI): "add a Playwright test that verifies
//   the edit button on /users opens a modal with role=dialog"

• Install Copilot in VS Code. Use it for an hour on real test code. Note one save and one mistake.
• Try the chat panel; give it a 50-line file and ask it to refactor.
• Compare the same prompt across two tools; observe which needed less correction.

BEFORE COMMITTING AI CODE
[ ] Compiles / type-checks
[ ] All asserted APIs actually exist (read the import)
[ ] No string-concatenated SQL or HTML
[ ] Secrets aren't hardcoded
[ ] Same logging / error patterns as the rest of the codebase
[ ] Tests pass — including a new one for the changed path
[ ] License of any copy-pasted snippet is compatible

• Ask an AI for a "secure" auth helper. Audit it against the OWASP cheat sheet.
• Find one hallucinated API call in your AI history. Save the example.
• Run a license scanner (FOSSA free tier) on a small AI-assisted project.

# Claude Code — refactor a flaky suite
> read tests/login.spec.ts and tell me why this is flaky
> show me other suites in this repo that have the same issue
> refactor them all to use the auto-retrying matcher pattern
> run the suite and report failures
> commit with message: "fix: replace manual waits with auto-retry"

• Use Cursor Composer or Claude Code for one multi-file refactor. Read every diff before accepting.
• Use Copilot's "Workspace" or chat with @workspace context to ask about an unfamiliar repo.
• Set up a CLAUDE.md / .cursorrules with your project's conventions; verify the agent respects them.

// Prompt
"Open https://my-app.dev/checkout in your tools, snapshot the
 DOM, and generate a Playwright Page Object in TypeScript with:
 - private locators using getByRole/getByLabel
 - actions: fillCard, submit
 - returns ConfirmationPage on submit
 Match the style in pages/LoginPage.ts (attached)."

// You then: review locators, run the test, fix anything stale.

• Generate a page object for one screen with AI. Audit every locator.
• Generate test data (50 plausible users) as JSON; spot-check for duplicates.
• Convert a 10-test suite from manual waits to auto-retrying matchers via AI; review every diff.

"Playwright test fails on CI but passes locally:

  test('cart updates', async ({ page }) => {
      await page.click('.add-to-cart');
      expect(await page.locator('.cart-count').textContent()).toBe('1');
  });

CI error: 'Expected 1, received 0' on line 4.
Locally: passes 10/10 runs.
What I've ruled out: the selector matches (verified in DevTools).

Give me 5 hypotheses ranked by likelihood, with the smallest
investigation step for each."

• Take a recent flaky failure. Paste error + code + ruled-out into AI; rank the hypotheses against your own.
• Paste a 100-line failing log; ask AI to identify the first interesting line.
• For one bug, document the 3 wrong hypotheses AI suggested before the right one — sharpens prompting.

// VAGUE
"write a login test"

// SPECIFIC
"Write a Playwright test in TypeScript for our LoginPage POM
(pages/LoginPage.ts). It should:
- visit /login
- call loginPage.login(adaUser.email, adaUser.password)
- assert URL matches /dashboard
- assert .toast--success is visible
Use only existing helpers; don't add new dependencies."

• Take a vague prompt you wrote and rewrite it with the 4 elements above.
• Run both versions; diff the outputs.
• Save the best 3 prompts you write this week as templates.

"This Playwright test is flaky on CI but passes locally:

test('cart updates', async ({ page }) => {
    await page.click('.add-to-cart');
    expect(await page.locator('.cart-count').textContent()).toBe('1');
});

Error on CI: 'Expected 1, received 0'.

Why is it flaky? Show the fix using auto-waiting assertions."

• Use each pattern once today on real test code.
• Take a recent bug; ask AI to explain the root cause from the diff. Compare to your own analysis.
• Build 1-line shortcut prompts: /refactor, /explain, /test-this.

// AI suggested:
await page.locator('role=button[name="Save"]').click();

// You ask:
"Why role= over a CSS selector? When would CSS be better?"

// Now you actually understand role-based locators —
// the next time you'll choose, not copy.

• Pick one AI suggestion you accepted last week. Find the docs for every API it used.
• Replace one AI suggestion with a simpler one you wrote yourself. Compare readability.
• Keep a notebook: 1 line per useful pattern AI taught you each week.

"Refactor this test to:
- Use Playwright auto-retrying matchers (no `await ... .textContent()`)
- Replace `page.locator('css...')` with `getByRole` / `getByLabel`
   where roles are clear
- Keep the assertion semantics identical
Match the style in pages/LoginPage.ts (attached).

[paste current test]

Output: only the modified file, no commentary."

• Build a "framework prompt" template for your stack (1 paragraph) — reuse it everywhere.
• Refactor 3 tests with the template; compare diffs to your manual fixes.
• Generate a new test from a 1-sentence description that includes the framework prompt.

"Convert each test name to our convention.

Examples:
  test('it should login')        → test('logs in with valid credentials')
  test('check 404 on bad id')    → test('returns 404 for unknown order id')
  test('login broken')           → test('shows error for invalid password')

Now convert:
  test('add to cart works')
  test('admin only')
  test('save fails when offline')"

• Pick a tricky transformation in your codebase. Write a 3-shot prompt; verify accuracy.
• Use "list 3 hypotheses, then recommend one" on a real bug.
• Compare zero-shot vs few-shot output for the same task; note quality difference.

"Write a GitHub Actions workflow .github/workflows/e2e.yml:
- Triggers: push to main, PR
- Node 20, Ubuntu latest
- Install deps with `npm ci`
- Install Playwright browsers
- Run `npx playwright test --reporter=junit,html`
- On failure, upload `playwright-report/` as an artifact
- Pass secrets QA_API_URL, QA_TOKEN as env vars
Output the YAML only, no commentary."

• Build a 5-prompt library covering: framework setup, API tests from OpenAPI, POM scaffolding, CI YAML, test data.
• Run each on a fresh dummy project; refine until output requires no edits.
• Share your library with one teammate; iterate based on feedback.

// BARE
"Write a Playwright test for the cart"

// CONTEXT-RICH
"Project structure:
  pages/CartPage.ts (POM with addItem, getCount, checkout)
  fixtures/users.json (uses ada@x.com, role: admin)
  playwright.config.ts (baseURL, no implicit waits)
  package.json (Playwright 1.45, TS 5.4)

Existing CartPage methods:
  await cart.addItem(sku);
  expect(await cart.getCount()).toBe(N);

Write a test that adds 3 distinct SKUs and asserts count is 3."

• Write a prompt for a real change with no context. Save the output.
• Write the same prompt with 3 files of context. Diff the quality.
• Identify the minimum file set the AI needed (often 2-3 files).

# CLAUDE.md / .cursorrules

## Stack
- Playwright 1.45 + TypeScript, POM in `pages/`
- Tests in `tests/`, fixtures in `fixtures/`
- No `Thread.sleep` — use `expect(...).toBeVisible()` style

## Conventions
- File names: kebab-case
- Locators: prefer `getByRole`, fall back to CSS, avoid XPath
- One assertion per behaviour; meaningful messages

## Don't
- Don't add new dependencies without asking
- Don't write comments that just restate code

• Write a 1-page rules file for your project. Test it with 3 prompts.
• Reference 2 files in a prompt explicitly; compare to a no-context run.
• Add a 3-bullet "architecture" header to your standard prompt template.

# ARCHITECTURE.md

This is an SDET test repo for the Acme product.

- `tests/api/` — Playwright API tests (smoke + regression)
- `tests/e2e/` — Browser E2E using POM in `pages/`
- `pages/`    — One file per page; extends BasePage
- `fixtures/` — Per-test setup (uses Playwright fixtures pattern)
- `clients/`  — Typed API clients used by both API tests and E2E setup

Run: `npm test`         (everything)
     `npm run smoke`    (PR gate)
     `npm run e2e`      (nightly)

• Write a 1-page ARCHITECTURE.md for your repo. Test by asking an AI to describe the project back.
• Find one inconsistent folder/naming pattern; fix it.
• Use @workspace or codebase indexing on a real change; observe what context the agent picked.

"Update CartPage.checkout() to take an optional couponCode.

Files involved:
  - pages/CartPage.ts   (the method)
  - tests/checkout.spec.ts (existing test — update to pass undefined)
  - tests/coupon.spec.ts   (NEW — verify discount applies)

Update all three in one diff. Match existing styles in each file."

• Pick a small change touching 3 files. Write one prompt that updates all three; verify the diffs.
• Find one PR you wrote where the AI missed a caller — write the prompt that would have caught it.
• Build a "test/page/fixture trio" prompt template and reuse for next 3 features.

"Attached: openapi.yaml (full spec for our orders API).

Generate Playwright API tests in tests/api/orders/ covering:
- Happy path for each endpoint
- 400 / 401 / 403 / 404 / 422 cases per the spec's responses
- One schema-validation test per endpoint using zod

Use our base client `clients/orders.ts` (also attached).
Output: one .spec.ts file per endpoint, no commentary."

• Generate API tests from your team's OpenAPI spec; review what the AI got right and wrong.
• Where the spec was wrong, file a docs ticket — that's value the AI surfaced.
• Pair a feature file with a prompt to generate step definitions; review for accuracy.