🗓️ 30-Day QA → SDET Prep Plan

// STUDY

• Where manual testing transfers directly: test case design, equivalence partitioning, boundary thinking, defect lifecycle understanding, and exploratory instincts — these are genuine advantages over candidates who can code but cannot test, and you should be able to articulate this clearly and confidently
• JavaScript fundamentals: const and let, primitive types, functions, arrow functions, template literals, and conditionals — the building blocks every Cypress and Playwright test uses, and the syntax you need to internalise before the framework makes sense
• Arrays and loops: for...of, forEach, map, filter, and find — how to work with collections of test data programmatically rather than copying and pasting the same test case with different values
• Why automation is your test cases in code: a Cypress test is still 'given a condition, when I do something, then I assert a result' — the instinct is identical to what you already do; the syntax is new

// PRACTISE

• Read the QA → SDET role page and write 3 sentences explaining how your current manual testing experience is an asset in an automation interview — practise saying this aloud until it sounds confident and natural, not defensive
• Open VS Code and write 10 small JavaScript functions from scratch — do not paste, type every character: a function that checks whether a number falls in a valid range, one that filters a list of test results to only PASS entries, one that generates a test email address with a timestamp — these build the muscle memory the framework requires
• Take 5 manual test cases you have written before and rewrite each as a JavaScript function stub (no framework yet): describe what each function would take as input and return as output — this deliberately bridges manual test thinking to code thinking before any tool is involved

// STUDY

• async/await and Promises: what asynchronous code means in practice, why Playwright uses async/await throughout, why Cypress abstracts it away behind its command queue, and the most common beginner mistake — forgetting to await a Promise and wondering why the assertion runs before the page has loaded
• Working with objects and JSON: dot notation, destructuring, optional chaining (?.), JSON.parse and JSON.stringify — because API responses, fixture files, and test configuration are almost always JSON in a real automation project
• Reading others' code: how to approach an unfamiliar test file without being overwhelmed — read the describe block first, then each it block, then the helper functions — this skill matters when an interviewer asks you to extend an existing test suite you have never seen before
• Basic error handling: try/catch for expected failures, understanding a stack trace to find where an error originated, and the difference between a test assertion failure (expected behaviour you chose to check) and a runtime error (something your code did not anticipate)

// PRACTISE

• Extend your practice repository with 5 async functions: one that fetches data from a public API (e.g. jsonplaceholder.typicode.com/users) and returns the response as a parsed array, one that retries a simulated flaky operation up to 3 times using a loop and async/await, and 3 smaller exercises applying destructuring and optional chaining to JSON objects
• Find an open-source Cypress or Playwright project on GitHub and spend 30 minutes reading the tests without running them — note 3 things you understand and 3 things you do not, then look up the unfamiliar ones; this is the skill of working in an existing codebase
• Write a plain-English explanation of what async/await does and why it matters in test automation — if you can explain it clearly in 3 sentences to someone who does not code, you understand it well enough to answer an interview question about it

// STUDY

• Project setup: installing Cypress or Playwright in a fresh TypeScript project, folder structure (tests, support, fixtures), running in headed mode to watch tests, running headless for CI, and reading the failure output — screenshot, video, or Playwright trace
• Stable selectors: getByRole(), getByTestId(), getByLabel() in Playwright; cy.get('[data-testid=]') in Cypress — why these are more resilient than XPath and CSS class selectors, and why interviewers ask about locator strategy specifically in every automation round
• Meaningful assertions: toBeVisible(), toHaveText(), toHaveValue() in Playwright; .should('be.visible').and('contain.text', ...) in Cypress — asserting on what the user sees and can interact with, not on implementation details like class names or element IDs that developers change without warning
• The test lifecycle: beforeEach for setting up a clean state, afterEach for teardown, and how to share data between steps without global variables that make tests order-dependent

// PRACTISE

• Install your chosen framework in a fresh TypeScript project and write a login test against a public demo app (saucedemo.com works well): locate the username field, enter credentials, click Login, and assert the products page heading is visible — use stable selectors throughout, no XPath
• Add 3 more tests to the same suite: a failed login with a wrong password (assert the correct error message), an empty-field submission (assert the required field validation message), and a logout flow — 4 tests total, all green, all using the framework's built-in assertions
• Deliberately break one test by replacing a stable selector with a brittle XPath locator — run the test until it fails inconsistently or fails cleanly, read the failure output fully, then restore the stable selector and note what the failure output told you that guided the fix

