open-testing-design

name	open-testing-design
description	Generate comprehensive test strategies, quality engineering approaches, risk analysis, and optimal technique selection. Use this when you need to develop test strategies, perform quality risk analysis, select test design techniques, assess testability, estimate test effort, define governance structures, or establish test exit criteria and coverage targets.

Open Testing Design Strategy

The open-testing-design skill generates test strategies, quality engineering strategies, risk analysis, and technique selection using an 8-agent STRATEGY pipeline that transforms requirements and user stories into actionable quality engineering plans.

STRATEGY Agent Pipeline

The STRATEGY mnemonic orchestrates eight specialized agents that work sequentially and in parallel:

1. S_scope - Scope Agent
2. T_technique - Technique Selector Agent
3. R_risk - Risk Agent
4. A_approach - Approach Agent
5. T_testability - Testability Agent
6. E_estimation - Estimation Agent
7. G_governance - Governance Agent
8. Y_yield - Yield Agent

Agent Specifications

S_scope: Scope Agent

Purpose: Define test scope from requirements, user stories, and business context.

Inputs:

• Requirements document or user stories
• Product/system description
• Stakeholder priorities

Outputs:

• Scope Statement (in/out of scope items)
• Test Objects List (components, features, integrations)
• Quality Characteristics Matrix
• Scope Boundary Document

Knowledge Base Files:

• terminology.json - scope-related term definitions
• ontology.json - test object classification

Processing:

1. Parse requirements to identify test objects (UX, API, database, integrations)
2. Map quality characteristics relevant to each test object
3. Classify items as in/out of scope
4. Validate against stakeholder goals

---

T_technique: Technique Selector Agent

Purpose: Select optimal test design techniques based on quality characteristics and coverage requirements.

Inputs:

• Quality characteristics from Scope Agent
• Coverage group requirements
• Test intensity indicators (light/standard/thorough)

Outputs:

• Technique Recommendation Matrix
• Coverage Groups → Techniques Mapping
• Technique-to-Intensity Allocation
• Technique Selection Report

Knowledge Base Files:

• quality-to-technique.json - 8 ISO 25010 characteristics mapping to 78 test techniques
• technique-to-intensity.json - 20 techniques with light/standard/thorough intensity levels
• technique-patterns.json - 106 technique patterns with applicability rules

Mapping Logic:

Quality Characteristics (ISO 25010):

1. Functional Suitability → Black-box techniques (boundary analysis, decision tables, state transition)
2. Performance Efficiency → Load testing, stress testing, scalability testing
3. Compatibility → Integration testing, interoperability testing
4. Usability → Exploratory testing, user scenario testing, accessibility testing
5. Reliability → Robustness testing, failure mode testing, error handling testing
6. Security → Penetration testing, threat modeling, security scanning
7. Maintainability → Code review, static analysis, test coverage analysis
8. Portability → Platform-specific testing, environment testing, deployment testing

Technique Selection Algorithm:

1. Identify quality characteristics for test object
2. Look up characteristic → technique mapping in quality-to-technique.json
3. Validate technique applicability using technique-patterns.json
4. Map technique to intensity level using technique-to-intensity.json
5. Generate coverage target (% of techniques adopted)

---

R_risk: Risk Agent

Purpose: Perform Quality Risk Analysis (QRA) and assign risk-based testing intensity.

Inputs:

• Test objects from Scope Agent
• Quality characteristics priorities
• Business impact assessments

Outputs:

• Quality Risk Analysis Report
• Risk Class Assignments (A/B/C)
• Risk-to-Intensity Matrix
• Risk Mitigation Strategy

Knowledge Base Files:

• standards/iso-29119.json - risk assessment frameworks
• standards/tmap.json - TMap risk assessment patterns
• terminology.json - risk-related definitions

Risk Classification Algorithm:

Risk Matrix: Impact (High/Medium/Low) × Probability (High/Medium/Low)

Risk Classes:

• Class A (High Risk): Test intensively (thorough techniques, extensive coverage)
  • Probability: High or Impact: High
  • Testing Intensity: Thorough
• Class B (Medium Risk): Test at standard level
  • Probability: Medium and Impact: Medium or Low
  • Testing Intensity: Standard
• Class C (Low Risk): Test lightly or defer
  • Probability: Low and Impact: Low
  • Testing Intensity: Light or Coverage Only

Intensity Mapping:

• Thorough: Full technique coverage, 90%+ decision/branch coverage, extensive scenario testing
• Standard: Core technique coverage, 70-80% decision coverage, primary scenario testing
• Light: Key technique coverage, 50% decision coverage, critical path testing

---

A_approach: Approach Agent

Purpose: Generate test strategy tables and quality engineering strategy tables with preventive, static, dynamic, and corrective measures.

Inputs:

• Quality characteristics and risk classes from previous agents
• Organizational constraints and capabilities
• Budget and timeline parameters

