QA Engineer project
Write a release runbook and prove it works with a real dry run
A rollback plan and go/no-go criteria specific enough to use at 2am — validated by actually walking through it once, not just written.
The brief
Build a structured, reusable release checklist and runbook for a sample app, covering pre-release checks, a rollback plan with specific executable steps, smoke tests to run post-deploy, and objective go/no-go criteria. Then walk through the checklist once against a real or simulated deploy of your own app, and note in the doc what it actually caught.
Suggested stack
What you hand in
- A public GitHub repository with the checklist as a markdown file
- A dry-run log section documenting what happened when the checklist was actually used once
- The rollback plan is specific to this app, not a generic template
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 checklist covers this app's real risk areas — data migrations, config/env changes, third-party dependencies — not generic boilerplate copied from a template.
The rollback plan states exact steps for this app (undo the migration how, restore config how), not "roll back if something breaks".
Go/no-go criteria are specific, checkable conditions (e.g. "error rate under X% for 10 minutes post-deploy"), not a subjective feeling.
The dry-run log shows the checklist was actually used once, including anything it caught or a note that everything passed cleanly.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- Most teams' real release process lives in one person's head until it breaks, and writing it down is a genuinely high-leverage QA contribution.
- A rollback plan that isn't specific is useless at 2am during a real incident, which is exactly when it gets used.
- Running the checklist once for real, rather than only writing it, is what separates documentation from an actual process.
Where people lose points
- A rollback plan that says "revert the deploy" with no actual steps for what that means for this app's migrations, cache, or config.
- Go/no-go criteria that are subjective ("team feels confident") instead of specific, checkable conditions.
- A checklist that was clearly never run against anything real because it misses an obvious step, like checking environment variables after a redeploy.
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.