ma-agents 2.19.2 → 2.20.0

package/lib/bmad-cache/tea/src/workflows/testarch/bmad-teach-me-testing/steps-c/step-04-session-02.md

@@ -0,0 +1,465 @@
+---
+name: 'step-04-session-02'
+description: 'Session 2: Core Concepts - Risk-based testing, DoD, testing philosophy (45 min)'
+
+progressFile: '{test_artifacts}/teaching-progress/{user_name}-tea-progress.yaml'
+sessionNotesTemplate: '../templates/session-notes-template.md'
+sessionNotesFile: '{test_artifacts}/tea-academy/{user_name}/session-02-notes.md'
+nextStepFile: './step-03-session-menu.md'
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 4: Session 2 - Core Concepts
+
+## STEP GOAL:
+
+To teach testing fundamentals including risk-based testing, TEA quality standards (Definition of Done), and testing as engineering philosophy in a 45-minute session.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Master Test Architect and Teaching Guide
+- ✅ We engage in collaborative learning, not lectures
+- ✅ You bring expertise in TEA methodology and teaching pedagogy
+- ✅ Learner brings their role context, experience, and learning goals
+- ✅ Together we build their testing knowledge progressively
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on Session 2 content (Core Concepts)
+- 🚫 FORBIDDEN to skip ahead to other sessions
+- 💬 Approach: Teach fundamentals, provide examples, quiz understanding
+- 🚪 Teaching is mostly autonomous, quiz is collaborative
+- 📚 Reference TEA docs and knowledge fragments
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load TEA docs just-in-time
+- 💾 Generate session notes after completion
+- 📖 Update progress file with session completion and score
+- 🚫 FORBIDDEN to skip quiz - validates understanding
+- ⏭️ Always return to session menu hub after completion
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Progress file with user role/experience
+- Focus: Session 2 - Testing fundamentals and TEA principles
+- Limits: Only Session 2 content
+- Dependencies: Progress file exists with assessment data
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Session Welcome
+
+Display:
+
+"🧪 **Session 2: Core Concepts** (45 minutes)
+
+**Objective:** Understand WHY behind TEA principles
+
+**What you'll learn:**
+
+- Testing as Engineering philosophy
+- Risk-based testing with P0-P3 matrix
+- TEA Definition of Done (quality standards)
+- Probability × Impact risk scoring
+
+Let's dive into the fundamentals!"
+
+### 2. Update Progress File (Session Started)
+
+Load {progressFile} and update session-02-concepts:
+
+- Set `status: 'in-progress'`
+- Set `started_date: {current_date}`
+
+Save the updated progress file.
+
+### 3. Teaching: Testing as Engineering
+
+Present this content:
+
+"### 🏗️ Testing as Engineering
+
+**Core Philosophy:** Testing is not an afterthought - it's engineering.
+
+**What this means:**
+
+- Tests are **designed** before they're written (like architecture before coding)
+- Tests have **quality standards** (not just "does it run?")
+- Tests are **maintained** like production code
+- Testing decisions are **risk-based** (prioritize what matters)
+
+{If role == QA:}
+**For QA Engineers:** You're not just finding bugs - you're engineering test systems that scale. Design before write, maintain like production code.
+
+{If role == Dev:}
+**For Developers:** Think of tests like you think of production code. Design patterns, refactoring, DRY principles - they all apply to tests.
+
+{If role == Lead:}
+**For Tech Leads:** Testing as engineering means architecture decisions: fixture patterns, data strategies, CI orchestration. Not just "write more tests."
+
+{If role == VP:}
+**For VPs:** Testing is an engineering discipline requiring investment in tooling, architecture, and knowledge. Not a checklist item.
+
+**Key Principle:** If you wouldn't accept sloppy production code, don't accept sloppy test code.
+
+**Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/testing-as-engineering/>"
+
+### 4. Teaching: Risk-Based Testing
+
+Present this content:
+
+"### ⚖️ Risk-Based Testing: The P0-P3 Matrix
+
+**Problem:** You can't test everything. How do you prioritize?
+
+**Solution:** Risk = Probability × Impact
+
+**The P0-P3 Matrix:**
+
+**P0 - Critical (Must Test)**
+
+- Login/Authentication
+- Payment processing
+- Data loss scenarios
+- Security vulnerabilities
+- **Impact:** Business fails if broken
+- **Probability:** High usage, high complexity
+
+**P1 - High (Should Test)**
+
+- Core user workflows
+- Key features
+- Data integrity
+- **Impact:** Major user pain
+- **Probability:** Frequent usage
+
+**P2 - Medium (Nice to Test)**
+
+- Secondary features
+- Edge cases with workarounds
+- **Impact:** Inconvenience
+- **Probability:** Moderate usage
+
+**P3 - Low (Optional)**
+
+- Tooltips, help text
+- Nice-to-have features
+- Aesthetic issues
+- **Impact:** Minimal
+- **Probability:** Low usage
+
+{If role == QA:}
+**For QA Engineers:** Use P0-P3 to defend test coverage decisions. "We have 100% P0 coverage, 80% P1" is better than "we have 50% coverage overall."
+
+{If role == Dev:}
+**For Developers:** When writing tests, ask "Is this P0 login or P3 tooltip?" Focus your time accordingly.
+
+{If role == Lead:}
+**For Tech Leads:** P0-P3 helps allocate test automation budget. Mandate P0/P1 automation, P2/P3 is cost-benefit analysis.
+
+{If role == VP:}
+**For VPs:** Risk-based testing aligns engineering effort with business impact. Metrics that matter: P0 coverage, not lines of code.
+
+**Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/risk-based-testing/>
+
+**Knowledge Fragment:** probability-impact.md defines scoring criteria"
+
+### 5. Teaching: Definition of Done (Quality Standards)
+
+Present this content:
+
+"### ✅ TEA Definition of Done: Quality Standards
+
+**The Problem:** "The tests pass" isn't enough. What about quality?
+
+**TEA Definition of Done ensures:**
+
+**1. No Flaky Tests**
+
+- Tests pass/fail deterministically
+- No "run it again, it'll work" tests
+- Use explicit waits, not hard sleeps
+- Handle async properly
+
+**2. No Hard Waits/Sleeps**
+
+- Use `waitFor` conditions, not `sleep(5000)`
+- React to state changes, don't guess timing
+- Tests complete when ready, not after arbitrary delays
+
+**3. Stateless & Parallelizable**
+
+- Tests run independently, any order
+- No shared state between tests
+- Can run in parallel (fast feedback)
+- Use cron jobs/semaphores only when unavoidable
+
+**4. No Order Dependency**
+
+- Every `it`/`describe`/`context` block works in isolation
+- Supports `.only` execution for debugging
+- Tests don't depend on previous tests
+
+**5. Self-Cleaning Tests**
+
+- Test sets up its own data
+- Test automatically deletes/deactivates entities created
+- No manual cleanup required
+
+**6. Tests Live Near Source Code**
+
+- Co-locate test files with code they validate
+- `component.tsx` → `component.spec.tsx` in same folder
+
+**7. Low Maintenance**
+
+- Minimize manual upkeep
+- Avoid brittle selectors
+- Use APIs to set up state, not UI clicks
+- Don't repeat UI actions
+
+{If role == QA:}
+**For QA Engineers:** These standards prevent the "test maintenance nightmare." Upfront investment in quality = long-term stability.
+
+{If role == Dev:}
+**For Developers:** Write tests you'd want to inherit. No flaky tests, no "run twice" culture, no mystery failures.
+
+{If role == Lead:}
+**For Tech Leads:** Enforce these standards in code review. Flaky test PRs don't merge. Period.
+
+{If role == VP:}
+**For VPs:** Definition of Done isn't perfectionism - it's engineering rigor. Flaky tests erode trust in CI/CD.
+
+**Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/test-quality-standards/>
+
+**Knowledge Fragment:** test-quality.md has execution limits and criteria"
+
+### 6. Teaching: Key Takeaways
+
+Present this content:
+
+"### 🎯 Session 2 Key Takeaways
+
+**1. Testing is Engineering**
+
+- Design before write
+- Maintain like production code
+- Apply engineering principles
+
+**2. Risk-Based Testing**
+
+- P0 = Critical (login, payment)
+- P1 = High (core workflows)
+- P2 = Medium (secondary features)
+- P3 = Low (tooltips, nice-to-have)
+- Prioritize based on Probability × Impact
+
+**3. Definition of Done**
+
+- No flaky tests (deterministic)
+- No hard waits (use waitFor)
+- Stateless & parallelizable
+- Self-cleaning tests
+- Low maintenance
+
+**4. Quality Standards = Engineering Rigor**
+
+- Not perfectionism, but reliability
+- Prevents test maintenance nightmares
+- Builds trust in CI/CD
+
+**You now understand the WHY behind TEA principles!**"
+
+### 7. Quiz: Validate Understanding
+
+Display:
+
+"### ✅ Knowledge Check
+
+3 questions to validate your understanding. Passing: ≥70% (2 of 3 correct)."
+
+**Question 1:**
+
+"**Question 1 of 3:**
+
+In the P0-P3 matrix, what priority level should login/authentication have?
+
+A) P3 - Low priority
+B) P2 - Medium priority
+C) P1 - High priority
+D) P0 - Critical priority
+
+Your answer (A, B, C, or D):"
+
+**Wait for response. Validate:**
+
+- Correct answer: D
+- If correct: "✅ Correct! Login/authentication is P0 - critical. Business fails if broken."
+- If incorrect: "❌ Login/authentication is P0 - Critical (D). It's high usage, high impact, and business-critical."
+
+**Store result**
+
+**Question 2:**
+
+"**Question 2 of 3:**
+
+What is the problem with using `sleep(5000)` instead of `waitFor` conditions?
+
+A) It makes tests slower
+B) It's a hard wait that doesn't react to state changes (violates DoD)
+C) It uses too much memory
+D) It's not supported in modern frameworks
+
+Your answer (A, B, C, or D):"
+
+**Wait for response. Validate:**
+
+- Correct answer: B
+- If correct: "✅ Correct! Hard waits don't react to state - they guess timing. Use `waitFor` to react to conditions."
+- If incorrect: "❌ The issue is that hard waits don't react to state changes (B). They guess timing instead of waiting for conditions. This violates TEA Definition of Done."
+
+**Store result**
+
+**Question 3:**
+
+"**Question 3 of 3:**
+
+What does "self-cleaning tests" mean in TEA Definition of Done?
+
+A) Tests automatically fix their own bugs
+B) Tests delete/deactivate entities they create during testing
+C) Tests run faster by cleaning up code
+D) Tests remove old test files
+
+Your answer (A, B, C, or D):"
+
+**Wait for response. Validate:**
+
+- Correct answer: B
+- If correct: "✅ Correct! Self-cleaning tests clean up their data - no manual cleanup needed."
+- If incorrect: "❌ Self-cleaning means tests delete/deactivate entities they created (B). No manual cleanup required."
+
+**Store result**
+
+**Calculate score:**
+
+- Total points / 3 \* 100 = score (0-100)
+
+**Display results:**
+
+"**Quiz Results:** {score}/100
+
+{If score >= 70:}
+✅ **Passed!** You understand core testing concepts.
+
+{If score < 70:}
+⚠️ **Below passing.** Would you like to:
+
+- **[R]** Review the content again
+- **[C]** Continue anyway (score will be recorded)
+
+{Wait for response if < 70, handle R or C}"
+
+### 8. Generate Session Notes
+
+Create {sessionNotesFile} using {sessionNotesTemplate} with session-02 content including:
+
+- Teaching topics covered
+- TEA docs referenced
+- Knowledge fragments referenced (test-quality.md, probability-impact.md)
+- Quiz results
+- Key takeaways
+- Next recommended session based on experience level
+
+### 9. Update Progress File (Session Complete)
+
+Load {progressFile} and update session-02-concepts:
+
+- Set `status: 'completed'`
+- Set `completed_date: {current_date}`
+- Set `score: {score}`
+- Set `notes_artifact: '{sessionNotesFile}'`
+
+Update progress metrics:
+
+- Increment `sessions_completed` by 1
+- Calculate `completion_percentage`
+- Set `next_recommended: 'session-03-architecture'`
+
+Update stepsCompleted array:
+
+- Append 'step-04-session-02'
+- Update lastStep
+
+Save the updated progress file.
+
+### 10. Session Complete Message
+
+Display:
+
+"🎉 **Session 2 Complete!**
+
+**Your Score:** {score}/100
+
+**Session notes saved:** {sessionNotesFile}
+
+You now understand:
+
+- Testing as engineering philosophy
+- Risk-based testing (P0-P3 matrix)
+- TEA Definition of Done
+- Why quality standards matter
+
+**Next:** Session 3 (Architecture & Patterns) or explore any session from the menu.
+
+**Progress:** {completion_percentage}% complete ({sessions_completed} of 7 sessions)"
+
+### 11. Present MENU OPTIONS
+
+Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Session Menu
+
+#### Menu Handling Logic:
+
+- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
+- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
+- IF C: Progress file already updated, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Teaching content presented (Testing as Engineering, Risk-based, DoD)
+- Examples adapted to user role
+- Quiz administered (3 questions)
+- Score calculated correctly
+- Session notes generated
+- Progress file updated
+- stepsCompleted array updated
+- User routed back to hub
+
+### ❌ SYSTEM FAILURE:
+
+- Skipping quiz
+- Not adapting to role
+- Not generating notes
+- Not updating progress
+- Not routing to hub
+
+**Master Rule:** Teach, quiz, generate notes, update progress, return to hub.