@shaykec/bridge 0.4.25 → 0.4.26

package/modules/design-patterns/walkthrough.md

@@ -0,0 +1,64 @@
+# Design Patterns Walkthrough — Learn by Doing
+
+## Step 1: Strategy in Practice
+
+**Task:** Implement a `PaymentProcessor` that can use different payment strategies (CreditCard, PayPal, Crypto). The processor should accept a strategy and delegate the `pay(amount)` call.
+
+**Question:** What would you need to change to add Apple Pay? Would you edit the processor or add a new strategy class?
+
+**Checkpoint:** The user has a working strategy setup and understands open/closed extension.
+
+---
+
+## Step 2: Factory for Object Creation
+
+**Task:** Create a `NotificationFactory` that returns the right notification type (Email, SMS, Push) based on a string or enum. The factory encapsulates the `if/switch` logic.
+
+**Question:** Where should configuration (e.g., API keys for each channel) live — inside the factory, or passed in? What are the tradeoffs?
+
+**Checkpoint:** The user has a factory that returns typed instances based on input.
+
+---
+
+## Step 3: Observer for Event Handling
+
+**Task:** Build a simple `Subject` class: `subscribe(callback)`, `unsubscribe(callback)`, `notify(data)`. Use it to let a "form" notify "validators" and "analytics" when the user submits.
+
+**Question:** What happens if a subscriber throws? How might you make the observer more robust?
+
+**Checkpoint:** The user has a working pub-sub and multiple subscribers.
+
+---
+
+## Step 4: Decorator for Layered Behavior
+
+<!-- hint:code language="javascript" highlight="1,3" -->
+
+**Task:** Create a `Logger` interface with `log(msg)`. Implement `ConsoleLogger`. Then create `TimestampDecorator` and `LevelDecorator` that wrap a logger and add behavior. Compose them: `TimestampDecorator(LevelDecorator(ConsoleLogger))`.
+
+**Question:** What order should decorators be applied? Does it matter?
+
+**Checkpoint:** The user can stack decorators and explain composition order.
+
+---
+
+## Step 5: Adapter for Legacy Code
+
+**Task:** You have a function `fetchData(callback)` that uses callbacks. Create an adapter so it can be used with `async/await` or returns a Promise.
+
+**Question:** Does the adapter change the behavior of the legacy code, or just its interface?
+
+**Checkpoint:** The user can wrap a callback API in a Promise-based interface.
+
+---
+
+## Step 6: When *Not* to Use a Pattern
+
+<!-- hint:buttons type="single" prompt="For a simple utility function, which applies?" options="Singleton,Factory,Strategy,No pattern" -->
+<!-- hint:card type="concept" title="YAGNI: You Aren't Gonna Need It" -->
+
+**Task:** Consider a small feature (e.g., a utility function). Would Singleton, Factory, or Strategy apply? If not, explain why. "No pattern" is a valid answer.
+
+**Question:** What's the cost of over-applying patterns? When does YAGNI trump pattern elegance?
+
+**Checkpoint:** The user can articulate when patterns add value vs unnecessary complexity.

package/modules/exploratory-testing/content.md