Outputs:

• Test Strategy Table (TST)
• Quality Engineering Strategy Table (QEST)
• Risk Mitigation Actions
• Prevention/Detection/Correction Plan

Knowledge Base Files:

• template-analysis.json - 108 strategy templates
• standards/tmap.json - TMap strategy patterns

Test Strategy Table (TST) Format:

Quality Characteristic	Risk Class	Techniques	Coverage Target	Entry Criteria	Exit Criteria
Functional Suitability	A	Decision tables, BVA, State transition	90%	Requirements approved	All tests pass, coverage met
Performance	B	Load testing, stress testing	70%	Environment ready	Response time < threshold

Quality Engineering Strategy Table (QEST) Format:

Quality Characteristic	Prevention	Static Analysis	Dynamic Testing	Correction
Functional Suitability	Requirements review	Code inspection	Test case execution	Defect fixing
Security	Threat modeling	SAST scanning	Penetration testing	Vulnerability patching

---

T_testability: Testability Agent

Purpose: Assess testability of requirements and design; generate testability review reports.

Inputs:

• Requirements and design documents
• Architecture specifications
• Test object definitions

Outputs:

• Testability Assessment Report
• Testability Metrics
• Improvement Recommendations
• Requirement Traceability Matrix (RTM)

Knowledge Base Files:

• terminology.json - testability criteria definitions
• ontology.json - testability assessment patterns

Testability Review Dimensions:

1. Requirement Clarity: Are requirements unambiguous and testable?
2. Observability: Can test results be clearly observed?
3. Controllability: Can inputs/state be set to specific values?
4. Decomposability: Can system be tested independently?
5. Architecture Simplicity: Is design conducive to testing?

---

E_estimation: Estimation Agent

Purpose: Estimate test effort using Test Point Analysis, WSJF, and function points.

Inputs:

• Scope and test objects
• Technique selections and intensities
• Resource availability
• Project constraints

Outputs:

• Test Effort Estimate (in test points or hours)
• Resource Allocation Plan
• Schedule Estimate
• Confidence Level Assessment

Knowledge Base Files:

• technique-patterns.json - effort factors per technique
• standards/iso-29119.json - estimation frameworks

Estimation Methods:

Test Point Analysis:

• Functional Test Points (FTP) = Function Count × Function Complexity × Quality Weight
• Test Points = FTP × Technique Factor × Intensity Factor
• Effort (hours) = Test Points × Hours-per-TP conversion factor

WSJF Priority Calculation:

• WSJF = (Functional Value + Risk Reduction + Opportunity Value) / Job Size
• Allocate test effort proportional to WSJF scores

---

G_governance: Governance Agent

Purpose: Generate governance structures, accountability matrices, and quality policies.

Inputs:

• Organizational structure
• Roles and responsibilities
• Quality objectives
• Stakeholder map

Outputs:

• ARCI Matrix (Accountable, Responsible, Consulted, Informed)
• QAM (Quality Assurance Manager) Mapping
• QPM (Quality Process Manager) Mapping
• Quality & Test Policies
• Decision Rights Matrix

Knowledge Base Files:

• standards/iso-29119.json - governance frameworks
• terminology.json - role definitions

ARCI Matrix Format:

Activity	Test Manager	QA Lead	Developer	Product Owner	Stakeholder
Strategy approval	A	R	C	C	I
Test execution	I	R	R	C	I
Defect triage	C	R	R	A	I
Exit criteria decision	R	C	C	A	I

---

Y_yield: Yield Agent

Purpose: Define exit criteria, coverage targets, and quality gates for test completion.

Inputs:

• Risk class assignments
• Quality characteristics priorities
• Quality objectives
• Stakeholder acceptance criteria

Outputs:

• Exit Criteria Document
• Quality Gates Definition
• Coverage Metrics Dashboard
• Acceptance Criteria Checklist

Knowledge Base Files:

• standards/iso-29119.json - exit criteria frameworks
• standards/tmap.json - TMap quality gates

Exit Criteria Types:

1. Coverage Criteria:

   • Code coverage (statement/branch/path)
   • Requirement coverage (100% traceability)
   • Test technique coverage (% of selected techniques executed)

2. Quality Metrics:

   • Defect density ≤ X per KLOC
   • Critical defects = 0
   • High defects ≤ Y
   • P1/P2 mean time to fix ≤ Z hours

3. Acceptance Criteria:

   • All priority-1 requirements tested
   • Performance benchmarks met
   • Security scan clean
   • Usability testing feedback incorporated

4. Risk Criteria:

   • Class A risks tested at thorough level
   • Risk mitigation acceptance by stakeholder
   • Known risks documented and accepted

---

Output Templates

1. Test Strategy Table (TST)

JSON/CSV/Excel format with columns:

• Quality Characteristic
• Risk Class
• Selected Techniques (comma-separated)
• Coverage Target (%)
• Entry Criteria (requirements, environment)
• Exit Criteria (metrics, quality gates)
• Owner
• Timeline

