feat: add comprehensive test design techniques guide and Wopee.io integration (#124)

- Introduced a new blog post detailing essential test design techniques for web applications, covering boundary value analysis, equivalence partitioning, risk-based prioritization, and model-driven strategies.
- Added practical examples and implementation tips to enhance testing efficiency and coverage.
- Created a follow-up post demonstrating how to apply these techniques using Wopee.io, including ready-to-use prompts for generating tests.
- Included multiple illustrative images to support the content and improve user engagement.

Author: marcel-veselka

blog/2025-08-05-test-design-techniques/index.md

@@ -0,0 +1,185 @@
+---
+slug: test-design-techniques
+title: "Essential test design techniques for web apps"
+description: "Learn proven test design techniques for web applications—including boundary value analysis, equivalence partitioning, risk-based prioritization, and model-driven strategies—to maximize testing efficiency and coverage."
+tags: [qa, test automation, test design techniques, user stories]
+image: /img/blog/test-design-techniques.png
+authors: marcel
+---
+
+Want broader coverage with fewer tests?
+
+These **test design techniques** help you create a **smallest set of most effective tests**.
+
+This short guide covers **boundary value analysis (BVA)**, **equivalence partitioning (EP)**, **risk-based prioritization**, and **model/state-transition testing**.
+
+You’ll learn **when to use each technique, how to design the cases, and the minimal set** that gives maximum signal.
+
+<!--truncate-->
+
+## Why test design techniques matter
+
+Without structure, testing devolves into guesswork and redundancy. Design techniques give you a repeatable way to select high-value tests and avoid wasted effort.
+
+**What good test design delivers**
+
+- **Eliminates redundancy** using **equivalence partitioning (EP)**
+- **Catches edge bugs early** with **boundary value analysis (BVA)**
+- **Focuses where it hurts** via **risk-based prioritization**
+- **Covers complex flows** using **model- and state-transition testing**
+- **Improves maintenance** by organizing tests around **models and risks**, not pages
+
+---
+
+## Use boundary & equivalence to minimize cases
+
+**When to use**: Any input validation (forms, APIs, ranges, enums, formats).
+
+**How to design**
+
+1. Identify input domains (range, set, format).
+2. Create **partitions** (valid + invalid).
+3. Pick **one representative** per partition (EP).
+4. Add **BVA** around each limit: just below, at, just above.
+
+**Minimal set example (age: 18–65 inclusive)**
+
+| Partition        | Representative |
+| ---------------- | -------------- |
+| valid (in-range) | 25             |
+| valid (in-range) | 45             |
+| valid (in-range) | 60             |
+| invalid (< 18)   | 17             |
+| invalid (> 65)   | 66             |
+
+**BVA targets**: 17, **18**, **65**, 66
+
+> Tip: one mid-range value per valid partition is usually enough. Add more only if the code handles subranges differently.
+
+## Decision table (small, real example)
+
+Discount applies when **loyalty = gold** **and** **cart ≥ 100**.
+
+| Loyalty | Cart ≥ 100 | Expect           |
+| ------- | ---------- | ---------------- |
+| bronze  | false      | no discount      |
+| bronze  | true       | no discount      |
+| gold    | false      | no discount      |
+| gold    | true       | discount applied |
+
+> If rules × inputs explode, consider pairwise generation or MBT to keep the table tractable.
+
+---
+
+## Prioritize risks, then explore to find surprises
+
+**When to use**: Planning sprints/releases; scoping a suite under time pressure.
+
+**How to design**
+
+1. Score features on **Impact** (business/user) × **Likelihood** (defect/complexity/change).
+2. Test **high-impact/high-likelihood** first; **high-impact/low-likelihood** next.
+3. Allocate **exploratory charters** to the highest-risk zones.
+
+**Quick 2×2**
+
+- **High/High** → automate critical paths + explore each release
+- **High/Low** → smoke checks + targeted exploration
+- **Low/High** → lightweight checks, observe in prod/telemetry
+- **Low/Low** → sample or defer
+
+**Exploratory session charter (template)**
+
+- **Area**: Payments → promo codes
+- **Start with**: expired code, special characters, rapid apply/remove
+- **Risks**: rounding, concurrency, caching
+- **Timebox**: 45 minutes
+- **Capture**: notes, defects, screenshots, data used
+
+**Error-guessing checklist (starter)**
+
+- empty/huge inputs, whitespace, special characters
+- copy/paste, different keyboard layouts, IME input
+- rapid submit/double-click/back/refresh sequences
+- timeouts, slow network, offline/restore
+- concurrency: two tabs/users editing the same entity
+
+<img
+src={require('./prioritize-risks.png').default}
+alt="Prioritizing risks"
+style={{ width: '50%', height: 'auto', display: 'block', margin: '1rem auto' }}
+/>
+
+_Prioritizing risks_
+
+---
+
+## Model workflows with state transitions & BDD
+
+**When to use**: Multi-step flows, role-based behavior, approvals, wizards.
+
+**How to design**
+
+1. List states and allowed transitions (a sketch or bullets is enough).
+2. Cover **all valid transitions** at least once; include **invalid transitions** as negative tests.
+3. Use **0-switch/1-switch coverage**: single transitions and adjacent transition pairs.
+
+**Example transitions (account recovery)**
+
+- Valid: `Start → RequestToken → EmailSent → ResetForm → Success`
+- Invalid: `Start → ResetForm` (no token) → expect a clear error
+
+**BDD scenario (executable specification)**
+
+```gherkin
+Feature: Password reset
+
+  Scenario: Valid token enables password reset
+    Given a user requested a reset token
+    And the token is valid and not expired
+    When the user sets a new password that meets complexity
+    Then the user can sign in with the new password
+```
+
+**User story → tests (traceability mini-map)**
+
+- Extract **happy path**, **alternate paths**, **negative paths**
+- Link each scenario to **acceptance criteria**
+- Map tests → story IDs for coverage reporting
+
+---
+
+## Implementation tips
+
+- **Start each feature** with EP + BVA for inputs—keep it tiny and repeatable.
+- **Re-score risks each sprint**; prune or elevate tests based on change and incident data.
+- **Schedule exploratory charters** for top-risk areas every release.
+- **Automate from models**: generate cases from state charts/decision tables where feasible.
+- **Track four signals**:
+
+  - **defect yield** (by technique)
+  - **redundancy removed** (tests deleted/merged)
+  - **flake rate** (before/after design cleanup)
+  - **requirements coverage** (stories ↔ tests)
+
+---
+
+## Summary
+
+- **Strategic efficiency**: choose tests that add unique value, not volume.
+- **EP + BVA**: cover representative inputs and edges with minimal cases.
+- **Risk + exploration**: spend time where failures matter and surprises hide.
+- **Models & states**: make complex flows testable and maintainable.
+- **Traceability**: turn user stories and acceptance criteria into executable checks.
+
+:::tip transform your test design approach 🎯
+Skip manual test case creation.
+[Wopee.io](https://wopee.io) maps your app, applies user story-based test generation, explores high-risk flows, and generates coverage in minutes.
+
+**Test better. Ship faster.**
+
+---
+
+Tip: Read more about [how to apply test design techniques](test-design-techniques-w-wopee) when you generate tests with [Wopee.io](https://wopee.io).
+
+:::

blog/2025-08-05-test-design-techniques/prioritize-risks.png

@@ -0,0 +1,194 @@
+---
+slug: test-design-techniques-w-wopee
+title: "Test design techniques with Wopee.io"
+description: "Follow-up to our test design guide: ready-to-use prompts for BVA/EP, decision tables, and risk-based testing — using examples with the Swag Labs demo project inside Wopee.io."
+tags: [qa, test automation, test design techniques, prompts]
+image: /blog/wopee-commander.png
+authors: marcel
+---
+
+The era of manually writing tests is soo 2005. We can now generate tests automatically with LLMs.
+
+However, still, it is good to drive the test design process by human. ... at least until the current tools are good enough.
+
+Want to turn the theory into executable tests?
+
+Here are a few examples with the Swag Labs demo project inside Wopee.io Commander: a **copy-paste prompts** tailored to the Swag Labs demo project so you can generate real scenarios.
+
+<!--truncate-->
+
+[Test design techniques](/blog/test-design-techniques) are important to achieve comprehensive test coverage and assure effective testing.
+
+## Example prompts you can use
+
+Feel free to use the prompts below as a starting point and adapt them to your needs.
+
+All the examples below are for user story:
+
+> _As a shopper, I want to enter my shipping information_.
+
+In order to use the prompts below, go to **Analysis → 4. Test Cases**, pick the user story, and paste the prompt below. See below for the [detailed steps](#how-to-use-wopeeio-commander-quick-steps).
+
+---
+
+### A. BVA/EP for checkout info
+
+Use Boundary Value Analysis (BVA) and Equivalence Partitioning (EP) to create a **minimal set** of positive/negative tests around the required buyer fields before moving to the overview page.
+
+```
+Use BVA/EP test design technique to create a minimal set of positive/negative tests around the required buyer fields before moving to the overview page.
+
+Scope: First Name, Last Name, Postal Code
+
+Goal: Generate the smallest test set that proves required-field gating works and handles edge inputs.
+
+Design:
+- EP: {filled vs empty} for each field; {valid vs clearly invalid} for postalCode.
+- BVA around length: 0, 1, typical (5), long (100+) for each field.
+- Combine minimally to avoid duplicates; show which partition/boundary each case covers.
+- Each test should cover end-to-end flow: from login → cart → checkout → overview.
+
+Generate:
+- Positive path that advances to overview when all fields are valid.
+- Negative cases that block progression with clear errors when one or more fields are empty/invalid.
+- Use emojis to make the test design more fun.
+```
+
+Why this works here: User story explicitly requires first/last name and postal code and blocks progression on missing data; advancing shows the **order overview**.
+
+### Generated tests for BVA/EP example
+
+![Wopee.io Commander](./example-bva-ep.png)
+
+_Wopee.io Commander with test cases generated for the user story, BVA/EP_
+
+---
+
+### B. Decision table for “continue” gating
+
+Model the **rules for advancing** from `checkout info` → `overview` using a compact decision table (presence/absence of required fields).
+
+```
+Use decision table test design technique to model the rules for advancing from checkout info → overview.
+
+Rules:
+- Continue is allowed only when firstName, lastName, and postalCode are all provided.
+- Otherwise: progression is blocked; show clear error/highlight on missing fields.
+
+Please:
+1) Produce a decision table with the three conditions (FName?, LName?, Zip?) → Outcome (Advance/Blocked + which field errors).
+2) Generate the minimal set of unique test cases from that table (no duplicates).
+3) Include steps and expected results for each case.
+4) Into test description field, add a short "Mitigates risk:" note to each test (Impact, Likelihood).
+5) Use emojis extensively to make the final tests fun to read.
+```
+
+This aligns with Swag Labs behavior: missing any of the three required inputs prevents progression and highlights errors; with all present, the flow proceeds to the **overview** and later to **confirmation**.
+
+### Generated tests for decision table example
+
+![Wopee.io Commander](./example-decision-table.png)
+
+_Wopee.io Commander with test cases generated for the user story, decision table_
+
+---
+
+### C. Risk-based testing: prioritize what matters first
+
+This version bakes priority **into the test names** so your suite is immediately ordered. Use the prefixes:
+
+- `prio-H` = high impact × high likelihood (test first)
+- `prio-M` = medium
+- `prio-L` = low
+
+**Risk focus for user story**
+
+- **High**: required-field gating (firstName, lastName, postalCode), invalid postal code formats, and the ability to continue only when all fields are valid.
+- **Medium**: whitespace handling (trim vs. all-spaces), max/min lengths, state persistence when navigating back from Overview.
+- **Low**: special characters, accessibility focus on first invalid field, non-Latin characters.
+
+Copy-paste prompt (risk-based, with priority in names):
+
+```
+Use risk-based testing with explicit priority prefixes in test names.
+
+Goal:
+- Generate a prioritized suite for the user story.
+- Prefix every test title with one of emojis: High 🔴, Medium 🟠, Low 🟢
+- One deterministic automated test per risk; include preconditions, steps, and expected results.
+
+Risk model (Impact × Likelihood)
+
+High (prio-H) — must-have paths and hard blockers:
+- prio-H - cannot continue with empty firstName
+- prio-H - cannot continue with empty lastName
+- prio-H - cannot continue with empty postalCode
+- prio-H - rejects invalid postalCode format (e.g., "ABC", "12-3")
+- prio-H - can continue when all fields are valid and reaches Overview page
+
+Medium (prio-M) — common edge behaviors:
+- prio-M - trims leading/trailing spaces before validation ("  John  " → "John")
+- prio-M - all-whitespace is treated as empty and blocks progression
+- prio-M - field length boundaries: 0, 1, typical (10), long (100+) with expected outcomes
+- prio-M - values persist when navigating back from Overview to Info and then forward again
+
+Low (prio-L) — nice-to-have quality checks:
+- prio-L - handles special characters without crashing (names with hyphen/accents)
+- prio-L - focus moves to the first invalid field when Continue fails
+- prio-L - accepts non-Latin letters if supported; otherwise shows a clear validation error
+
+Generation requirements
+- For negatives, verify error text and that the page does NOT advance.
+- For the positive case, assert navigation to Overview and presence of order summary.
+- Add a short "Mitigates risk:" note to each test (Impact, Likelihood) into test description field.
+```
+
+Note: There are no validations or any other logic for the fields in the Swag Labs demo project. This is just an example.
+
+### Generated tests for risk-based testing example
+
+![Wopee.io Commander](./example-risk-based.png)
+
+_Wopee.io Commander with test cases generated for the user story, risk-based testing_
+
+---
+
+## How to use Wopee.io Commander (quick steps)
+
+### 1. Go to **Analysis → 4. Test Cases** (Commander).
+
+![Wopee.io Commander](./wopee-commander.png)
+
+_Wopee.io Commander with test cases generated for the user stories, step 1: Analysis → 4. Test Cases_
+
+### 2. **Add a user story** you want to cover.
+
+![Wopee.io Commander](./wopee-commander-add-user-story.png)
+
+_Wopee.io Commander with test cases generated for the user stories, step 2: Add user story_
+
+### 3. Select the user story, then paste a prompt (see below).
+
+![Wopee.io Commander](./wopee-commander-select-user-story.png)
+
+_Wopee.io Commander with test cases generated for the user stories, step 3: Paste a prompt_
+
+### 4. Click **`GENERATE`** to create the test cases.
+
+:::caution heads-up
+
+If you pick an existing user story that already has scenarios, the generator will **rewrite** them.
+
+:::
+
+:::tip fast path
+
+## Generate your tests automatically too
+
+Wopee.io maps your app. Create tests. Automate instantly.
+
+<br />
+
+Paste a prompt and then let our AI Agent map your app, generate rest of the test cases. You will get automated tests right in [Wopee.io](https://wopee.io) Commander.
+
+:::