@@ -0,0 +1,133 @@
+# Exploratory Testing — Structured Discovery of Bugs
+
+<!-- hint:slides topic="Exploratory testing: exploratory vs scripted, session-based test management, charters, SFDPOT heuristic, and note-taking" slides="5" -->
+
+## Exploratory vs Scripted Testing
+
+**Scripted testing**: Follow predefined steps. Repeatable, good for regressions.
+**Exploratory testing**: Simultaneous learning, test design, and execution. You explore based on what you discover. Ideal for finding unknown unknowns.
+
+They complement each other. Use scripted tests for known risks; use exploratory for discovery.
+
+## Session-Based Test Management (SBTM)
+
+James Bach's framework structures exploratory testing into **time-boxed sessions** with clear charters and debriefs.
+
+### Session Structure
+
+- **Charter**: What to explore (1–2 sentences).
+- **Time box**: 60–90 minutes typical.
+- **Uninterrupted focus**: No meetings, minimal context switching.
+- **Notes**: Log what you tried, found, and questions.
+- **Debrief**: Summary for the team.
+
+```mermaid
+flowchart TD
+    A[Define charter] --> B[Start timer]
+    B --> C[Explore: try, observe, note]
+    C --> D{Time up or scope done?}
+    D -->|No| C
+    D -->|Yes| E[End session]
+    E --> F[Debrief: findings, risks, bugs]
+    F --> G[Create bug reports]
+```
+
+## Test Charters
+
+A charter guides exploration without prescribing steps. Format:
+
+> **Explore** [target] **with** [resources/tools] **to discover** [information].
+
+### Examples
+
+- Explore the checkout flow with a test credit card to discover payment failure handling.
+- Explore the search feature with various input lengths to discover how results are truncated.
+- Explore the profile page with different user roles to discover permission gaps.
+
+Charters give direction but not instructions. You decide *how* to explore.
+
+## SFDPOT — A Heuristic for Coverage
+
+Elisabeth Hendrickson's **SFDPOT** helps ensure you don't miss areas:
+
+| Letter | Area | Questions |
+|--------|------|-----------|
+| **S** | Structure | UI layout, navigation, menus, links |
+| **F** | Function | Features work as stated? |
+| **D** | Data | Valid, invalid, boundary, empty, special chars |
+| **P** | Platform | Browsers, OS, devices, screen sizes |
+| **O** | Operations | Install, upgrade, backup, config |
+| **T** | Time | Delays, timeouts, dates, concurrent users |
+
+Use SFDPOT to generate charter ideas: "Explore [Structure] of the dashboard to discover layout bugs on narrow viewports."
+
+## Note-Taking During Sessions
+
+Capture:
+
+- **What you did**: Steps, inputs, paths.
+- **What you observed**: Bugs, odd behavior, questions.
+- **Ideas**: New charters, areas to revisit.
+
+Keep notes lightweight: bullet points, timestamps, screenshots. A session report template:
+
+```
+Charter: Explore X with Y to discover Z
+Time: 14:00–15:30
+Tester: [name]
+
+Exploration notes:
+- Tried A → observed B
+- Bug: [brief description]
+- Question: [unresolved]
+
+Bugs found: 2
+Risks: [areas of concern]
+```
+
+## Bug Reporting
+
+Good bug reports have:
+
+- **Title**: One-line summary.
+- **Steps to reproduce**: Numbered, precise.
+- **Expected vs actual**: What should happen vs what did.
+- **Environment**: Browser, OS, version.
+- **Screenshots/videos**: When helpful.
+- **Severity**: Impact and frequency.
+
+```
+Title: Search returns no results when query contains &
+Steps: 1. Go to /search. 2. Enter "A&B Corp". 3. Click Search.
+Expected: Results for "A&B Corp"
+Actual: "No results found"
+Env: Chrome 120, MacOS
+```
+
+## Debrief Sessions
+
+After exploration, share:
+
+- **Findings**: Bugs, risks, positive discoveries.
+- **Coverage**: What you did and didn't cover.
+- **Charters for next time**: Unfinished areas.
+- **Blockers**: What stopped you (e.g., missing access).
+
+Debriefs turn individual exploration into team learning.
+
+## Combining Exploratory with Automated Testing
+
+- **Before release**: Exploratory sessions on new features.
+- **After automation**: Exploratory to find what automation misses (UX, edge cases, integration quirks).
+- **Charters from automation gaps**: "Explore areas with low e2e coverage to discover risks."
+
+---
+
+## Key Takeaways
+
+1. **Exploratory = learning + designing + executing** — not ad-hoc clicking.
+2. **SBTM** — time-boxed sessions with charters and debriefs.
+3. **Charters** — "Explore X with Y to discover Z" — guide without scripting.
+4. **SFDPOT** — heuristic for broad coverage.
+5. **Notes and debriefs** — make exploration visible and actionable.
+6. **Combine** exploratory with automated tests for balanced quality.

package/modules/exploratory-testing/exercises.md