2. Quality Engineering Strategy Table (QEST)

Preventive/Static/Dynamic/Corrective measures organized by quality characteristic.

3. Test Intensity Table

Mapping of techniques to light/standard/thorough intensity levels with effort estimates.

4. ARCI Matrix

Roles vs. Activities with assignment levels (A/R/C/I).

5. QAM/QPM Document

Quality Assurance Manager and Quality Process Manager role definitions and responsibilities.

6. Testability Review Report

Assessment findings with numeric scores and improvement recommendations.

---

Knowledge Base Files Reference

All KB files located at /sessions/trusting-pensive-ptolemy/mnt/Open-Testing/knowledge-base/:

• terminology.json (1105 terms): Standardized testing terminology
• technique-patterns.json (106 patterns): Technique applicability rules, effort factors, quality mapping
• template-analysis.json (108 templates): Strategy, plan, and report templates
• quality-to-technique.json: 8 ISO 25010 characteristics → 30 sub-characteristics → 78 techniques
• technique-to-intensity.json: 20 techniques with light/standard/thorough intensity definitions
• standards/iso-29119.json: ISO/IEC 29119 testing standard requirements
• standards/tmap.json: TMap best practices and frameworks
• ontology.json: Test object and testing domain classification

---

Invocation Examples

Example 1: Test Strategy from User Story

User Input:

Create a test strategy for our new payment module:
- High-value transaction feature
- Must support credit cards, bank transfers, wallet
- Performance critical (< 2 sec response time)
- PCI DSS compliance required
- 3 weeks to delivery

Agent Pipeline:

1. S_scope identifies test objects: payment gateway, transaction processor, security layer
2. T_technique selects: functional testing (BVA, decision tables), performance testing (load), security testing (penetration)
3. R_risk classifies payment functionality as Class A (high impact, high probability)
4. A_approach generates TST with thorough techniques for Class A items
5. T_testability assesses requirement clarity on compliance requirements
6. E_estimation calculates test points and effort
7. G_governance defines roles (QA lead accountable for execution)
8. Y_yield sets exit criteria (100% functional coverage, 0 critical defects, PCI compliance confirmation)

Output: Multi-page strategy document with TST, QEST, effort estimate, and governance

Example 2: Risk-Based Testing for Legacy System

User Input:

Modernizing legacy CRM system. Identify critical areas for intensive testing:
- 500K+ customer records
- 20+ year old codebase
- Business-critical functionality
- Moving to cloud with 2-month timeline

Agent Pipeline:

1. R_risk identifies high-risk areas: data migration, reporting accuracy, integration points
2. T_technique selects regression testing (heavy), data integrity testing, integration testing
3. T_testability assesses decomposability challenges in legacy code
4. A_approach creates risk mitigation strategy with preventive measures (data validation rules)
5. E_estimation accounts for legacy system testing complexity
6. Y_yield defines acceptance criteria: zero data loss, 99.9% uptime post-migration

---

Integration with Other Skills

For Test Plan Generation: Pass outputs to open-testing-plan skill

• TST feeds into Level Test Plans
• QEST feeds into approach definition
• Risk classes and intensities inform NFT planning

For Report Generation: Use docx skill to create formatted strategy documents For Spreadsheet Output: Use xlsx skill to create strategy tables and matrices

---

Algorithm Summary

Quality-to-Technique Selection

FOR EACH quality_characteristic:
  1. Look up sub-characteristics in quality-to-technique.json
  2. Find applicable techniques (filter by type: functional/non-functional)
  3. Get intensity levels from technique-to-intensity.json
  4. Calculate coverage target based on risk class:
     - Class A: 90% (thorough)
     - Class B: 70% (standard)
     - Class C: 50% (light)
  5. Validate technique applicability using technique-patterns.json
  6. Output technique recommendation with effort factor

Risk Classification & Intensity Mapping

Risk Score = (Probability + Impact) / 2
IF Risk Score >= 7.5 THEN Class A, Intensity = Thorough
ELSE IF Risk Score >= 4.5 THEN Class B, Intensity = Standard
ELSE Class C, Intensity = Light

FOR EACH risk_class:
  Apply corresponding technique intensity
  Define coverage targets
  Set effort multiplier

---

Quality Assurance

The STRATEGY pipeline ensures:

• Techniques are evidence-based (sourced from ISO 25010, ISO 29119, TMap)
• Risk analysis is systematic and documented
• Governance is explicit and RACI-clear
• Effort estimation is grounded in function/test points
• Exit criteria are measurable and achievable
• Testability issues are identified early

Output Quality Validation:

• All selected techniques are in technique-patterns.json
• All quality characteristics map to ISO 25010
• ARCI matrix is complete (no blanks)
• Exit criteria are specific, measurable, and achievable
• Effort estimates include confidence intervals