// STUDY

• Page Object Model: separating selectors and actions from test assertions — a LoginPage class with login(email, password) and getErrorMessage() methods, where tests call the method but never touch a raw selector — the most common framework design question in automation interviews
• Fixtures and test data: externalising credentials, expected values, and test inputs into fixture files rather than hard-coding them in test files — so that when an environment changes, you update one file instead of hunting through every test
• Network mocking: intercepting API calls in Cypress with cy.intercept() or in Playwright with page.route() to isolate UI tests from unstable back-end state — this is where your manual testing instinct for 'what if the server returns an error?' becomes a concrete coded test
• TypeScript basics for automation: interfaces for typed test data, import and export between modules, and understanding that TypeScript errors at compile time are a safety net, not an obstacle — they tell you about a problem before the browser does

// PRACTISE

• Refactor your Days 11–16 test suite into a Page Object Model: create a LoginPage class with typed action methods and move every selector into it — tests should import only the page object and call login() and getErrorMessage(), with no raw selectors visible in the test file
• Externalise your test credentials into a fixture file and load them using the framework's fixture mechanism — verify all tests still pass after the move, and note how the refactored test file reads compared to the original
• Add one network-mock test: in your Cypress or Playwright suite, intercept the login API call and return a 500 error response, then assert that the correct user-facing error message appears — your manual 'what happens when the server fails' instinct, expressed as a coded test

// STUDY

• Git daily workflow: clone, branch (git checkout -b feature/my-change), add, commit with a meaningful message, push, and open a pull request — this loop is how every engineering team on every automation project works, and interviewers ask about it as a proxy for team-readiness
• Branching and pull requests: feature branches vs committing directly to main, what a pull request is for (review, CI check, shared history), and why your GitHub repository's commit history is evidence of a real engineering habit, not just proof of attendance
• GitHub Actions basics: creating a workflow YAML file that runs your Cypress or Playwright suite on every push, installs Node dependencies, runs tests in headless mode, and uploads the HTML report as a downloadable artifact
• Reading a failing CI pipeline: where to find the error in the GitHub Actions log, how to reproduce the failure locally, and the most common CI failure modes — a missing environment variable, a different Node version, or tests running from the wrong working directory

// PRACTISE

• Set up your repository with a proper Git workflow: create a feature branch for your CI work, make the changes on that branch, commit with a descriptive message ('feat: add GitHub Actions workflow for headless test run'), push the branch, and merge via pull request — not directly to main
• Create a GitHub Actions workflow YAML file that runs your Cypress or Playwright suite on push to main: installs dependencies, runs in headless mode, and uploads the Playwright HTML report or Cypress video as a downloadable artifact
• Trigger a deliberate CI failure — break a test assertion — and fix it using only the GitHub Actions log output without running locally; practise treating the pipeline log as your primary debugging tool, because that is what working on a real team requires

// STUDY

• Your transition narrative: why you are making the switch, what you have built (your GitHub repository is the evidence — reference specific tests, the POM structure, and the CI pipeline), and how your manual background gives you a testing advantage over candidates who can code but cannot test — this is a 2-minute opening answer, not a rambling explanation
• Behavioural and motivation questions: 'show me something you built', 'what is your biggest current gap', 'how do you handle not knowing the answer in a coding screen' — practise the structure of the answer, not a memorised script
• Manual testing bank: interviewers for switcher roles often open with your fundamentals — equivalence partitioning, defect lifecycle, exploratory heuristics — to confirm the testing base is strong before assessing the code; do not let the coding prep crowd out your core testing answers
• JavaScript and TypeScript banks: arrow functions, array methods, async/await, reading a TypeScript type error — at the level a lightweight coding screen expects from a transitioner rather than a senior engineer

// PRACTISE

• Answer 10 questions aloud from the manual testing, JavaScript, and TypeScript question banks — for each answer, connect it to either your testing background or something specific in your GitHub repository; never answer in the abstract when you have a concrete artefact to reference
• Identify your 5 weakest answers and write a worked example for each: grounded in specific code you wrote, a test you designed, or a manual testing situation where your QA instinct shaped a better outcome than a pure coder would have achieved
• Run a 30-minute mock coding screen: given a small Cypress or Playwright test file with 2 bugs (a broken selector and a wrong assertion), fix both under time pressure, then add 1 new test — time yourself and debrief on where you slowed down and why