@@ -0,0 +1,88 @@
+# Exploratory Testing Exercises
+
+## Exercise 1: Charter Writing Practice
+
+**Task:** Write 3 test charters for a "User Profile" page that allows editing name, avatar, and notification preferences. Use the format: Explore [target] with [resources] to discover [information]. Make each charter focus on a different aspect (e.g., Structure, Data, Function).
+
+**Validation:**
+- [ ] Each charter has target, resources, and discovery goal
+- [ ] Charters are distinct (not redundant)
+- [ ] Charters are specific enough to guide a 30–60 min session
+
+**Hints:**
+1. Vary the "with" — different data, different roles, different devices
+2. Vary the "discover" — bugs, UX, performance, accessibility
+3. One charter per SFDPOT area is a good spread
+
+---
+
+## Exercise 2: SFDPOT Coverage Analysis
+
+**Task:** For an app you've tested (or a hypothetical one), list which SFDPOT areas you typically cover and which you skip. For one skipped area, write a charter that would address it.
+
+**Validation:**
+- [ ] Identifies at least 2 often-skipped areas
+- [ ] Explains why they're skipped (time, habit, tooling)
+- [ ] One charter targets a gap
+
+**Hints:**
+1. Platform (P) and Time (T) are commonly skipped
+2. Operations (O) — install, upgrade, config — often forgotten
+3. "We never test on Safari" → Platform charter
+
+---
+
+## Exercise 3: Session Notes to Bug Report
+
+**Task:** You have these raw session notes:
+
+- Clicked "Add to cart" 3 times quickly → cart showed 1 item
+- Tried empty search → spinner forever
+- Pasted 5000 chars in "Notes" → UI froze for 2 sec
+
+Convert one of these into a proper bug report (title, steps, expected, actual, environment).
+
+**Validation:**
+- [ ] Title is concise and descriptive
+- [ ] Steps are reproducible (someone else could follow them)
+- [ ] Expected vs actual is clear
+- [ ] Environment is specified
+
+**Hints:**
+1. "3 times quickly" — how quick? Add timing if relevant
+2. "5000 chars" — exact count or range helps
+3. Include browser/OS if it might matter
+
+---
+
+## Exercise 4: Debrief Summary
+
+**Task:** After a hypothetical session on a "Password reset" flow, you found: (1) Email validation allows "test@"; (2) Reset link expires after 5 min but error says "invalid"; (3) Success message appears before email is actually sent. Write a 5-bullet debrief summary for your team.
+
+**Validation:**
+- [ ] Bugs are listed clearly
+- [ ] Risks or patterns are noted (e.g., "validation inconsistent")
+- [ ] Next steps or charters suggested
+- [ ] Tone is factual, not blaming
+
+**Hints:**
+1. Group related issues (e.g., "error messaging")
+2. Prioritize: what's critical vs nice-to-fix
+3. Suggest: "Charter for email delivery and expiration edge cases"
+
+---
+
+## Exercise 5: Exploratory + Automation Plan
+
+**Task:** A "Drag-and-drop file upload" feature is new. You have 2 hours. Propose a plan: how much time for exploratory vs writing/reviewing automated tests? What charters? What would you automate?
+
+**Validation:**
+- [ ] Exploratory time is allocated first (discovery before automation)
+- [ ] At least 2 charters for exploratory
+- [ ] Automation targets are clear (e.g., "happy path upload")
+- [ ] Rationale for the split
+
+**Hints:**
+1. Exploratory finds edge cases; automate the obvious happy path
+2. File types, sizes, network failures — exploratory
+3. "Upload valid file, see in list" — automate

package/modules/exploratory-testing/module.yaml

@@ -0,0 +1,41 @@
+slug: exploratory-testing
+title: "Exploratory Testing — Structured Discovery of Bugs"
+version: 1.0.0
+description: "Learn session-based exploratory testing, test charters, and heuristics to find bugs systematically."
+category: quality-assurance
+tags: [exploratory-testing, manual-testing, bug-hunting, quality, test-charters]
+difficulty: intermediate
+
+xp:
+  read: 15
+  walkthrough: 40
+  exercise: 25
+  quiz: 20
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 20
+  guided: 50
+
+prerequisites: [test-strategy]
+related: [debugging-systematically, accessibility-fundamentals]
+
+triggers:
+  - "What is exploratory testing?"
+  - "How do I find bugs without a test plan?"
+  - "What are test charters?"
+  - "How do I do structured manual testing?"
+
+visuals:
+  diagrams: [diagram-flow, diagram-mermaid]
+  quiz-types: [quiz-drag-order, quiz-timed-choice]
+  slides: true
+
+sources:
+  - url: "https://www.amazon.com/Explore-It-Reduce-Risk-Exploratory/dp/1937785025"
+    label: "Explore It! by Elisabeth Hendrickson (book)"
+    type: book
+  - url: "https://www.satisfice.com/download/session-based-test-management"
+    label: "Session-Based Test Management (James Bach)"
+    type: docs

