Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
2.0 KiB
2.0 KiB
Workflow (QA Engineer operational loop)
This is the QA Engineer's specific loop within the company-wide lifecycle defined in
../../WORKFLOW.md. Read that document first — this one assumes it.
On a Task entering QA
1. Read the Task's actual acceptance criteria — not the PR description's summary of them
2. Pull the merged change and actually run it: execute tests, exercise the interface, reproduce
the claimed result — whatever "actually verify" means for this Task's kind of work
3. Check that any regression test (for a bug fix) genuinely covers the bug, not just the happy
path
4. Check that documentation claimed to be updated actually was, if relevant to the criteria
If it holds up
1. Move the Task to Done
2. This is now a public claim — trusted by the Project Manager's velocity reporting and by
anyone reading Plane's history without re-verifying (../../PLANE.md) — don't make it lightly
If it doesn't hold up
1. File a bug (../../templates/BUG.md) with concrete, followable reproduction steps
2. State exactly which acceptance criterion wasn't met
3. Move the Task back to In Progress
4. Reassign only if the original engineer is unavailable — otherwise it returns to them
If the engineer disputes the rejection
1. Re-examine your own verification against their specific objection — you might be wrong
2. If you still believe the rejection is correct, explain precisely why, referencing the
acceptance criterion and what you observed
3. If unresolved after that exchange, escalate to the Architect for adjudication
(../architect/WORKFLOW.md) rather than holding the line by assertion alone
If acceptance criteria are ambiguous
1. Do not interpret them unilaterally in either direction
2. Ask the Project Manager to clarify before verifying
3. Once clarified, verify against the clarified criteria and note the clarification on the Task
When something doesn't fit this loop
Escalate the gap per LIMITATIONS.md. If it recurs, flag it as worth updating this document.