Mathias STRASSER
b7dc27f2a5
Les enseignants ont besoin de moyennes à jour immédiatement après la publication ou modification des notes, sans attendre un batch nocturne. Le système recalcule via Domain Events synchrones : statistiques d'évaluation (min/max/moyenne/médiane), moyennes matières pondérées (normalisation /20), et moyenne générale par élève. Les résultats sont stockés dans des tables dénormalisées avec cache Redis (TTL 5 min). Trois endpoints API exposent les données avec contrôle d'accès par rôle. Une commande console permet le backfill des données historiques au déploiement.
106 lines
4.1 KiB
Markdown
106 lines
4.1 KiB
Markdown
<!-- Powered by BMAD-CORE™ -->
|
|
|
|
# Test Design and Risk Assessment
|
|
|
|
**Workflow ID**: `_bmad/tea/testarch/bmad-testarch-test-design`
|
|
**Version**: 5.0 (Step-File Architecture)
|
|
|
|
---
|
|
|
|
## Overview
|
|
|
|
Plans comprehensive test coverage strategy with risk assessment, priority classification, and execution ordering. This workflow operates in **two modes**:
|
|
|
|
- **System-Level Mode (Phase 3)**: Testability review of architecture before solutioning gate check
|
|
- **Epic-Level Mode (Phase 4)**: Per-epic test planning with risk assessment
|
|
|
|
The workflow auto-detects which mode to use based on project phase and user intent.
|
|
|
|
---
|
|
|
|
## WORKFLOW ARCHITECTURE
|
|
|
|
This workflow uses **step-file architecture** for disciplined execution:
|
|
|
|
### Core Principles
|
|
|
|
- **Micro-file Design**: Each step is a self-contained instruction file
|
|
- **Just-In-Time Loading**: Only the current step file is in memory
|
|
- **Sequential Enforcement**: Execute steps in order without skipping
|
|
- **State Tracking**: Write outputs only when instructed, then proceed
|
|
|
|
### Step Processing Rules (Non-Negotiable)
|
|
|
|
1. **READ COMPLETELY**: Read the entire step file before taking any action
|
|
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
|
|
3. **WAIT FOR INPUT**: Halt when user input is required
|
|
4. **LOAD NEXT**: Only load the next step file when directed
|
|
|
|
---
|
|
|
|
## INITIALIZATION SEQUENCE
|
|
|
|
### 1. Configuration Loading
|
|
|
|
From `workflow.yaml`, resolve:
|
|
|
|
- `config_source`, `test_artifacts`, `user_name`, `communication_language`, `document_output_language`, `date`
|
|
|
|
### 2. First Step
|
|
|
|
Load, read completely, and execute:
|
|
`./steps-c/step-01-detect-mode.md`
|
|
|
|
### 3. Resume Support
|
|
|
|
If the user selects **Resume** mode, load, read completely, and execute:
|
|
`./steps-c/step-01b-resume.md`
|
|
|
|
This checks the output document for progress tracking frontmatter and routes to the next incomplete step.
|
|
|
|
---
|
|
|
|
## OUTPUT GENERATION GUIDANCE
|
|
|
|
When populating templates in step 5, apply the following guidance for these sections:
|
|
|
|
### Not in Scope
|
|
|
|
- Identify components, third-party services, or subsystems NOT covered by this test plan
|
|
- For each excluded item, provide reasoning (why excluded) and mitigation (how risk is addressed elsewhere)
|
|
- Common exclusions: external vendor APIs tested by upstream teams, legacy modules outside the current phase scope, infrastructure already covered by platform team monitoring
|
|
|
|
### Entry and Exit Criteria
|
|
|
|
- **Entry criteria**: Derive from Dependencies and Test Blockers -- what must be resolved before QA can start testing
|
|
- **Exit criteria**: Derive from Quality Gate Criteria -- what constitutes "done" for the testing phase
|
|
- Include project-specific criteria based on context (e.g., "feature flag enabled in staging", "seed data loaded", "pre-implementation blockers resolved")
|
|
|
|
### Project Team (Optional)
|
|
|
|
- Include only if roles/names are known or responsibility mapping is needed
|
|
- Extract names and roles from PRD, ADR, or project context if available
|
|
- If names are unknown, either omit or use role placeholders for drafts
|
|
- Map testing responsibilities to each role (e.g., who owns E2E tests, who signs off)
|
|
|
|
### Tooling and Access (System-Level QA Document Only)
|
|
|
|
- Include only if non-standard tools or access requests are required
|
|
- List notable tools/services needed for test execution and any access approvals
|
|
- Avoid assuming specific vendors unless the project context names them
|
|
- Mark each item's status as Ready or Pending based on available information
|
|
- This section applies only to `test-design-qa-template.md` output
|
|
|
|
### Implementation Planning Handoff (Optional)
|
|
|
|
- Include only if test design produces implementation tasks that must be scheduled
|
|
- Derive items from Dependencies & Test Blockers, tooling/access needs, and QA infra setup
|
|
- If no dedicated QA, assign ownership to Dev/Platform as appropriate
|
|
- Keep the list short; avoid per-milestone breakdown tables
|
|
|
|
### Interworking & Regression
|
|
|
|
- Identify services and components that interact with or are affected by the feature under test
|
|
- For each, define what existing regression tests must pass before release
|
|
- Note any cross-team coordination needed for regression validation (e.g., shared staging environments, upstream API contracts)
|