mirror of
https://github.com/azaion/autopilot.git
synced 2026-04-22 09:26:34 +00:00
Oleksandr Bezdieniezhnykh
50 lines
2.5 KiB
Markdown
50 lines
2.5 KiB
Markdown
# Phase 2: Test Scenario Specification
|
|
|
|
**Role**: Professional Quality Assurance Engineer
|
|
**Goal**: Produce detailed black-box test specifications covering blackbox, performance, resilience, security, and resource limit scenarios.
|
|
**Constraints**: Spec only — no test code. Tests describe what the system should do given specific inputs, not how the system is built.
|
|
|
|
## Steps
|
|
|
|
Based on all acquired data, acceptance_criteria, and restrictions, form detailed test scenarios:
|
|
|
|
1. Define test environment using `.cursor/skills/plan/templates/test-environment.md` as structure
|
|
2. Define test data management using `.cursor/skills/plan/templates/test-data.md` as structure
|
|
3. Write blackbox test scenarios (positive + negative) using `.cursor/skills/plan/templates/blackbox-tests.md` as structure
|
|
4. Write performance test scenarios using `.cursor/skills/plan/templates/performance-tests.md` as structure
|
|
5. Write resilience test scenarios using `.cursor/skills/plan/templates/resilience-tests.md` as structure
|
|
6. Write security test scenarios using `.cursor/skills/plan/templates/security-tests.md` as structure
|
|
7. Write resource limit test scenarios using `.cursor/skills/plan/templates/resource-limit-tests.md` as structure
|
|
8. Build traceability matrix using `.cursor/skills/plan/templates/traceability-matrix.md` as structure
|
|
|
|
## Self-verification
|
|
|
|
- [ ] Every acceptance criterion is covered by at least one test scenario
|
|
- [ ] Every restriction is verified by at least one test scenario
|
|
- [ ] Every test scenario has a quantifiable expected result from `input_data/expected_results/results_report.md`
|
|
- [ ] Expected results use comparison methods from `.cursor/skills/test-spec/templates/expected-results.md`
|
|
- [ ] Positive and negative scenarios are balanced
|
|
- [ ] Consumer app has no direct access to system internals
|
|
- [ ] Test environment matches project constraints (see `phases/hardware-assessment.md`, which runs before Phase 4)
|
|
- [ ] External dependencies have mock/stub services defined
|
|
- [ ] Traceability matrix has no uncovered AC or restrictions
|
|
|
|
## Save action
|
|
|
|
Write all files under TESTS_OUTPUT_DIR:
|
|
|
|
- `environment.md`
|
|
- `test-data.md`
|
|
- `blackbox-tests.md`
|
|
- `performance-tests.md`
|
|
- `resilience-tests.md`
|
|
- `security-tests.md`
|
|
- `resource-limit-tests.md`
|
|
- `traceability-matrix.md`
|
|
|
|
## Blocking
|
|
|
|
**BLOCKING**: Present test coverage summary (from `traceability-matrix.md`) to user. Do NOT proceed to Phase 3 until confirmed.
|
|
|
|
Capture any new questions, findings, or insights that arise during test specification — these feed forward into downstream skills (plan, refactor, etc.).
|