QA Engineer project
Build an automated smoke suite that's reliable, not just present
5 critical flows automated in Playwright or Cypress — graded harder on reliability and failure diagnostics than on raw coverage.
The brief
Write an automated smoke test suite (Playwright or Cypress) covering the 5 most critical user flows of a real or sample app (e.g. signup, login, and the app's core action). The suite must run in CI, and a failing test must produce clear diagnostics — a screenshot or trace attached to the failure, not just a red X with no context.
Suggested stack
What you hand in
- A public GitHub repository with the test suite and a README
- The README explains why these 5 flows were chosen as the highest-risk ones
- A CI workflow file showing the suite runs on every push or PR
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
The 5 flows chosen are genuinely the highest-risk paths in the app (auth, the core value action), not arbitrary or trivially safe ones.
Tests pass consistently across repeated runs and don't flake due to timing issues — proven by running the suite multiple times in a row.
A failing test attaches a screenshot or trace that shows what actually went wrong, without needing to reproduce it locally to understand the failure.
The suite is wired into a CI workflow and actually runs there, not only demonstrated locally.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- A flaky test suite is worse than no suite, because teams learn to ignore red builds — reliability is graded harder than coverage here for exactly that reason.
- Choosing the right 5 flows out of dozens possible is itself a real QA judgment call that interviewers ask candidates to justify.
- Automated smoke tests running in CI are the actual daily artifact most QA engineers own and maintain.
Where people lose points
- Relying on fixed wait times (e.g. sleep(2000)) instead of waiting for a real condition, making tests flaky on slower CI runners.
- Hardcoded test data that breaks the second time the suite runs against a shared environment.
- A failure message that just says "expected true, got false" with no screenshot or context to debug from.
Other QA Engineer projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.