The 90-Day Plan to Land Your First QA Job

Most QA learners spend months on tutorials and reach day 90 with concepts but no portfolio. This plan structures 90 days around concrete deliverables: a working Playwright test by week 4, a 20+ test suite with GitHub Actions CI by week 8, and active job applications by week 12.

Days 1–30: Foundation

The goal of the first month is not to become an expert. It's to get comfortable with the vocabulary and mindset of QA, understand what test cases and bug reports actually look like in a real team, and write your first working Playwright test. You'll do all of this in parallel: manual testing concepts in the first two weeks, automation starting in week three, so that by day 30 you've touched everything you'll be building on.

Week 1: Manual testing fundamentals

Spend the first week understanding what structured testing looks like. The key output of manual QA work is the test case: a documented set of steps, preconditions, expected results, and actual results. Write five test cases for the login flow at lab.becomeqa.com by hand in a Google Sheet or Notion doc. Use columns for: Test Case ID, Precondition, Steps, Expected Result, Actual Result, and Status.

Don't make the steps vague. "Go to the login page, enter the email admin@becomeqa.com, enter a wrong password, click Submit, verify the error message reads 'Invalid credentials'" is a test case. "Check that login works" is not. Precision is the entire skill.

Once you've written the login test cases, write five more for the items list: verify items load, verify the count matches what the API returns, verify sorting works, verify the search filters results, verify an empty search shows a meaningful empty state. You'll run each of these manually and log any bugs you find.

When you find a bug (and you will), write it up as a formal bug report. A minimal bug report has a title, environment (browser, OS), preconditions, steps to reproduce, expected behavior, actual behavior, and severity. Severity is not how annoyed you are. Critical means the app is broken for all users. Major means a core feature doesn't work. Minor means something looks wrong but doesn't block anything. Trivial means a typo.

Week 2: Agile basics and the QA mindset in a team

Real QA work happens inside Agile sprints. Spend this week learning how QA engineers fit into that process. You need to understand what a user story is and how acceptance criteria relate to test cases, what "definition of done" means and why QA is part of it, and what a sprint review looks like from a QA perspective.

The practical exercise: take three user stories from a public project management board (Trello templates work, or write your own based on the lab.becomeqa.com features) and write acceptance criteria for each. Then convert those acceptance criteria into test cases. This is the actual flow in a real job: story comes in, you write tests for it before development finishes, then verify it when the developer says it's done.

Read up on the difference between verification (did we build the thing right?) and validation (did we build the right thing?). These terms come up in interviews.

Weeks 3–4: Start Playwright

Install Node.js (LTS version) and create a new Playwright project with npm init playwright@latest. Choose TypeScript when prompted. Playwright will scaffold a folder structure and a sample test. Run npx playwright test and watch it pass. That folder structure (tests/, playwright.config.ts, package.json) is what you'll be building on for the next two months.

Your first test to write from scratch is a login test against lab.becomeqa.com:

import { test, expect } from '@playwright/test';

test('login with valid credentials shows dashboard', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('My Travel Items')).toBeVisible();
});

Run it with npx playwright test --headed to watch the browser open and fill in fields on its own. This is the moment that hooks most people. Then write two more tests: one for invalid credentials (assert the error message appears), one for logging out (assert the login button is visible again). By the end of week 4 you should have six to eight passing tests and a feel for how Playwright thinks about pages.

Days 31–60: Automation Skills

Month two is where the real work happens. You'll go deep on Playwright, learn locator strategies, write assertions with confidence, implement Page Object Model, get comfortable with Git and GitHub, and hit a concrete target: 20 or more real tests against lab.becomeqa.com. This is the material that technical interviewers will ask about.

Week 5: Locators and assertions

Playwright gives you multiple ways to find elements on a page. The right hierarchy, from most preferred to least: getByRole, getByLabel, getByPlaceholder, getByText, getByTestId, and then CSS selectors as a last resort. The reason for this order is resilience. Role-based and label-based locators still work when a developer renames a CSS class or changes a div to a section. CSS selectors break.

Spend week 5 writing locators for every major element on lab.becomeqa.com using the preferred methods. Use npx playwright codegen https://lab.becomeqa.com to see how Playwright identifies elements as you click around. Then rewrite every locator it generates into the preferred format by hand. This is a deliberate practice exercise. The codegen output often uses CSS selectors, and you want to build the habit of choosing better options.

