Building a QA portfolio without leaking company data

A hiring manager asks for samples of your work. You open your laptop and realise every good test plan you have written sits behind your employer's login, full of internal screen names, customer emails, and unreleased features.

So you send nothing, and your application looks the same as everyone else's.

There is a way out. You rebuild the thinking on software anyone can open. The skill was never in the company data. It was in how you decided what to test.

Short version

Never export internal tickets, specs, or screenshots. Rebuild the work instead.
Public demo apps are enough to show every core QA skill.
Anonymising means changing names, data, and structure, not just blurring a logo.
Five strong artefacts beat twenty shallow ones.
Host it where a link opens in one click: GitHub, Notion, or a simple site.

Why you cannot just reuse company work

Most employment contracts say the work you produce belongs to the employer. That covers test plans, test cases, bug reports, and automation code. It usually covers screenshots of internal tools too.

Even where the contract is loose, three risks remain:

Customer data. A screenshot with a real name, email, or order value is a privacy problem, not a portfolio.
Unreleased features. Showing a feature that has not shipped can breach confidentiality.
Security detail. Internal URLs, API paths, and error traces tell an attacker where to look.

A hiring manager who sees you share your last employer's internals learns exactly one thing: you will do the same with theirs. It reads as a red flag, not as initiative.

Public apps you can test freely

You need software that is open to the public, has real complexity, and does not ban testing in its terms. Good options:

Type of app	Example targets	Skills it shows
Practice sites built for testing	The Internet (herokuapp), SauceDemo, ParaBank, OrangeHRM demo	Test case design, automation, edge cases
Open source web apps	Wikipedia, OpenStreetMap, a self-hosted WordPress or Nextcloud instance	Real-world messiness, accessibility, performance
Public APIs	GitHub REST API, Open Weather, restful-booker	API testing, status codes, schema checks
Your own tiny app	A to-do app you build in an afternoon	Test planning from scratch, CI setup

Two rules. Do not run load tests against anything you do not own, because that looks like an attack. Do not test authenticated areas of a service unless the terms allow it or the account is your own.

Set up a local copy where you can. A self-hosted instance of an open source app gives you full freedom: you can break the database, change configuration, and take any screenshot you like.

What to actually build

Five artefacts cover almost everything a QA interview asks about. Aim for depth, not volume.

1. A test plan for one feature

Pick one feature, such as checkout on SauceDemo. Write a one-page plan: scope, what is out of scope, risks, test data, environments, and how you will decide it is done. One page. A twenty-page plan signals that you cannot prioritise.

2. A test case set with clear design technique

Show that your cases come from a method, not from guessing. Label them.

TC-014 — Discount code boundary Technique: boundary value analysis Data: cart totals of $49.99, $50.00, $50.01 with code SAVE10 Expected: no discount below $50.00, 10% at and above $50.00

That single case shows more skill than fifty cases that each say "verify the page loads".

3. Three to five bug reports

This is the artefact hiring managers read most closely. Find real bugs on a public app and write them properly: title, steps, expected, actual, environment, evidence, severity with a reason.

Include the console error as text, not only a screenshot, for example TypeError: Cannot read properties of undefined (reading 'total'). Include the URL, such as https://staging.example.com/cart. If you capture evidence with a browser tool like Crosscheck, the screenshot, console log, network requests, and browser details come attached in one step, which is also the workflow most teams expect you to know.

4. A small automation project

One framework, done well. Ten to fifteen tests in Playwright or Cypress that cover one flow end to end, with a README that explains how to run them and why you chose those tests. Add a GitHub Actions file so the tests run on every push. A green badge on the repo does more than a long description.

5. One written analysis

Pick something you noticed and write 400 words on it. An accessibility audit of one page against WCAG rules. A comparison of two bug templates. A note on why a flaky test was flaky. This shows you can communicate, which is the skill that separates senior from mid.

How to anonymise work you cannot rebuild

Sometimes the structure of an internal document is genuinely yours and worth showing. You can adapt it, but do it properly. Blurring a logo is not anonymising.

Follow these steps:

Replace all names. Company, product, feature, and team names. "Acme Retail" becomes "an online retailer". Internal codenames must go, because they are searchable.
Replace all data. Real emails become [email protected]. Real order values become round example numbers. Real customer IDs become CUST-0001.
Replace all URLs and paths. Internal hosts become https://staging.example.com. Remove API paths that reveal internal architecture.
Remove screenshots entirely. Redacted screenshots leak layout, feature names, and often data at the edges. Rebuild the screen on a public app or draw a simple wireframe.
Change the scale. If your company had 2 million users and 40 engineers, do not say so. The combination identifies the employer.
Read it as an outsider. If someone who knows your industry could name the company in under a minute, you have not finished.

A clean rule: if removing the detail would break the sample, it was probably the company's detail, not your skill. Rebuild instead.

Where to host it

Pick the place a busy person can open in one click from your CV. No downloads, no access requests.

GitHub repository. Best for automation work. Put the written artefacts in a docs/ folder as markdown. Everything is public and versioned, and the commit history shows real work over time.
Notion or a similar public page. Best for written artefacts. Fast to build, easy to keep tidy. Check the share setting is public before you send the link.
A small static site. GitHub Pages or Netlify, free. Worth it if you want a custom domain such as yourname.dev.

Whichever you choose, the landing page needs a short paragraph saying who you are, what is in the portfolio, and which link to open first. Hiring managers spend about a minute on the first visit.

A sample structure you can copy

qa-portfolio/
  README.md            <- who you are, what to look at first
  01-test-plan/        <- one feature, one page
  02-test-cases/       <- 20-30 cases, techniques labelled
  03-bug-reports/      <- 5 reports, full evidence
  04-automation/       <- Playwright project + CI workflow
  05-writing/          <- one analysis piece

Your README should open with something like:

QA portfolio by Sara Ahmed. All work here is built on public demo applications. No employer data is included. Start with 03-bug-reports/checkout-discount.md for a sample of how I report defects.

That last line matters. You are choosing which sample gets read first instead of leaving it to chance.

Keeping it alive

A portfolio last touched two years ago works against you. Two habits keep it current with about an hour a month:

Add one new bug report whenever you find a good bug on a public site.
Update the automation repo when the framework releases a major version, and note the migration in the README.

Both leave a visible timestamp. A recent commit tells a hiring manager you are still practising, without you saying a word about it.

Frequently asked questions

Do I need a portfolio if I already have QA experience?

Not strictly, but it helps at two moments: when you have no referenceable work because everything was internal, and when you are changing specialism, such as manual to automation.

Can I show work from a freelance client?

Only with written permission, and even then anonymise it. Ask by email so you have a record. Many clients agree if you remove their name and data.

How many bug reports are enough?

Three to five, written well. A long list of shallow reports suggests you file noise. Depth on a few shows judgement.

Should I include test cases that found nothing?

Yes, if they show good design. Testing is not only about finding bugs. A well-designed boundary case that passed still proves you knew where the risk was.

Is a portfolio expected for junior QA roles?

It is not required, but it stands out most at junior level, where every candidate has similar training and no work history to point at.