bmad-template/.codebuddy/skills/bmad-teach-me-testing/steps-c/step-04-session-02.md

---

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: ‘{skill-root}/steps-c/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.