Inside the workflow
Illustrative reconstruction · No workplace data
01 / Source context
Start with the sources.
I checked Jira acceptance criteria against RFCs and implementation details in GitHub, then looked through Slack and conversations for decisions missing from the ticket. Conflicting requirements and unanswered product questions stayed in the notes.
02 / Preparation
Choose the check before the tool.
I brought expected behavior, prior findings, and regression risks into a runbook. Stored values, server rules, and interface calculations needed different assertions.
03 / Investigation
Follow the state beyond Save.
In one settings investigation, turning an option off and on, then saving, dropped other choices. I matched recording frames with HAR network logs and compared GraphQL values before and after reload. An unaffected option served as a control.
04 / Independent review
Try to disprove the claim.
An independent AI reviewer replayed the form logic against recorded request data. I reviewed the evidence and corrected claims that the recordings, environment, or stored state did not support.
05 / Human decision
Write the verdict with its limits.
I wrote the QA acceptance verdicts. AI generated or assembled the surrounding prose. I kept preparation, investigation, independent review, and the human decision separate, with review before posting.
This reconstructs the workflow, rather than showing a product interface or workplace artifact. The examples retain their historical coverage limits.
Test design
Put the assertion in the right place.
In care-module planning, I put stored vital values and server-rule checks in GraphQL tests. BMI was calculated in the interface, so an API assertion could not tell me whether it displayed correctly. That belonged in UI coverage.
The June 2026 record separates the states: the vitals API checks had run against dev; the UI checks were still marked pending.
Workflow refinement
Sometimes, remove a stage.
I retired a parallel-work pipeline whose overhead outweighed its help, and moved an unused impact viewer into a screen I already used.
The Kanban board moved from ownership lanes to pipeline stages. I removed realistic sample cards from the starting view so they couldn’t be mistaken for work waiting to be done. One writer per shared document and recovery steps for interruptions kept the handoffs manageable.
Review in practice
The evidence changed the report.
Review caught claims that needed correction. These are summaries of documented corrections, rather than additional findings.
- Screenshot
- A loading screen had been labeled as a saved result. I kept the timing offsets and missing visual evidence in the notes.
- Environment
- A control ran on dev, but the draft described it as staging coverage. I corrected the environment label.
- Saved state
- The visible defaults were restored, but the stored settings differed from the starting state. I corrected the report.
I asked for more random trials after a repaired pilot passed its original sample. A screenshot gets a vote, not the final word.
Outputs
Useful work, with the limits attached.
The workflow produced ticket-specific runbooks and evidence reviews. The release-reporting tools combined Jira status, GitHub pull requests, and release discussions into scope and merge updates in Google Docs and Confluence. Colleagues used those documents to follow releases. I operated the tools; colleagues used the documents.
Inspect a synthetic saved-state evidence record
Synthetic example · Invented settings and values
| Check | Example record |
|---|---|
| Starting state | Weekly digest on; reminder off. Record the initial values. |
| Action and request | Change a separate display option, save, and inspect the recorded request. |
| Reload and control | Read back both stored settings. Compare an unaffected option, too. |
| Conclusion | A successful Save click alone cannot establish that the starting values survived. |
| Open scope | Other accounts and browsers are untested in this example. |
Limits and lessons
Keep the unfinished work visible.
This was personal tooling for my QA work. The workflows evolved; I later retired the release-documentation automation. Its history included stale information and environment mix-ups that needed correction.
I keep coming back to two questions: can I start work from this packet, and can I tell what it hasn’t checked?