QA Tester Portfolio Tips for Complete Beginners — 2026

QA · Portfolio · Beginners · 2026

QA Tester Portfolio Tips for Complete Beginners — 2026

SECTION 01Pillar 1 — bug reports

A bug report is the single most important artefact for a manual QA candidate. It shows you can think like a tester and communicate clearly. Ten great reports are worth more than fifty mediocre ones.

What a great bug report contains

• Title — specific and searchable: "Login fails when password contains emoji" beats "Login bug".
• Environment — browser, OS, device, app version. Anything a developer would need to reproduce.
• Preconditions — login state, user role, data setup.
• Steps to reproduce — numbered, precise, one action per step.
• Expected behaviour — what should have happened.
• Actual behaviour — what did happen, with a screenshot or short video.
• Severity vs priority — High severity / Medium priority, with a one-line justification.
• Evidence — a screenshot, a screen recording, a console log. Every report should be independently verifiable.

Where to find bugs as a beginner

• Public test sites that are designed for practice — SauceDemo, DemoQA, ParaBank, OrangeHRM demo.
• Open-source web apps — browse the issue tracker, then try to find similar bugs and document them cleanly.
• Real sites you use — but report responsibly via a bug bounty or contact page, and never share data that isn't yours.

# Bug report format (Markdown) — a template for your GitHub repo

## Title
Login fails when password contains emoji

## Environment
- Browser: Chrome 120.0.6099.109 (Windows 11)
- App: saucedemo.com, build: production
- User: standard_user

## Preconditions
- User is on the login page
- User is not logged in

## Steps to reproduce
1. Enter username: standard_user
2. Enter password: secret_sauce🔑
3. Click Login

## Expected
- User logged in successfully OR
- Validation error: "Password contains unsupported characters"

## Actual
- Login fails silently with no error message
- Console: 400 Bad Request from /api/login

## Severity / Priority
High / High — affects any user who uses emoji or non-ASCII in passwords

## Evidence
- Screenshot: screenshot-01.png
- Console log: console-01.txt
- Video: login-fail.mp4

SECTION 02Pillar 2 — test cases

Test cases show you can think systematically about a feature — not just click around and hope. A set of 20–30 well-written test cases for one feature (login, checkout, registration) is enough.

What to include in each test case

• ID — a stable identifier (TC-LOGIN-001). This is what people refer to when discussing a failure.
• Title — what behaviour it verifies. "Valid credentials allow login" beats "Test 1".
• Preconditions — what must be true before you start.
• Test data — the credentials, values, or inputs used. Don't hard-code sensitive data.
• Steps — numbered actions.
• Expected result — the observable outcome. "User is redirected to dashboard" beats "Login works".
• Actual result — only in the execution record, not the case itself.
• Status — Pass / Fail / Blocked / Skipped.

Coverage approach

Don't write test cases in a vacuum — cover the categories:

• Happy path — the intended flow with valid data.
• Negative — invalid credentials, missing fields, malformed input.
• Boundary — min/max lengths, zero, one, edge values.
• Security — SQL injection, XSS, rate limiting, password masking.
• Usability — error messages, accessibility basics, keyboard navigation.

SECTION 03Pillar 3 — automation repo

This is where beginner QA portfolios separate themselves. A working automation suite with clean structure and a good README proves you can write code — which is what nearly every entry-level role now expects.

What to build

• Language + tool — Playwright with TypeScript (most in-demand) or Python. Selenium is fine but less preferred in 2026.
• Target — a public site designed for practice: SauceDemo, DemoQA, or a public e-commerce site with a stable UI.
• Suite size — 15–20 tests covering one flow end to end (login, add to cart, checkout, logout).
• Structure — Page Object Model. Even if you're new, a POM structure signals you understand the pattern teams actually use.
• Tests — happy path, negative cases, one or two edge cases. Clear test names.
• README — what the suite covers, how to run it, what design choices you made.
• CI — a GitHub Actions workflow that runs the suite on every push. Even one workflow makes the whole repo look production-ready.

// A clean Playwright test with Page Object Model
// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

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

// tests/login.spec.ts
test('valid credentials log the user in', async ({ page }) => {
  const login = new LoginPage(page);
  await page.goto('/');
  await login.login('standard_user', 'secret_sauce');
  await expect(page.getByText('Products')).toBeVisible();
});

test('wrong password shows an error', async ({ page }) => {
  const login = new LoginPage(page);
  await page.goto('/');
  await login.login('standard_user', 'wrong');
  await expect(page.getByText('Username and password do not match')).toBeVisible();
});

SECTION 04Pillar 4 — live demo

