Skill first: chrome-live-business-qa.
What got captured here was not a tidy conclusion, but a kind of work that can easily go out of control in real projects: testing a business system with visible Chrome, multiple roles, a real backend, and write-side effects.
A page opening does not mean the flow passed. An admin save succeeding does not mean the user side actually changed. An export button being clickable does not mean the exported content is ready for real users. This distinction is what made the session worth preserving.
I First Turned the Experience into a Reusable Operation
The iron rule of this workflow is skill first, blog second. The reason is direct: if you write the blog first, it easily becomes a smooth retrospective. If you write the skill first, you must define triggers, inputs, steps, pitfalls, and verification checklists clearly.
So I landed a skill first: chrome-live-business-qa. It does not teach people "how to click the browser"; it constrains how real business QA should start, how it should be recorded, when to stop, and how to avoid contaminating test data.
The Biggest Pitfall: Testing Only the Current Role
In a multi-role system, one action often affects more than the current page. When an admin changes a teacher, time, roster, or status, the real question is not whether the save button turned green, but whether the affected role's page changed accordingly.
That is why the skill makes cross-role readback a hard step: immediately after writing, switch to the affected role and read back the detail page, list, overview, and export content. If it cannot be read back, the case cannot be called passed.
This rule is simple, but it blocks a lot of false passes that merely look tested.
The Second Pitfall: Real Data Needs Restoration
A real backend is not a sandbox. If one test changes time, teacher, or status without restoring it, the next test, the next teammate, or even real users may step on the residue of that test.
So the skill requires every write action to carry a recovery path: know how to undo it before writing; read back after writing; read back again after restoring. If restoration fails, record it as explicit leftover cleanup instead of pretending the scene is clean.
The Third Pitfall: Testing Cannot Extend Forever
Long live QA easily turns into "one more page". That makes the report longer, but does not necessarily reduce risk. What helps is stopping after the core flows are covered and turning the remainder into a minimal regression set.
So the skill includes a stop audit: once creation, editing, cross-role readback, export, login, and navigation have evidence, stop full write testing and turn follow-up work into the smallest retest after fixes.
Stopping is also engineering judgment.
The Template Preserved This Time
Besides the main skill, I also kept references/case-ledger-template.md. It records each case's result, page, steps, readback, cross-role readback, whether it wrote data, whether it restored data, and next owner.
The value of this template is that the next QA run does not need to reinvent the record format. It also makes handoff more honest: what has been verified, what was only observed, what needs user confirmation, and what must wait for a minimal regression after fixes.
The Lesson from This Session
- Skill capture is not copying chat logs into an article; it is writing repeatable judgment into an operating checklist.
- The core of real business QA is not browser automation, but evidence, restoration, cross-role side effects, and stop rules.
- The personal blog version does not need to be pushed to someone else's
Innei/SKILLrepo; the skill should first live in my own GitHub skills repo with a real, accessible, maintainable location. - The blog is the discovery layer; the skill is the operation layer that can be reused next time.
Skill again at the bottom:chrome-live-business-qa. This article is only the entry point; the operating doc is what should actually be reused.