Six Thinking Hats

Six Thinking Hats for Testing

<default_to_action> When analyzing testing decisions: 1. DEFINE focus clearly (specific testing question) 2. APPLY each hat sequentially (5 min each) 3. DOCUMENT insights per hat 4. SYNTHESIZE into action plan

Quick Hat Rotation (30 min):

🤍 WHITE (5 min) - Facts only: metrics, data, coverage
❤️ RED (3 min) - Gut feelings (no justification needed)
🖤 BLACK (7 min) - Risks, gaps, what could go wrong
💛 YELLOW (5 min) - Strengths, opportunities, what works
💚 GREEN (7 min) - Creative ideas, alternatives
🔵 BLUE (3 min) - Action plan, next steps

Example for "API Test Strategy":

• 🤍 47 endpoints, 30% coverage, 12 integration tests
• ❤️ Anxious about security, confident on happy paths
• 🖤 No auth tests, rate limiting untested, edge cases missing
• 💛 Good docs, CI/CD integrated, team experienced
• 💚 Contract testing with Pact, chaos testing, property-based
• 🔵 Security tests first, contract testing next sprint

</default_to_action>

Quick Reference Card

The Six Hats

When to Use Each Hat

---

Hat Details

🤍 White Hat - Facts & Data

Output: Quantitative testing baseline

Questions:

• What test coverage do we have?
• What is our pass/fail rate?
• What environments exist?
• What is our defect history?

Example Output:
Coverage: 67% line, 45% branch
Test Suite: 1,247 unit, 156 integration, 23 E2E
Execution Time: Unit 3min, Integration 12min, E2E 45min
Defects: 23 open (5 critical, 8 major, 10 minor)

🖤 Black Hat - Risks & Cautions

Output: Comprehensive risk assessment

Questions:

• What could go wrong in production?
• What are we NOT testing?
• What assumptions might be wrong?
• Where are the coverage gaps?

HIGH RISKS:
- No load testing (production outage risk)
- Auth edge cases untested (security vulnerability)
- Database failover never tested (data loss risk)

💛 Yellow Hat - Benefits & Optimism

Output: Strengths and opportunities

Questions:

• What's working well?
• What strengths can we leverage?
• What quick wins are available?

STRENGTHS:
- Strong CI/CD pipeline
- Team expertise in automation
- Stakeholders value quality

QUICK WINS:
- Add smoke tests (reduce incidents)
- Automate manual regression (save 2 days/release)

💚 Green Hat - Creativity

Output: Innovative testing ideas

Questions:

• How else could we test this?
• What if we tried something completely different?
• What emerging techniques could we adopt?

IDEAS:
1. AI-powered test generation
2. Chaos engineering for resilience
3. Property-based testing for edge cases
4. Production traffic replay
5. Synthetic monitoring

❤️ Red Hat - Emotions

Output: Team gut feelings (NO justification needed)

Questions:

• How confident do you feel about quality?
• What makes you anxious?
• What gives you confidence?

FEELINGS:
- Confident: Unit tests, API tests
- Anxious: Authentication flow, payment processing
- Frustrated: Flaky tests, slow E2E suite

🔵 Blue Hat - Process

Output: Action plan with owners and timelines

Questions:

• What's our strategy?
• How should we prioritize?
• What's the next step?

PRIORITIZED ACTIONS:
1. [Critical] Address security testing gap - Owner: Alice
2. [High] Implement contract testing - Owner: Bob
3. [Medium] Reduce flaky tests - Owner: Carol

---

Session Templates

Solo Session (30 min)

# Six Hats Analysis: [Topic]

## 🤍 White Hat (5 min)
Facts: [list metrics, data]

## ❤️ Red Hat (3 min)
Feelings: [gut reactions, no justification]

## 🖤 Black Hat (7 min)
Risks: [what could go wrong]

## 💛 Yellow Hat (5 min)
Strengths: [what works, opportunities]

## 💚 Green Hat (7 min)
Ideas: [creative alternatives]