A recruiter shouldn't have to run code to see you work. Give them something clickable.

Options — pick one

• Deployed automation suite — GitHub Actions with the run results pinned to your repo. A link to the latest workflow run shows the suite running in minutes.
• Small portfolio site — a single-page site (host on Vercel or GitHub Pages) with your bug reports, test cases, automation suite links and a short bio. Even a static HTML page is fine.
• Public test report — a report generated by Playwright's HTML reporter, hosted and linked. It shows the tests, results, screenshots and timings — proof the suite exists and works.
• Short video walkthrough — 3–5 minutes walking through one bug report and one automated test. Not required, but hugely effective at fresher level.

SECTION 05GitHub structure + README

Your GitHub profile is often the first thing a recruiter clicks. Make it easy to evaluate.

Structure your repos

• qa-portfolio — a top-level repo with your portfolio site, bug reports and test cases. This is the entry point.
• playwright-suite-<target> — one clean repo per automation suite. Don't put multiple unrelated suites in one repo.
• qa-notes (optional) — a repo with your learning notes, test plans, or a small sample manual QA exercise. Shows ongoing learning.

Pin the best repos

GitHub lets you pin up to six repos. Pin your QA portfolio, your best automation suite, and your portfolio site. Leave the tutorial clones unpinned — they don't help.

Write a README that actually explains things

Every repo should have a README with four sections: what it is, how to run it, what it covers, and what you'd improve. The last section is where beginners often skip — and it's the one that signals maturity.

# README template for a Playwright suite

# Playwright Suite — SauceDemo E-commerce

## What this is
Automated end-to-end tests for [saucedemo.com](https://www.saucedemo.com) using
Playwright + TypeScript. Covers login, product listing, cart and checkout.

## How to run
1. npm install
2. npx playwright install
3. npx playwright test

## Coverage
- Login: 5 tests (valid, invalid, empty, SQL injection, rate limit)
- Cart: 4 tests (add, remove, empty, quantity limits)
- Checkout: 5 tests (happy path, validation errors, edge cases)

## Design decisions
- Page Object Model for reusability
- getByRole and getByLabel locators for accessibility + stability
- Configurable environment via .env for different deployments

## CI
[![ci](https://github.com/you/playwright-saucedemo/actions/workflows/ci.yml/badge.svg)](...)

## What I'd improve next
- Add API-level tests to speed up the auth setup
- Add visual regression checks for the checkout flow
- Parameterise users to test roles end to end

SECTION 06Common mistakes

These cost interviews. Avoid them.

• No README, no context. A repo with just code and no explanation is ignored. Every repo needs a README that says what it is and why it exists.
• Tutorial clones. A direct copy of a YouTube tutorial is worse than nothing — recruiters recognize it and assume you have no original work. Even a small original project is better.
• Vague bug reports. "Login doesn't work" is not a bug report. Every report needs steps, expected, actual and evidence.
• Screenshots as portfolio. A folder of screenshots isn't a portfolio. It's evidence that a portfolio might exist. Link to a repo, a live URL, or a public file — not image files in a folder.
• No automation. Manual-only QA portfolios are almost dead in 2026. Even one Playwright suite with 10 tests changes the entire evaluation.
• Only one repo, mixed content. Bug reports, test cases and automation all crammed into one repo is hard to evaluate. One repo per purpose is cleaner.
• No CI badge. A green CI badge takes 20 minutes to set up and transforms how the repo is read.
• Broken links. Nothing kills a portfolio faster than clicking "live demo" and getting a 404. Test every link before sharing.

SECTION 074-week plan to build the portfolio

Assumes 1.5–2 hours per day. Follow in order — each week builds on the last.

1. Week 1 — bug reports and test cases. Pick one public test site (SauceDemo). Explore it. Write 10–15 quality bug reports and 20 test cases for the login and cart flows. Put them in a GitHub repo as Markdown files or CSV. Add a README explaining what the repo contains.
2. Week 2 — first automation suite. Learn Playwright basics: install, write 5 simple tests against SauceDemo. Get them passing locally. Push to GitHub. This is week two's deliverable — a working repo, even if small.
3. Week 3 — expand and structure. Refactor to Page Object Model. Add 10–15 more tests covering login, cart, checkout. Write a strong README. Add a GitHub Actions workflow that runs the suite on every push. Get the CI badge green.
4. Week 4 — portfolio site and polish. Build a one-page site (host on Vercel or GitHub Pages) linking to your bug reports, test cases and automation suite. Take a 3-minute video walkthrough. Test every link. Apply for jobs.

SECTION 08Test yourself — QA portfolio

SECTION 09Frequently asked questions

Related reads