QA portfolio projects that don't look fake

I've reviewed a lot of QA portfolios, and most of them are the same project. A test suite against a demo e-commerce site, twenty Playwright tests of the happy path, a README that reads like the tutorial it came from. It tells me the candidate can follow instructions. It tells me nothing about whether they can test. The fake-looking ones aren't fake because they're dishonest — they're fake because they skip the part of testing that's actually the job: deciding what to test and judging what you find. Here's how to build ones that don't.

Why the tutorial project reads as fake

Real testing work has a shape: someone hands you something underspecified, you figure out what could break, you find problems, you make calls about what matters, you communicate it. A tutorial project has none of that shape — the what-to-test was decided for you, nothing actually breaks, and there's nothing to communicate. A reviewer feels that absence immediately, even if they can't name it. The fix isn't a fancier framework; it's putting the missing shape back in.

Test something real, where bugs actually exist

Automating the happy path of a polished demo site proves nothing — by design it has no bugs. Instead, point your testing at something with real surface area and real defects:

• A genuinely buggy practice target (the practice & projects section exists for exactly this — apps built to be tested, with bugs to find).
• A small open-source tool or a public API. Real APIs have the twelve bug classes waiting to be found, and "I found a real auth/pagination bug in X and reported it" is worth more than 50 green tests.
• Your own tiny app, deliberately. If you build the thing, you can speak to the trade-offs and the risk areas — which is the senior signal.

Show the thinking, not just the code

The code is the least interesting part. What makes a reviewer lean in is the reasoning around it:

• A test plan or risk note. Half a page: what this is, what's risky about it, what you chose to test and what you deliberately didn't, and why. This single artifact separates testers from test-script-writers.
• Real bugs, written up properly. A handful of actual defects you found, each as a clear bug report — steps, expected vs actual, why it matters. Two well-reported real bugs beat a perfect green suite.
• Decisions, not just results. "I used data-testid here because the copy changes often" / "I skipped visual testing because the design isn't stable yet." Showing the call you made is the whole point.

Make it readable in two minutes

Nobody reads your repo top to bottom. The README does the work: what the project is, what you tested and why, the most interesting bug you found, and how to run it — in that order, above the fold. If the interesting judgement is buried in commit messages, it doesn't exist as far as the reviewer is concerned.

Where this fits

A portfolio is one half of the job hunt; the interview is the other. The SDET interview loop breaks down what each round tests, and the manual-to-automation transition guide covers the skills path if you're building toward your first automation role. The interview prep hub ties the questions to the same skills your portfolio should be demonstrating.

Does your portfolio project look real?

• It targets something with actual bugs, not a polished demo's happy path
• There's a short test plan / risk note: what you tested AND what you skipped
• It includes real bugs you found, written up with expected vs actual
• It shows decisions and trade-offs, not just passing results
• The README surfaces the interesting thinking in the first two minutes
• A reviewer could tell it's yours and not a tutorial's, at a glance