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.
55 lines
2.0 KiB
Markdown
55 lines
2.0 KiB
Markdown
# 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.
|