QA Workflow
The QA workflow covers the final verification phase where the QA team validates completed development work and transitions specifications from under-test to released status. This process ensures that only properly verified features reach end users.
Overview
When development work reaches the under-test status, the QA team takes ownership of the validation process. After successful verification against acceptance criteria and test scenarios, the team transitions the specification to released status.
under-test ──> released
If testing fails, the work returns to an earlier status for correction.
Workflow Stages
Under-Test (Starting Point)
The development team has signaled that implementation is complete and the specification is ready for verification.
What the QA team receives:
- A specification with clearly defined acceptance criteria
- Implementation that the development team considers complete
- Full traceability from the specification back to business goals
- Visibility into what changed compared to previous versions
Testing in Progress
The QA team conducts validation activities.
Who owns it: QA team
What happens:
- QA team members review the specification's acceptance criteria
- Testing is performed against the implemented functionality
- Test results are recorded
- Issues found are documented and communicated
What QA team members can do:
- View all work items currently in under-test status
- Access the details of work items they need to test
- Indicate when testing has passed or failed
- Transition items to released when validation is complete
Released (Transition Target)
The specification has been verified and is available to end users.
Who performs the transition: Authorized QA team member
What this signals:
- All acceptance criteria have been verified
- The implementation meets the specification requirements
- The feature is approved for production use
Key rules:
- Only users with QA team authorization can transition items to released
- Work items must be in under-test status before they can be released
- The release transition must capture an audit trail of who approved the release
- Work items cannot skip the under-test phase
Test Failure
When testing reveals issues that need correction.
What happens:
- The QA team member indicates the test failure
- The work item returns to an earlier status for rework
- The development team addresses the issues
- The item returns to under-test for re-verification
Transition Criteria
| From | To | Requirements |
|---|---|---|
| under-test | released | All acceptance criteria verified; authorized QA team member approves |
| under-test | (earlier status) | Test failure documented; returned for rework |
QA Team Responsibilities
- Review acceptance criteria -- understand exactly what needs to be verified
- Validate implementation -- test against the specification, not assumptions
- Document results -- record what was tested and the outcome
- Approve or reject -- make a clear decision on each work item
- Maintain the audit trail -- every decision should be traceable
Status History
Every QA transition is recorded with:
- The QA team member who performed the action
- A timestamp of the decision
- Whether the item was released or returned for rework
- Context or notes about the decision
Tips for QA Teams
- Start with the acceptance criteria -- they define the pass/fail boundaries
- Check the specification hierarchy -- understand the feature's context within goals
- Verify traceability -- ensure tests map back to acceptance criteria
- Communicate clearly when returning items for rework -- the development team needs to understand what failed
- Use the SPECLAN tree view to quickly see all items awaiting testing
Related Topics
- Development Workflow -- How specifications reach under-test
- Requirements Workflow -- How specifications get approved
- Status Lifecycle -- Full status progression reference
- Change Requests -- How to modify released specifications