> tpl_qav_003
Test Case Design and Exploratory-Test Charter Pack
Comprehensive test design framework combining formal specification-based test cases (Equivalence Partitioning, Boundary Value Analysis, Decision Tables, Gherkin BDD) with structured time-boxed Exploratory Test Charters under Session-Based Test Management (SBTM).
Unified test design framework combining formal specification techniques with Session-Based Exploratory Test Charters.
Important Tech Document Template & Operational Notice
TinyCTO.tv Tech Document Template Notice: This template is a general educational and operational starting point. It is not legal, tax, accounting, investment, procurement, regulatory, security or certification advice. Requirements vary by jurisdiction, organization, contract and risk. Review and adapt it with qualified professionals before relying on it.
Problem Solved
Engineering teams either write brittle, unmaintainable step-by-step test scripts that miss real-world user flows, or conduct unstructured ad-hoc testing with zero repeatable evidence or traceability.
When to Use
- •Designing robust, maintainable test case repositories for web applications, APIs, and microservices
- •Conducting structured exploratory testing sessions using Session-Based Test Management (SBTM)
- •Bridging Business Analysts, Product Owners, and Engineers using Gherkin Given-When-Then behavioral specifications
When NOT to Use
- •For overarching release governance and quality gate sign-offs (use TPL-QAV-002)
- •For business user acceptance testing workflows and UAT sign-off sheets (use TPL-QAV-004)
5 Template Sections & Structural Outline
Applying rigorous black-box techniques: Equivalence Partitioning (EP), Boundary Value Analysis (BVA), Decision Table Testing, and State Transition Testing to maximize defect discovery with minimal test cases.
Authoring clean Gherkin feature files using Feature, Scenario, Given, When, Then, and Scenario Outline tables to serve as living documentation between Product and QA.
Structuring focused exploratory charters: Mission, Target Areas, Persona, Timebox (60-90 min), Heuristics used (SFDIPOT), and bug reporting guidelines.
Designing boundary value data fixtures, positive/negative payloads, edge-case Unicode strings, and concurrency stress conditions.
Building bidirectional links between User Story / PRD requirements, automated test IDs, manual test cases, and discovered defects.
Completion Instructions
Independent Review Checklist
- All mandatory sections completed
- No secrets or passwords included
- Executive sponsor sign-off obtained
Test Case Design and Exploratory-Test Charter Pack - Worked Case Study
Fictional Entity: Payments & Settlement Engineering QA Guild
Real-world production case study demonstrating complete operational adoption for Payments & Settlement Engineering QA Guild.
- •Designed 450+ high-efficiency boundary value and decision table test cases covering multi-currency transactions
- •Discovered 34 high-severity edge-case defects through structured 90-minute SBTM exploratory sessions
- •Achieved 100% bidirectional requirements traceability between Jira Epics and Cucumber BDD scenarios
Frequently Asked Questions
What is the key difference between formal test cases and exploratory test charters?
Formal test cases are predefined, scripted procedures verifying that specific explicit requirements operate as designed (essential for regressions). Exploratory test charters are time-boxed, mission-guided investigations where the tester actively learns, designs, and executes tests simultaneously to uncover unscripted edge cases and subtle UX flaws.
How does Session-Based Test Management (SBTM) provide governance over exploratory testing?
SBTM structures exploratory testing into uninterrupted 60-to-90-minute sessions governed by a formal charter. Each session concludes with standardized metrics: session duration, percentage of time spent testing vs. bug investigation vs. environment setup, and a list of identified bugs and open questions.
Why should BDD Gherkin scenarios avoid UI implementation details?
Gherkin scenarios should describe user intent and business rules (e.g. "Given an authenticated premium user, When they checkout with an expired card, Then transaction is declined with re-entry prompt") rather than brittle UI actions ("When user clicks button #submit-btn"), preventing test suite failure during cosmetic UI redesigns.
Download Tech Document Pack
Auth RequiredDownload all blank templates, worked scenarios, and verification manifests in a single verified archive.
Authoritative Sources
- ISO/IEC/IEEE 29119-4 Software Testing - Test TechniquesISO/IEC/IEEE • OFFICIAL REQUIREMENT
- Session-Based Test Management (James Bach & Jonathan Bach)Satisfice Inc. • OFFICIAL REQUIREMENT
- Cucumber Gherkin Reference SpecificationSmartBear / Cucumber • OFFICIAL REQUIREMENT