Guide · Self-reviews

Self-review examples for QA engineers.

QA has one of the hardest self-reviews to write, because success is an absence: the bug that never reached users, the release that went out on time because nobody was guessing. You have to count what didn't happen, and show that you made it not happen.

What reviewers look for in a QA engineer

Bugs caught before users saw them. Especially severe ones, and how early in the cycle you found them.
Faster, trusted feedback. Automation that runs in CI, and tests people believe when they fail.
Clear bug reports. Steps, device, logs. Engineers notice whose bugs they can fix on the first read.
Quality earlier. Joining design reviews and spec discussions before code exists.
Release confidence. A sign-off that means something, and a clear "not yet" when it doesn't.

Example: impact

The projects, people and numbers in these examples are made up. Keep the shape and use your own facts.

Impact • Automated the Recipe App 2.0 create-and-sync regression suite (38 cases). A full regression pass went from about two days by hand to 40 minutes in CI. • Cut the flaky-run rate of the Sync SDK suite from roughly 12% to under 2%, by isolating shared test state and replacing sleeps with explicit waits. • Found the offline duplicate-save bug (APP-733) in the release candidate, two days before the 2.0 launch, with steps that reproduced it on three devices. It was fixed the same day.

Timing is the evidence. A severe bug found in a spec review is worth more than the same bug found in the release candidate, and both are worth more than one found by users.

Example: collaboration

Collaboration • Joined design reviews for 2.0 and added test notes to each spec. Nine edge cases, mostly about going offline mid-edit, were fixed before any code was written. • Paired with Ravi on contract tests for the sync API, so a breaking change now fails his build instead of reaching the apps. • Ran a one-hour session for engineers on writing UI tests with our page objects. Neha has since added 11 tests herself.

Example: growth

Growth • Learned to write API tests against the sync endpoint, which let me test conflict cases the UI can't reach. • Started reading crash reports after each release to find gaps in our test plan. Two new regression cases came from that. • Next half: own performance testing for sync, starting with a baseline for large recipe libraries.

Phrases that land

"found in the release candidate, two days before launch": the bug, and how close it came.
"regression pass from two days to 40 minutes": time given back to the whole team.
"fixed before any code was written": the cheapest bug there is.
"fails his build instead of reaching the apps": names the safety net you built.

Phrases that don't

"Ensured quality." Nobody can. Say what you checked and what you caught.
"Logged 140 bugs." A count without severity rewards noise.
"Tested everything." Reviewers know you didn't, so it costs you trust.
"Supported the release." Say what your sign-off was based on.

Gather your evidence

Your test code lives in git. This lists your commits to test folders over six months:

git log --since="6 months ago" --author="$(git config user.email)" --no-merges \ --date=short --format='%ad %s' -- tests e2e

Your bug reports live in the tracker. In Jira, a filter like this lists what you reported in the last six months, most severe first:

reporter = currentUser() AND created >= -26w ORDER BY priority DESC, created ASC

For each severe bug, note when you found it (spec, development, release candidate) and whether it reached users. Add the CI history of the suites you own, from before and after you fixed the flaky tests.

Let Sill keep the record

Most QA work happens in other people's tickets and builds, so it's the easiest to forget by review time. Sill keeps the record while you work. On the Mac it reads your local git history (commit messages and times, never code). On every device it records the tasks you finish, the releases you ship and the follow-ups you send, with receipts like day 6, asked 3×.

At review time, Sill Pro's Review generator turns months of that into a draft per project: what shipped, commit counts and ticket IDs, and every dependency you waited on. Where Apple Intelligence is available it writes a first-person draft on the device, and nothing leaves it. Commits come only from the Mac app. The last 7 days are free; longer periods need Sill Pro, an optional paid upgrade.

Get Sill on the App Store — for Mac, iPhone, iPad and Apple Watch. The daily standup and its set-time reminder are free.

More self-review examples: backend engineers · frontend engineers · iOS engineers · Android engineers · SRE and DevOps engineers · data engineers · engineering managers · product designers · product managers. Or start with how to write a self-review.