package/modules/exploratory-testing/quick-ref.md

@@ -0,0 +1,68 @@
+# Exploratory Testing Quick Reference
+
+## Charter Format
+
+```
+Explore [target] with [resources] to discover [information]
+```
+
+## SFDPOT Heuristic
+
+| Letter | Area | Example Focus |
+|--------|------|---------------|
+| S | Structure | UI, navigation, layout |
+| F | Function | Features, behavior |
+| D | Data | Valid, invalid, bounds, empty |
+| P | Platform | Browsers, OS, devices |
+| O | Operations | Install, upgrade, config |
+| T | Time | Delays, timeouts, concurrency |
+
+## SBTM Session Flow
+
+```
+Charter → Timer → Explore (try, observe, note) → End → Debrief
+```
+
+## Session Notes Template
+
+```
+Charter: ...
+Time: ...
+Tester: ...
+
+Exploration: [what you did, what you saw]
+Bugs: [list]
+Risks: [concerns]
+Next charters: [ideas]
+```
+
+## Bug Report Checklist
+
+- [ ] Title (one line)
+- [ ] Steps to reproduce (numbered)
+- [ ] Expected vs actual
+- [ ] Environment (browser, OS)
+- [ ] Screenshots/video (when helpful)
+
+## Debrief Outline
+
+- Findings (bugs, risks)
+- Coverage (what was/wasn't tested)
+- Next charters
+- Blockers
+
+## Exploratory vs Scripted
+
+| Exploratory | Scripted |
+|-------------|----------|
+| Learn + design + execute | Follow predefined steps |
+| Discovery, unknowns | Regression, known risks |
+| Charters guide | Test cases define |
+| Debrief shares learning | Results are pass/fail |
+
+## One-Liners
+
+- **Charter**: Guide, don't prescribe.
+- **SFDPOT**: Don't skip Platform, Time, or Operations.
+- **Debrief**: Turn exploration into team learning.
+- **Combine**: Exploratory finds gaps; automation locks in coverage.

package/modules/exploratory-testing/quiz.md

@@ -0,0 +1,75 @@
+# Exploratory Testing Quiz
+
+## Question 1
+
+What is the main difference between exploratory and scripted testing?
+
+A) Exploratory is faster; scripted is more thorough
+B) Exploratory combines learning, design, and execution; scripted follows predefined steps
+C) Exploratory is only for manual testers; scripted is for automation
+D) There is no real difference
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Exploratory testing involves simultaneous learning about the product, designing tests on the fly, and executing them. Scripted testing follows a predefined test plan with fixed steps. Both can be manual or involve tools. -->
+
+## Question 2
+
+What is a test charter?
+
+A) A formal test plan with detailed steps
+B) A short directive that guides exploration: Explore X with Y to discover Z
+C) A list of all bugs found in a session
+D) A tool used for automation
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: A test charter is a brief mission statement that gives direction without prescribing exact steps. It guides what to explore, with what resources, and what information to discover. -->
+
+## Question 3
+
+What does SFDPOT stand for?
+
+A) A test automation framework
+B) A heuristic for test coverage: Structure, Function, Data, Platform, Operations, Time
+C) A bug severity classification
+D) A type of test charter
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: SFDPOT is a heuristic by Elisabeth Hendrickson to ensure broad coverage across structure, function, data, platform, operations, and time—areas that are easy to overlook. -->
+
+## Question 4
+
+Why is a debrief valuable after an exploratory session?
+
+A) It's required by process
+B) It turns individual findings into shared learning, context, and next steps
+C) It replaces bug reports
+D) It's only for managers
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Debriefs summarize findings, risks, coverage, and ideas for future charters. They add context and priorities that raw bug reports don't capture, and help the team decide what to do next. -->
+
+## Question 5
+
+What should a good bug report include?
+
+A) Only a title and severity
+B) Steps to reproduce, expected vs actual, environment, and screenshots when helpful
+C) Opinions about the developer's code
+D) Only the actual behavior
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: A good bug report enables someone else to reproduce the issue. It needs clear steps, expected vs actual behavior, environment details, and visual evidence when useful. -->
+
+## Question 6
+
+Drag these SBTM session steps into the correct order:
+
+<!-- VISUAL: quiz-drag-order -->
+
+A) Define charter → Start timer → Explore → End session → Debrief
+B) Explore → Debrief → Define charter → Start timer
+C) Start timer → Explore → Define charter → Debrief
+D) Debrief → Explore → Define charter → End session
+
+<!-- ANSWER: A -->
+<!-- EXPLANATION: In Session-Based Test Management, you first define a charter, then start the time box, explore, end when time is up or scope is done, and finally debrief to share findings. -->