## 🔵 Blue Hat (3 min)
Actions: [prioritized next steps]

Team Session (60 min)

• Each hat: 10 minutes
• Rotate through hats as group
• Document on shared whiteboard
• Blue Hat synthesizes at end

---

Agent Integration

// Risk-focused analysis (Black Hat)
const risks = await Task("Identify Risks", {
  scope: 'payment-module',
  perspective: 'black-hat',
  includeMitigation: true
}, "qe-regression-risk-analyzer");

// Creative test approaches (Green Hat)
const ideas = await Task("Generate Test Ideas", {
  feature: 'new-auth-system',
  perspective: 'green-hat',
  includeEmergingTechniques: true
}, "qe-test-generator");

// Comprehensive analysis (All Hats)
const analysis = await Task("Six Hats Analysis", {
  topic: 'Q1 Test Strategy',
  hats: ['white', 'black', 'yellow', 'green', 'red', 'blue']
}, "qe-quality-analyzer");

---

Agent Coordination Hints

Memory Namespace

aqe/six-hats/
├── analyses/*        - Complete hat analyses
├── risks/*           - Black hat findings
├── opportunities/*   - Yellow hat findings
└── innovations/*     - Green hat ideas

Fleet Coordination

const analysisFleet = await FleetManager.coordinate({
  strategy: 'six-hats-analysis',
  agents: [
    'qe-quality-analyzer',        // White + Blue hats
    'qe-regression-risk-analyzer', // Black hat
    'qe-test-generator'           // Green hat
  ],
  topology: 'parallel'
});

---

Related Skills

• risk-based-testing - Black Hat deep dive
• exploratory-testing-advanced - Green Hat exploration
• context-driven-testing - Adapt to context

---

Anti-Patterns

---

Remember

Separate thinking modes for clarity. Each hat reveals different insights. Red Hat intuition often catches what Black Hat analysis misses.

Everyone wears all hats. This is parallel thinking, not role-based. The goal is comprehensive analysis, not debate.

Six Thinking Hats for Testing

A comprehensive Claude Code skill that applies Edward de Bono's Six Thinking Hats methodology to software testing contexts.

Quick Overview

What It Does: Enables structured exploration of quality concerns from six distinct perspectives (facts, emotions, risks, benefits, creativity, and process) to uncover blind spots and make better testing decisions.

When to Use:

• Designing test strategies for new features
• Conducting test retrospectives
• Analyzing test failures or production incidents
• Evaluating testing approaches
• Facilitating testing discussions with teams
• Overcoming analysis paralysis in testing decisions

The Six Hats

Total: 30 minutes for solo session, 60-90 minutes for team session

Quick Start

Solo Session (30 minutes)

# 1. Copy the template
cp .claude/skills/six-thinking-hats/resources/templates/solo-session-template.md my-analysis.md

# 2. Define your testing focus
# Example: "Test strategy for user authentication feature"

# 3. Work through each hat sequentially (use timer!)
# White Hat (5 min): List facts, metrics, data
# Red Hat (3 min): Capture gut feelings, no justification
# Black Hat (7 min): Identify risks, gaps, problems
# Yellow Hat (5 min): Find strengths, opportunities
# Green Hat (7 min): Generate creative testing ideas
# Blue Hat (5 min): Create action plan

# 4. Synthesize into actionable test plan

Team Session (90 minutes)

# 1. Copy the team template
cp .claude/skills/six-thinking-hats/resources/templates/team-session-template.md team-session.md

# 2. Pre-session: Gather data (White Hat prep)

# 3. Run session with strict time boundaries
# - Blue Hat opening: 5 min (set context)
# - White Hat: 10 min (collect facts round-robin)
# - Red Hat: 5 min (silent reflection + sharing)
# - Black Hat: 12 min (brainstorm risks)
# - Yellow Hat: 8 min (identify opportunities)
# - Green Hat: 15 min (rapid ideation)
# - Blue Hat: 10 min (synthesize action plan)

# 4. Post-session: Document and share (20 min)

File Structure

.claude/skills/six-thinking-hats/
├── SKILL.md                           # Main skill documentation
├── README.md                          # This file (human-readable overview)
├── resources/
│   ├── templates/
│   │   ├── solo-session-template.md  # Template for individual use
│   │   └── team-session-template.md  # Template for team sessions
│   └── examples/
│       └── api-testing-example.md    # Complete worked example

When to Use Which Format

Solo Session (30 min)

✅ Use when:

• Quick decision needed
• Individual test analysis
• Personal exploration
• Preparing for team discussion

Team Session (90 min)

✅ Use when:

• Complex testing challenges
• Cross-functional alignment needed
• Multiple perspectives valuable
• Shared understanding required

Async Session (2-3 days)

✅ Use when:

• Distributed team
• Deep thinking needed
• Time zone challenges
• Written documentation desired

Integration with Other QE Skills

Works exceptionally well with:

• context-driven-testing - Choose practices based on context
• risk-based-testing - Prioritize using Black Hat
• exploratory-testing-advanced - Use Green Hat for creative charters
• holistic-testing-pact - Comprehensive quality model (all hats)

Key Benefits

1. Uncovers Blind Spots: Each hat reveals different insights 2. Balances Perspectives: Black Hat pessimism balanced by Yellow Hat optimism 3. Structures Discussion: Prevents chaotic brainstorming 4. Builds Consensus: Team alignment through shared process 5. Saves Time: 30-90 min investment prevents days of rework 6. Validates Intuition: Red Hat legitimizes gut feelings 7. Drives Creativity: Green Hat forces innovative thinking

Common Pitfalls to Avoid

❌ Hat Mixing: Combining perspectives (e.g., "Tests are passing (White) but I'm worried (Red)")

• ✅ Solution: Strict separation, use timer

❌ Justifying Red Hat: Rationalizing feelings instead of trusting intuition

• ✅ Solution: "I feel X" not "I feel X because..."

❌ Skipping Hats: "We don't need Green Hat"

• ✅ Solution: Every hat reveals insights, wear all six

❌ Rushing: 5 minutes for all hats

• ✅ Solution: Minimum 5 min per hat, use timer

❌ Judging Contributions: Criticizing ideas during Green Hat

• ✅ Solution: All ideas valid, evaluate later in Blue Hat

Success Metrics

A successful Six Hats session should produce:

• ✅ 10+ facts documented (White Hat)
• ✅ Honest feelings captured (Red Hat)
• ✅ 5+ risks identified (Black Hat)
• ✅ 3+ opportunities found (Yellow Hat)
• ✅ 5+ creative ideas generated (Green Hat)
• ✅ Clear action plan with owners (Blue Hat)

Resources

Templates

• resources/templates/solo-session-template.md - Individual analysis
• resources/templates/team-session-template.md - Team facilitation

Examples

• resources/examples/api-testing-example.md - Complete worked example with real test strategy

Further Reading

• SKILL.md - Complete documentation with all use cases
• "Six Thinking Hats" by Edward de Bono - Original methodology
• "Context-Driven Testing" - Related testing philosophy

Quick Tips

1. Use Timer: Strict time boundaries improve quality 2. Start with Black Hat: Teams love identifying risks 3. Trust Red Hat: Intuition catches what analysis misses 4. Go Wild in Green Hat: No idea too crazy 5. Close with Blue Hat: Always end with action plan 6. Document Everything: Especially Green Hat wild ideas 7. Practice Solo First: Get comfortable before facilitating teams

Support

• Main documentation: SKILL.md
• Templates: resources/templates/
• Examples: resources/examples/
• Related skills: context-driven-testing, risk-based-testing, exploratory-testing-advanced

---

Created: 2025-11-13 Category: Testing Methodologies Difficulty: Intermediate Best Used With: context-driven-testing, risk-based-testing, exploratory-testing-advanced

Six Hats Example: REST API Testing Strategy

Context: New REST API with 25 endpoints, 3-week development sprint, need to define comprehensive test strategy.

Team: 2 backend developers, 1 QE engineer Timeline: Week 1 (planning), Weeks 2-3 (implementation & testing) Stack: Node.js, Express, PostgreSQL, JWT auth

---

🤍 White Hat - Facts (5 minutes)

Current State

• API Endpoints: 25 total (8 GET, 7 POST, 5 PUT, 3 DELETE, 2 PATCH)
• Authentication: JWT with refresh tokens
• Database: PostgreSQL with 12 tables
• Documentation: OpenAPI 3.0 spec (80% complete)
• Current Coverage: 0% (greenfield project)
• Team Experience: Strong backend, moderate API testing experience

Technical Details

• Expected Load: 100 requests/second peak
• Response Time Target: <200ms for 95th percentile
• Uptime SLA: 99.9%
• Data Volume: ~50k records in production

Available Resources

• CI/CD: GitHub Actions configured
• Test Frameworks: Jest, Supertest, Newman (Postman)
• Timeline: 2 weeks for test development
• Budget: Standard (no new tools needed)

Known Risks (from product)

• Authentication complexity (OAuth2 + JWT)
• Multi-tenant data isolation
• Real-time updates via WebSockets

---

❤️ Red Hat - Feelings (3 minutes)

Confidence Levels

• ✅ Confident: CRUD operations, database schema design
• ⚠️ Somewhat Anxious: Authentication edge cases, rate limiting
• ❌ Very Concerned: WebSocket testing, multi-tenant isolation

Gut Instincts

• "The authentication flow feels overly complex - bugs will hide there"
• "I have a bad feeling about the data isolation between tenants"
• "The WebSocket real-time updates worry me - we've never tested those before"
• "The happy path will work, but edge cases will bite us"

Team Sentiment

• Backend devs are excited about the API design
• QE engineer feels time pressure (2 weeks is tight)
• Product manager seems unaware of testing complexity
• Overall: 6/10 confidence we'll ship on time with quality

---

🖤 Black Hat - Risks & Problems (7 minutes)

High-Risk Areas

1. Authentication & Authorization

• JWT token expiration not tested
• Refresh token rotation edge cases
• Password reset flow vulnerable
• Multi-tenant authorization bypass possible
• No rate limiting on auth endpoints

2. Data Isolation (Multi-Tenancy)

• Tenant A could potentially access Tenant B data
• No tests verify data isolation
• Database queries lack tenant ID filters
• Admin endpoints could leak data

3. WebSocket Real-Time Updates

• Zero experience testing WebSockets
• Connection stability untested
• Concurrent user scenarios unknown
• Message ordering not validated

4. Performance & Scalability

• No load testing planned
• N+1 query problems likely
• Database connection pooling untested
• No caching strategy

Coverage Gaps

• Error handling: Only 30% of endpoints have error tests
• Edge cases: Boundary values, null handling untested
• Integration: Database + API + auth not tested together
• Regression: No test suite exists yet

Assumptions to Challenge

• ❌ "JWT handles security" → Need to test token validation, expiry, revocation
• ❌ "ORM prevents SQL injection" → Need to validate input sanitization
• ❌ "Database constraints ensure data integrity" → Need application-level validation tests

What Could Go Wrong in Production

• Authentication bypass: Attacker gains unauthorized access
• Data leak: Tenant A sees Tenant B's sensitive data
• Performance degradation: 100 req/sec causes database crash
• Race conditions: Concurrent updates corrupt data
• API breaking changes: Clients break on deployment

---

💛 Yellow Hat - Benefits & Opportunities (5 minutes)

Current Strengths

• ✅ Well-documented OpenAPI spec (can generate tests from it!)
• ✅ Team has strong Jest experience
• ✅ CI/CD already configured (easy to add test stage)
• ✅ Database schema well-designed (migrations tested)
• ✅ Clean architecture (easy to mock/stub)

Reusable Assets

• Existing authentication test utilities from previous project
• Database seeding scripts already written
• Postman collection with 15 example requests
• Swagger UI for manual testing

Opportunities

• Test automation framework: Build once, reuse for future APIs
• Contract testing: Share API contracts with frontend team
• Performance baseline: Establish benchmarks early
• Documentation: Tests serve as living documentation

Quick Wins

• Generate basic tests from OpenAPI spec (1 day)
• Automate Postman collection in CI (4 hours)
• Add authentication test suite from previous project (2 hours)

Strategic Value

• First API with comprehensive testing → template for future projects
• Build QE reputation with strong quality delivery
• Reduce production incidents (costly to fix)

---

💚 Green Hat - Creative Ideas (7 minutes)

Alternative Testing Approaches

1. Contract Testing (Pact)

• Define API contracts between frontend and backend
• Generate tests from contracts automatically
• Prevent breaking changes
• Enable independent team deployments

2. Property-Based Testing (fast-check)

• Define properties: "All GET requests return 200 or 404"
• Generate hundreds of random inputs
• Uncover edge cases humans miss
• Example: Test all possible JWT token formats

3. Chaos Testing

• Randomly kill database connections
• Inject network latency
• Corrupt request payloads
• Test system resilience

4. Visual API Testing

• Use Postman Mock Server
• Validate response schemas visually
• Enable non-technical stakeholders to review
• Generate documentation from tests

5. AI-Generated Test Data

• Use LLMs to generate realistic test users
• Create synthetic PII (privacy-safe)
• Generate edge case scenarios
• Cover cultural/language variations

Crazy Ideas (That Might Work)

• Idea: Test API by deploying to production with feature flags (0% traffic)
• Why it might work: Real production environment, no synthetic load, early validation

• Idea: Crowdsource testing with bug bounty program
• Why it might work: Security experts find vulnerabilities we'd miss

• Idea: Record production traffic and replay in test
• Why it might work: Test with real usage patterns, not synthetic scenarios

• Idea: Use GitHub Copilot to generate test cases from API documentation
• Why it might work: Fast initial coverage, human review for quality

Emerging Techniques to Explore

• Fuzzing: AFL, libFuzzer for input validation
• GraphQL Testing: If we migrate from REST
• Service Virtualization: For external API dependencies
• Shift-Left Security: OWASP ZAP in CI/CD

---

🔵 Blue Hat - Process & Action Plan (5 minutes)

Test Strategy Summary

Goal: 80% automated coverage, <5% production defects, ship on time

Approach: Risk-based testing with focus on authentication and data isolation

Frameworks:

• Unit: Jest
• Integration: Supertest
• Contract: Pact (frontend collaboration)
• Performance: k6 (load testing)
• Security: OWASP ZAP (automated scan)

Prioritized Test Development

Week 1: Foundation (Red Hat priorities)

• ✅ Day 1-2: Authentication test suite (JWT, refresh, expiry)
• ✅ Day 3: Multi-tenant data isolation tests
• ✅ Day 4: Error handling and edge cases
• ✅ Day 5: Integration tests (DB + API + Auth)

Week 2: Expansion (Yellow Hat opportunities)

• Day 1-2: Property-based testing for input validation
• Day 3: Contract testing setup with frontend
• Day 4: Performance baseline (load testing)
• Day 5: Security scan (OWASP ZAP)

Week 3: Polish (Green Hat innovations)

• Day 1-2: WebSocket testing framework
• Day 3: Chaos testing experiments
• Day 4: Documentation and knowledge sharing
• Day 5: Buffer for fixes

Action Plan

Decision Points

Go/No-Go Decision (End of Week 2):

• ✅ Must have: All P0 tests passing, no critical security issues
• ✅ Should have: P1 tests at 70% complete, performance baseline met
• ⚠️ Nice to have: P2 experimental tests

Criteria for Launch:

• Auth test suite: 95%+ coverage
• Data isolation: 100% verified
• Integration tests: All passing
• Performance: <200ms p95 response time
• Security: No high/critical findings

Next Steps (Immediate)

1. Today: QE starts auth test suite (pull existing code from previous project) 2. Tomorrow: Dev 1 sets up integration test framework 3. Day 3: Team reviews OpenAPI spec, generates test skeleton 4. Day 4: QE demos property-based testing POC to team 5. Day 5: Retrospective on Week 1 progress

Metrics to Track

• Test coverage % (target: 80%)
• Test execution time (target: <5 min)
• Defect detection rate (baseline: track for future)
• Production incidents (target: <2 per month)

Communication Plan

• Daily: Standup with test status
• Weekly: Demo to product manager (show test results)
• End of Week 2: Go/No-Go decision meeting
• Post-Launch: Retrospective with Six Hats on testing effectiveness

---

Synthesis: Key Decisions

What We're Doing

1. Risk-based approach: Auth + data isolation first (Black Hat priorities) 2. Quick wins: Reuse existing test utilities (Yellow Hat opportunities) 3. Innovation: Property-based testing + contract testing (Green Hat ideas) 4. Pragmatic: Skip WebSocket deep testing for MVP, address in next sprint

What We're NOT Doing (And Why)

• ❌ Comprehensive WebSocket testing (too risky for timeline, defer to next sprint)
• ❌ Chaos testing in production (not ready for that level of experimentation)
• ❌ 100% coverage (diminishing returns, 80% is realistic)
• ❌ Manual exploratory testing (no time, focus on automation)

How This Addresses Concerns

• Red Hat anxiety about auth → P0 auth test suite
• Black Hat risk of data leaks → P0 tenant isolation tests
• Yellow Hat opportunity to reuse code → Leverage existing test utils
• Green Hat innovation → Property-based testing POC

Success Definition

• Ship on time with <3 critical bugs in first month
• 80% automated test coverage
• <5 minute CI/CD test execution
• Team confident in quality (Red Hat validation)
• Reusable test framework for future APIs

---

Lessons for Next Time

What This Six Hats Session Revealed

1. Red Hat identified the real concern (auth complexity, data isolation) before we wasted time 2. Black Hat forced us to challenge "JWT is secure" assumption 3. Green Hat gave us property-based testing idea (wouldn't have thought of it) 4. Yellow Hat reminded us we have existing auth tests (saved 2 days) 5. Blue Hat prevented scope creep (deferred WebSocket testing)

Time Investment vs Value

• Time: 45 minutes for Six Hats session
• Value:
• Avoided 2 days of redundant work (reused existing tests)
• Identified critical risk (data isolation) early
• Aligned team on priorities
• Created clear action plan

ROI: ~4x (45 min investment prevented 2+ days of rework)

---

Session Date: 2025-11-13 Participants: Backend Dev 1, Backend Dev 2, QE Engineer Duration: 45 minutes Outcome: Clear test strategy, team alignment, on-track for launch

Six Hats Analysis: [Your Testing Topic]

Date: YYYY-MM-DD Facilitator: [Your Name] Focus: [Specific testing question or challenge]

---

🤍 White Hat - Facts & Data (5 minutes)

Objective: List only objective information. No opinions or interpretations.

Test Metrics

• Current coverage:
• Number of tests:
• Pass rate:
• Execution time:

Environment & Resources

• Test environments:
• Tools available:
• Team capacity:

Known Data

• Recent defects:
• Performance benchmarks:
• Historical trends:

---

❤️ Red Hat - Feelings & Intuition (3 minutes)

Objective: Capture gut instincts and emotions. No justification needed.

My Feelings About Quality

• I feel confident about:
• I feel anxious about:
• I'm frustrated by:

Gut Instincts

• Something feels off about:
• My intuition says:
• If I had to ship today, I'd feel:

Team Sentiment

• The team seems:
• Energy level around testing:

---

🖤 Black Hat - Risks & Problems (7 minutes)

Objective: Critical judgment. What could go wrong?

High-Risk Areas

1. 2. 3.

Coverage Gaps

• Not testing:
• Missing edge cases:
• Integration points:

Assumptions to Challenge

• We assume:
• This might be wrong because:

Potential Failures

• In production, this could fail if:
• Security vulnerabilities:
• Performance bottlenecks:

---

💛 Yellow Hat - Benefits & Opportunities (5 minutes)

Objective: Positive thinking. What's working? What can we leverage?

Current Strengths

• Testing assets we have:
• Team capabilities:
• Tools and infrastructure:

Opportunities

• We could leverage:
• Quick wins available:
• Reusable components:

Value Being Provided

• Our testing prevents:
• We're good at:
• Competitive advantages:

---

💚 Green Hat - Creative Ideas (7 minutes)

Objective: New ideas and alternatives. No idea too crazy!

Alternative Approaches

1. 2. 3.

Innovative Testing Ideas

• What if we:
• We could try:
• Emerging techniques to explore:

Crazy Ideas (That Might Work)

- - -

Tools/Techniques to Investigate

-

---

🔵 Blue Hat - Process & Action Plan (5 minutes)

Objective: Organize findings into structured plan.

Summary of Key Insights

• Most critical finding:
• Biggest opportunity:
• Top creative idea:

Prioritized Actions

1. Immediate (This Week):

• [ ]
• [ ]

2. Short-Term (2-4 Weeks):

• [ ]
• [ ]

3. Long-Term (Quarter):

• [ ]
• [ ]

Next Steps

• First action:
• Owner:
• Deadline:
• Success criteria:

Decision Points

• Go/No-Go decision:
• Required before proceeding:

---

Final Synthesis

What Did I Learn?

-

Key Decisions Made

-

Follow-Up Required

-

Share With

-

---

Session Duration: ___ minutes Most Valuable Hat: Would Use Again: Yes / No Notes:

Team Six Hats Session

Date: YYYY-MM-DD Facilitator: [Name] Participants: [List names] Topic: [Testing challenge or decision] Duration: 90 minutes

---

Pre-Session Checklist (10 minutes before)

• [ ] Define focus clearly and share with team
• [ ] Gather relevant data (White Hat prep)
• [ ] Set up timer (5-15 min per hat)
• [ ] Brief new participants on Six Hats rules
• [ ] Prepare whiteboard/Miro board
• [ ] Assign note-taker

---

Rules Reminder

1. Wear one hat at a time - No mixing perspectives 2. All ideas are valid - No criticism during Green Hat 3. Red Hat needs no justification - Trust intuition 4. Time is strict - Move on when timer rings 5. Blue Hat leads - Facilitator guides process 6. Everyone participates - Round-robin sharing

---

Session Agenda (60 minutes)

🔵 Blue Hat - Opening (5 minutes)

Facilitator: Explain the challenge and desired outcome

Today's Focus:

Success Criteria:

Time Allocation:

• White Hat: 10 min
• Red Hat: 5 min
• Black Hat: 12 min
• Yellow Hat: 8 min
• Green Hat: 15 min
• Blue Hat: 10 min

---

🤍 White Hat - Facts & Data (10 minutes)

Format: Round-robin, each person shares one fact until exhausted

Facilitator Notes:

• Keep opinions out ("I think" → stop them)
• Ask for sources ("Where's that data from?")
• Document everything

Facts Collected:

Data Summary:

• Test coverage:
• Defect rate:
• Team capacity:
• Timeline:

Missing Data (to collect later): -

---

❤️ Red Hat - Feelings & Intuition (5 minutes)

Format: 2 min silent reflection, 3 min sharing

Facilitator Notes:

• Make it safe to share
• No justification required
• No judgment or debate
• Capture exact words

Individual Feelings:

Team Sentiment Summary:

• Overall confidence level: 1-10:
• Common anxieties:
• Shared intuitions:
• Red flags from instinct:

---

🖤 Black Hat - Risks & Critical Analysis (12 minutes)

Format: Brainstorm risks on whiteboard, then categorize

Facilitator Notes:

• Encourage pessimism (this is the time!)
• Ask "What else could go wrong?"
• Challenge all assumptions
• Group similar risks

Risks Identified:

High-Risk (Could cause production outage/data loss)

1. 2. 3.

Medium-Risk (Could impact users significantly)

1. 2. 3.

Low-Risk (Minor issues)

1. 2.

Coverage Gaps: -

Challenged Assumptions:

• We assume: ___________. But what if: ___________?
• We assume: ___________. But what if: ___________?

"What Could Go Wrong" Scenarios:

• If [X] fails, then:
• If we get [Y] traffic, then:
• If [Z] edge case occurs, then:

---

💛 Yellow Hat - Benefits & Opportunities (8 minutes)

Format: Positive brainstorm, build on each other's ideas

Facilitator Notes:

• Balance the Black Hat pessimism
• Ask "What's working well?"
• Identify quick wins
• Find opportunities in challenges

Strengths:

• Testing capabilities:
• Team skills:
• Infrastructure:
• Stakeholder support:

Opportunities:

• Can leverage:
• Could reuse:
• Quick wins:
• Strategic advantages:

Value Provided:

• Our testing prevents:
• We excel at:
• ROI of testing:

---

💚 Green Hat - Creative Ideas (15 minutes)

Format: Rapid-fire ideation, no filtering, build on ideas

Facilitator Notes:

• Quantity over quality
• No idea too crazy
• Encourage wild combinations
• Build on others' ideas ("Yes, and...")

Idea Generation: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Crazy Ideas (that might actually work): - - -

Alternative Approaches:

• Instead of [current], we could:
• What if we completely:
• Opposite approach:

Emerging Techniques to Explore: -

Innovation Backlog (for later): -

---

🔵 Blue Hat - Process & Action Plan (10 minutes)

Format: Facilitator synthesizes, team validates

Facilitator Notes:

• Summarize key insights from each hat
• Identify patterns and conflicts
• Prioritize actions
• Assign owners and deadlines
• Get commitment

Key Insights Summary:

Patterns Identified:

• Red Hat feelings align with Black Hat risks:
• Green Hat idea addresses Black Hat risk:
• White Hat gaps need:

Action Plan:

Immediate Next Steps (This Week): 1. [ ] 2. [ ] 3. [ ]

Decision Required:

• Decision:
• Decide by:
• Criteria:
• Decider:

Follow-Up:

• Next Six Hats session:
• Progress review:
• Stakeholder communication:

---

Post-Session (20 minutes)

Documentation

• [ ] Clean up notes
• [ ] Share summary with team
• [ ] Add actions to backlog/Jira
• [ ] Update test strategy doc
• [ ] Schedule follow-ups

Retrospective on the Session

What Worked Well: -

What to Improve: -

Facilitator Observations:

• Hat that generated most value:
• Hat that was rushed:
• Team engagement level:
• Next session changes:

Sharing

Send to (within 24 hours):

• Team: [Summary + Actions]
• Stakeholders: [Key decisions]
• Management: [High-level outcomes]

Archive:

• [ ] Save to shared drive
• [ ] Tag with project/sprint
• [ ] Link from test strategy

---

Appendix: Hat Prompts (If Team Gets Stuck)

White Hat Stuck?

• What test metrics do we track?
• How many tests do we have?
• What's our defect rate?
• What data are we missing?

Red Hat Stuck?

• Rate confidence 1-10: Why that number?
• If you had to ship today, would you?
• Where do you feel uneasy?
• Trust your gut: What's wrong?

Black Hat Stuck?

• What keeps you up at night?
• What could cause a production incident?
• What are we NOT testing?
• Play devil's advocate: Why will this fail?

Yellow Hat Stuck?

• What are we proud of?
• What would we do again?
• What's our competitive advantage?
• What quick wins exist?

Green Hat Stuck?

• What would [competitor] do?
• What if we had unlimited budget?
• What's the opposite of our approach?
• What emerging tech could we use?

Blue Hat Stuck?

• What's the next step?
• How do we prioritize?
• What's our strategy?
• How do we measure success?

---

Template Version: 1.0 Last Updated: 2025-11-13 License: MIT