For assertions, practice both the "soft" and "hard" varieties. A hard assertion (expect(locator).toBeVisible()) stops the test immediately if it fails. A soft assertion (expect.soft(locator).toBeVisible()) logs the failure but keeps the test running to catch more issues in one pass. Use soft assertions when you want to check a whole page state at once; use hard assertions when a failure means nothing else in the test can be trusted.

Week 6: Page Object Model

By this point your tests are probably getting repetitive. Every test that needs a logged-in user repeats the same four lines. Page Object Model (POM) eliminates that duplication and makes your tests read like documentation.

Create a pages/ folder. Start with two files: LoginPage.ts and ItemsPage.ts.

// pages/LoginPage.ts
import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async navigate() {
    await this.page.goto('https://lab.becomeqa.com');
  }

  async login(username: string, password: string) {
    await this.page.getByRole('button', { name: 'Login' }).click();
    await this.page.getByLabel('Username').fill(username);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Submit' }).click();
  }

  async getErrorMessage() {
    return this.page.getByRole('alert').textContent();
  }
}

// pages/ItemsPage.ts
import { Page, Locator } from '@playwright/test';

export class ItemsPage {
  readonly itemRows: Locator;

  constructor(private page: Page) {
    this.itemRows = this.page.getByRole('row');
  }

  async getItemCount() {
    return this.itemRows.count();
  }

  async searchFor(term: string) {
    await this.page.getByPlaceholder('Search').fill(term);
  }
}

Rewrite all your existing tests to use these classes. A test that used to be twelve lines of setup becomes four. More importantly, if the login button's label changes tomorrow, you fix it in one file instead of twenty.

Week 7: Git and GitHub

You've been writing code for a month. Now you need to version-control it properly and put it somewhere visible. Install Git if you haven't. Create a GitHub account. Push your Playwright project as a public repository.

The Git workflow you need for a job: git status to see what changed, git add to stage specific files, git commit -m "message" to save a snapshot, git push to upload. For this stage you're working alone so you don't need branching workflows yet. But practice it anyway: make a feature branch with git checkout -b add-items-tests, write your tests there, commit them, and merge with git checkout main && git merge add-items-tests. This is how every team you'll ever work on operates.

Write a README for your repository. It doesn't need to be long. Tell readers what the project is, how to install dependencies (npm install), how to run the tests (npx playwright test), and what site you're testing against. A README that exists and has working instructions is better than most junior portfolios already.

Week 8: 20+ tests and API coverage

This is the execution week. Your goal is to reach 20 or more passing tests against lab.becomeqa.com. That sounds like a lot. It isn't. Between login flows, items CRUD operations, search, filtering, and the API endpoints, there's easily 40 scenarios worth testing.

For API testing, Playwright has it built in. No separate tool needed:

import { test, expect } from '@playwright/test';

test('GET /api/items returns a list with required fields', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

  expect(response.status()).toBe(200);

  const items = await response.json();
  expect(items.length).toBeGreaterThan(0);
  expect(items[0]).toHaveProperty('id');
  expect(items[0]).toHaveProperty('destination');
});

Write at least five API tests: a happy-path GET, a POST that creates an item, a DELETE that removes it, a test for authentication (what happens if you call the API without a token?), and one that validates the shape of the response matches what the UI displays. Mix your API tests and UI tests into the same test suite. That's how real projects are structured.

Days 61–90: Portfolio and Job Search

Month three is about converting everything you've built into something that gets you hired. You'll set up CI so your tests run automatically, write a professional README, polish your LinkedIn profile, and start applying. The job search and the learning run in parallel. Don't wait until day 90 to send your first application.

Week 9: GitHub Actions CI

A test suite that only runs on your laptop is worth less to a hiring manager than one that runs in the cloud on every commit. Set up GitHub Actions by creating a file at .github/workflows/playwright.yml:

name: Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Push this file. Watch the Actions tab in your GitHub repo. You should see a workflow trigger and your tests run in a Linux container. When they pass, you'll see a green checkmark next to your latest commit. That green checkmark is something you can screenshot and put in your LinkedIn posts. It's also concrete evidence that you understand CI, a question that comes up in nearly every technical interview.

If some tests are flaky in CI (they pass locally but fail intermittently in the pipeline), that's an important lesson on its own. Flaky tests usually fail in CI because of timing: the page loads more slowly on a cloud machine than on your laptop. The fix is almost always to replace hard waits (page.waitForTimeout(2000)) with proper Playwright waiting (page.waitForSelector, or just trusting that Playwright assertions auto-wait). Track down every flaky test and fix it. A CI run with one red flaky test is worse than a CI run with 15 tests instead of 20.