package/modules/exploratory-testing/resources.md

@@ -0,0 +1,39 @@
+# Exploratory Testing — Resources
+
+## Books
+
+- **Explore It! Reduce Risk and Increase Confidence with Exploratory Testing** by Elisabeth Hendrickson — Charters, heuristics, and practical techniques. The go-to book on exploratory testing.
+- **Session-Based Test Management** (PDF) by Jonathan Bach & James Bach — The original SBTM paper. Time-boxed sessions, charters, debriefs.
+- **Lessons Learned in Software Testing** by Cem Kaner, James Bach, Bret Pettichord — Context-driven testing, exploratory mindset.
+
+## Articles
+
+- [Session-Based Test Management](https://www.satisfice.com/download/session-based-test-management) — James Bach. Original SBTM methodology.
+- [Exploratory Testing Explained](https://www.ministryoftesting.com/articles/exploratory-testing-explained) — Ministry of Testing. Clear introduction.
+- [How to Use SFDPOT Heuristic](https://www.developsense.com/blog/2010/02/sfdpot/) — Michael Bolton. Applying SFDPOT in practice.
+- [Heuristic Test Strategy Model](https://www.satisfice.com/download/heuristic-test-strategy-model) — James Bach. Broader model for test design.
+
+## Videos
+
+- [Exploratory Testing — Elisabeth Hendrickson](https://www.youtube.com/watch?v=7LsS9Yl0NDg) — Keynote on exploration and charters.
+- [Session-Based Testing — James Bach](https://www.youtube.com/watch?v=4QdR0Mdt-cs) — SBTM in practice.
+- [Ministry of Testing — Exploratory Testing](https://www.youtube.com/results?search_query=ministry+of+testing+exploratory) — Various talks and workshops.
+
+## Communities
+
+- [Ministry of Testing](https://www.ministryoftesting.com/) — Community, articles, TestBash conferences.
+- [Software Testing Stack Exchange](https://sqa.stackexchange.com/) — Q&A on testing topics.
+- [Association for Software Testing](https://www.associationforsoftwaretesting.org/) — Conferences, workshops, BBST courses.
+
+## Tools
+
+- [Session Tester](https://www.sessiontester.com/) — Session tracking and charter management.
+- [Rapid Reporter](https://www.theconnective.co.uk/rapid-reporter/) — Lightweight note-taking during sessions.
+- [Azure DevOps / Jira](https://www.atlassian.com/software/jira) — Bug tracking integrated with charters and sessions.
+- [OBS Studio](https://obsproject.com/) — Screen recording for bug reports and session evidence.
+
+## Quick References
+
+- [SFDPOT Cheat Sheet](https://www.developsense.com/blog/2010/02/sfdpot/) — One-page SFDPOT reminder.
+- [Charter Template](https://www.ministryoftesting.com/articles/writing-exploratory-testing-charters) — Examples and templates.
+- [Bug Report Template](https://www.atlassian.com/software/jira/guides/getting-started/best-practices) — Jira best practices for bug reports.

package/modules/exploratory-testing/walkthrough.md

@@ -0,0 +1,87 @@
+# Exploratory Testing Walkthrough — Learn by Doing
+
+## Before We Begin
+
+**Diagnostic Question:** What's the difference between "running tests" and "exploratory testing"? When would you choose one over the other?
+
+**Checkpoint:** You recognize that scripted tests verify known behavior, while exploratory testing discovers what you don't yet know. Both matter; they serve different purposes.
+
+---
+
+## Step 1: Write a Test Charter
+
+<!-- hint:list style="checklist" -->
+
+You're about to explore a new "Export to CSV" feature. The feature lets users export a filtered list of orders.
+
+**Task:** Write a test charter for this feature using the format: "Explore [target] with [resources] to discover [information]."
+
+**Question:** What makes a charter too narrow vs too broad? How would you know when you're "done" with this charter?
+
+**Checkpoint:** User writes a charter like "Explore the Export to CSV feature with various filter combinations to discover data accuracy and format issues." They understand narrow = prescriptive; broad = vague. Done when time box ends or key areas covered.
+
+---
+
+## Step 2: Use SFDPOT to Generate Charters
+
+<!-- hint:card type="concept" title="SFDPOT" -->
+
+Pick a feature you know: e.g., a login form, a search bar, or a settings page.
+
+**Task:** For each letter of SFDPOT, write one charter idea. You don't have to execute them—just generate possibilities. (Example for F: "Explore the Function of the login form with invalid credentials to discover error messages.")
+
+**Question:** Which SFDPOT areas do you usually skip when testing? Why might that hide bugs?
+
+**Checkpoint:** User produces 6 charter ideas. They reflect on often-skipped areas (often Platform, Time, Operations) and recognize these can hide real issues.
+
+---
+
+## Step 3: Conduct a Mini Session
+
+<!-- hint:buttons type="single" prompt="How did having a charter change your exploration?" options="Focused my attention,Made it rigid,No difference" -->
+
+Pick any web app or tool you can access (e.g., a todo app, a calculator). Set a 10-minute timer.
+
+**Task:** Run a mini exploratory session. Charter: "Explore [pick one area] with [a constraint] to discover [something]." Take notes as you go: what you tried, what you saw, any bugs or questions.
+
+**Question:** How did having a charter change your exploration compared to "just clicking around"?
+
+**Checkpoint:** User completes a short session with notes. They notice the charter focused their attention; they found at least one observation (bug or quirk) they might have missed without structure.
+
+---
+
+## Step 4: Write a Bug Report
+
+Suppose during exploration you found: When you paste a long URL into a "Share link" field, the Save button does nothing and no error appears.
+
+**Task:** Write a bug report with: title, steps to reproduce, expected vs actual, and environment. Aim for clarity so a developer can reproduce it without talking to you.
+
+**Question:** What's the risk of writing "sometimes it doesn't work" without clear steps?
+
+**Checkpoint:** User writes numbered steps, clear expected/actual, and environment. They understand vague reports waste time and block fixes.
+
+---
+
+## Step 5: Plan a Debrief
+
+You've just finished a 90-minute session on a checkout flow. You found 2 bugs and noticed the "Apply coupon" field behaves oddly with special characters.
+
+**Task:** Outline what you'd cover in a 10-minute debrief. What would you tell the team? What would you ask for?
+
+**Question:** Why is a debrief valuable even if you've already filed bug reports?
+
+**Checkpoint:** User lists: bugs found, risks (coupon field), coverage (what was/wasn't tested), suggested next charters, blockers. They see debrief adds context, priorities, and ideas for follow-up that raw bug reports don't.
+
+---
+
+## Step 6: Combine Exploratory with Automation
+
+<!-- hint:diagram mermaid-type="flowchart" topic="exploratory and automation workflow" -->
+
+Your team has good e2e coverage for happy paths. A new "Bulk actions" feature was just added.
+
+**Task:** Propose how exploratory and automated testing could work together. When would you run exploratory? What charters might fill gaps that automation won't cover?
+
+**Question:** What kinds of bugs does automation typically miss that exploratory can find?
+
+**Checkpoint:** User suggests: exploratory first on new feature to find risks, then automate critical paths. Automation misses UX quirks, odd input combinations, cross-browser issues, performance under load—exploratory can target those with charters.