🗓️ 14-Day Automation QA Prep Plan

// STUDY

• The automation pyramid: what lives at unit, integration, and UI layers — and why misplacing tests costs you
• What makes a good automation target: stable selectors, deterministic outcomes, high-value user journeys
• Test isolation principles: independent tests, no shared mutable state, atomic setup
• The Automation QA interview scope: rounds, question themes, and what interviewers actually grade

// PRACTISE

• Read the role page and identify the 3 topic areas where your current knowledge is weakest
• Write 5 test cases for a login form — happy path, wrong password, empty fields, account locked, SQL injection attempt — to warm up test-design thinking
• List 3 features from any app you know that are NOT worth automating and write a one-sentence justification for each

// STUDY

• Playwright: auto-waits, web-first locator API (getByRole, getByTestId, getByLabel), and expect assertions
• Cypress: command queue mechanics, cy.intercept() for network stubs, and web-first assertions
• Locator stability: ARIA roles and data-testid as first choice; why text and CSS class locators break
• Running headless and reading the failure output: stack trace, screenshot, and trace context

// PRACTISE

• Install your framework and scaffold a TypeScript project from scratch (no boilerplate generators)
• Write a login test for a public demo app: assert on the success state, the URL, and one visible element post-login
• Deliberately break your locator to produce a failure — read the trace or screenshot and fix it

// STUDY

• Page Object Model: separating locators and actions from assertions and test flow
• Fixture factories: creating typed test data builders to keep tests readable and decoupled
• Shared fixtures: reusing authentication state so tests don't re-log-in on every run
• Data-driven tests: parameterising the same spec over multiple input sets

// PRACTISE

• Refactor your Days 3–5 tests into at least 2 page objects with typed action methods
• Add a shared authentication fixture so downstream tests start already logged in
• Write one parameterised test covering 3 input variations using the framework's test.each or data table

// STUDY

• REST API testing in your framework: sending requests, asserting status codes, validating JSON response bodies
• Chaining requests: extracting a token or ID from one response and passing it into the next
• GitHub Actions: trigger on push, install dependencies, run tests in parallel, upload the HTML report
• Reading a failing pipeline: where to find the error, how to reproduce it locally

// PRACTISE

• Write 3 API tests against a public REST API (e.g. reqres.in or jsonplaceholder.typicode.com): GET list, POST create, DELETE and assert 204
• Set up a GitHub Actions workflow file that installs, runs your full suite on push, and uploads the Playwright/Cypress HTML report as an artifact
• Trigger a deliberate CI failure and fix it from the GitHub Actions log alone — practice diagnosing pipeline errors without a local environment

// STUDY

• Cypress and Playwright banks: focus on questions about auto-wait, network interception, parallel execution, and debugging flakes
• Framework design bank: POM trade-offs, selector strategies, fixture patterns, test isolation
• CI/CD bank: pipeline triggers, parallel sharding, artifact management, failure triage
• Behavioural bank: flaky test escalation, legacy codebase with no tests, stakeholder communication

// PRACTISE

• Answer 10 questions aloud from the banks — time yourself at 90 seconds per answer
• Identify your 5 weakest answers and write a worked example for each, referencing your own test suite
• Ask a colleague or friend to run a 30-minute mock using questions from the banks