Week 10: Polish the portfolio

Your GitHub repository needs three things before you start applying: a test count worth mentioning (20+), a CI badge in the README, and documentation that a stranger can follow.

Add a CI badge to your README by copying the badge URL from your GitHub Actions workflow. It looks like this in Markdown:

![Playwright Tests](https://github.com/YOUR_USERNAME/YOUR_REPO/actions/workflows/playwright.yml/badge.svg)

When the tests pass, this badge shows green in your README. It's a small detail that signals you care about professional practices.

Expand your README to include a project description, what you're testing and why (lab.becomeqa.com is a practice application for QA engineers), a table listing each test file and what it covers, and how to run specific test groups with npx playwright test --grep @api (add tags like @api and @ui to your tests to enable this). The goal is that someone who has never seen your project can clone it, run it, and understand what they're looking at in under ten minutes.

Week 11: LinkedIn and resume

Your LinkedIn profile needs four things to attract QA recruiter attention: a headline that says what you're targeting ("QA Automation Engineer | Playwright | TypeScript"), an About section of 3–4 sentences that explains your transition into QA and what you've built, a Featured section with a link to your GitHub repository, and a Skills section listing Playwright, TypeScript, JavaScript, Git, GitHub Actions, API Testing, and Agile.

If you're coming from another field, don't hide it. Frame it as an asset. "Background in customer service gave me a different perspective on how real users interact with software" is more interesting than pretending you've always been in tech.

For your resume, list the GitHub portfolio project as an experience entry, not a side note. Write it like this: "Playwright Automation Framework (Personal Project): built a test suite with 25+ UI and API tests against a live web application using TypeScript and Playwright. Configured CI/CD pipeline with GitHub Actions. Implemented Page Object Model for maintainability." Every word there is true, specific, and maps directly to what job postings ask for.

If you have no professional QA experience, your resume is two sections: the portfolio project and your previous work experience framed around transferable skills (attention to detail, process orientation, communication, technical work if any). Keep it to one page.

Week 12: Apply and keep going

Start applying before you feel ready. You felt unready at day 30, at day 60, and you'll feel unready at day 90. The way to know what gaps you have is to get into interviews and see what they ask. A rejection after a technical screen where you couldn't answer a question about fixtures or test data management tells you exactly what to study next. That's valuable.

Apply to 5–10 companies in week 12. Prioritize companies with smaller QA teams (you'll learn more and have more ownership), companies whose products you actually use (genuine interest comes through in interviews), and companies explicitly hiring junior automation engineers (not just "QA analyst" roles that are purely manual).

After each interview, write down every question you couldn't answer. Spend an hour on each topic the following day. You will interview better the second time than the first, and better the third time than the second.

FAQ

Twenty is the floor. Thirty to forty is solid. You don't need more than that. The point is to demonstrate breadth (UI tests, API tests, POM, CI), not volume. Five tests that cover login, items list, one API endpoint, and show Page Object Model is more impressive than fifty copy-pasted login tests.

Most modern Playwright projects use TypeScript. You don't need to be a TypeScript expert. The static typing helps more than it hurts. Start with TypeScript from day one, let your editor tell you when types are wrong, and look up what the error means. That's 90% of how you learn it.

If your application volume is under 30 and you've been applying for less than four weeks, it's too early to draw conclusions. If you're past 30 applications with no response, the issue is usually the resume or the LinkedIn profile, not your skills. Have someone in a QA or tech role review your resume. Join QA communities on LinkedIn and Discord. People in those communities often share open roles and can refer you internally, which bypasses the resume stack entirely.

Not instead of the portfolio, ever. If you have spare time in month one while the technical concepts are still light, reading the ISTQB Foundation Level syllabus is useful for vocabulary. But a working GitHub portfolio with CI is harder evidence of your abilities than any certification. Hiring managers who tell you otherwise are in the minority.

Keep applying and keep building. Add a second portfolio project. Write tests against a different application. Many open-source projects accept contributions that include tests, which gives you real collaborative experience. Start a simple technical blog documenting what you learned; even two or three posts about specific problems you solved signals that you can communicate technical ideas. The 90-day plan gets you to the starting line, not the finish line. Most people get their first QA offer between month 4 and month 6.