| name | open-testing-plan |
| description | Generate comprehensive test plans, schedules, resource allocation, environment setup, and test data strategies. Use this when you need to develop master test plans, level-specific test plans, allocate resources and environments, plan non-functional testing, define end-to-end testing chains, or establish test data management strategies. |
Open Testing Plan
The open-testing-plan skill generates test plans, schedules, resource allocation, environment setup, and test data strategies using a 7-agent PLANNED pipeline that transforms test strategies into executable test plans.
PLANNED Agent Pipeline
The PLANNED mnemonic orchestrates seven specialized agents:
- P_plan - Plan Agent
- L_levels - Levels Agent
- A_allocation - Allocation Agent
- N_nonfunctional - Non-Functional Agent
- N_network - Network/E2E Agent
- E_environment - Environment Agent
- D_data - Data Agent
Agent Specifications
P_plan: Plan Agent
Purpose: Generate master test plans and level-specific test plans following ISO 29119-3 and TMap templates.
Inputs:
- Test strategy from
open-testing-design skill
- Scope and test objects
- Timeline and release gates
- Stakeholder requirements
Outputs:
- Master Test Plan (MTP)
- Level Test Plans (LTP) for each level
- Test Plan Change Request procedure
- Test Plan Approval Sign-Off document
Knowledge Base Files:
standards/iso-29119.json - ISO/IEC 29119-3 Master Test Plan structurestandards/tmap.json - TMap test planning templatestemplate-analysis.json - 108 plan templates with field definitionsterminology.json - standardized terminology
Master Test Plan (MTP) Structure:
-
Scope and Objectives
- Testing objectives aligned with business goals
- Scope: what is/isn't tested
- Success criteria
-
Test Approach
- Test strategy reference (from design skill)
- Technique selections and intensities
- Risk-based allocation approach
-
Test Schedule and Milestones
- Planning, preparation, execution, closing phases
- Key milestones and gates
- Dependencies and critical path
-
Resources and Roles
- Test team structure
- Skills and competencies required
- Tool and environment requirements
-
Entry and Exit Criteria
- Phase-level entry criteria (e.g., "Requirements approved")
- Phase-level exit criteria (e.g., "Test cases reviewed and approved")
-
Risk Management
- Testing risks (schedule, resource, technical)
- Mitigation strategies
- Contingency plans
-
Deliverables and Reporting
- Test artifacts (cases, data, scripts)
- Status and metrics reporting cadence
- Escalation procedures
L_levels: Levels Agent
Purpose: Define test levels with entry/exit criteria, scope, and techniques for each level.
Inputs:
- Master Test Plan
- Quality characteristics and risk classes
- Organizational testing standards
- Component architecture
Outputs:
- Level Test Plans (LTP) for:
- Unit Testing
- Component Testing
- Integration Testing
- System Testing
- System Integration Testing (SIT)
- User Acceptance Testing (UAT)
- Level-to-Technique Mapping
- Level-Specific Entry/Exit Criteria Document
Knowledge Base Files:
standards/iso-29119.json - level definitions per ISO 29119standards/tmap.json - TMap level frameworkstechnique-patterns.json - technique applicability by leveltemplate-analysis.json - level test plan templates
Level Definitions and Scope:
| Level | Focus | Techniques | Entry Criteria | Exit Criteria |
|---|
| Unit | Individual units/modules | Code inspection, unit test frameworks, TDD | Code ready, test framework configured | 100% statement coverage, all tests pass |
| Component | Component functionality | Component testing, API testing, mocking | Component code complete, test env ready | Functional coverage 90%+, defects fixed |
| Integration | Component interactions | Integration testing, API contract testing | Components tested individually, integration env ready | All interfaces verified, integration smoke tests pass |
| System | Full system functionality | End-to-end testing, scenario testing, business process | Integration complete, system env ready | All requirements tested, performance benchmarks met |
| SIT | System + external integrations | Integration testing, data mapping | System tested, external systems available | External interfaces verified, data integrity confirmed |
| UAT | Business requirements validation | User scenario testing, exploratory, acceptance testing | System SIT complete, UAT env ready | Business acceptance sign-off, all priority requirements met |
Technique Selection by Level:
- Unit: TDD, code inspection, branch coverage analysis
- Component: Black-box testing (BVA, equivalence partitioning), API contract testing
- Integration: Integration scenarios, state transition testing, data flow testing
- System: End-to-end scenarios, user journey testing, performance/security testing
- SIT: System integration with external APIs, data migration testing
- UAT: Business scenario testing, usability testing, exploratory testing
A_allocation: Allocation Agent
Purpose: Allocate resources, roles, environments, tools, and budget across test activities.
Inputs:
- Test effort estimate from design skill
- Resource availability
- Tool portfolio (licensed, open-source)
- Budget constraints
- Team structure and competencies
Outputs:
- Resource Allocation Matrix
- Role Definitions and RACI
- Tool and Environment Allocation
- Budget Breakdown by Phase
- Skills Gap Analysis
- Staffing Timeline
Knowledge Base Files:
standards/iso-29119.json - resource frameworksstandards/tmap.json - role definitionsterminology.json - role standardization
Resource Allocation Matrix Format:
| Role | Responsibility | % Allocation | Timeline | Skills Required | Reporting To |
|---|
| QA Lead | Test planning, execution oversight | 80% | Full project | 10 yrs QA exp, risk analysis | Test Manager |
| Test Automation Engineer | Automation infrastructure, scripts | 100% | Full project | Python, Selenium, CI/CD | QA Lead |
| Manual Tester | Test execution, exploratory | 100% | Execution phase | Test design, domain knowledge | QA Lead |
Tool Allocation by Activity:
- Test Management: [tool selection]
- Test Automation: [framework selection]
- Performance Testing: [load testing tool]
- Security Testing: [SAST/DAST tools]
- Reporting: [dashboarding tool]
N_nonfunctional: Non-Functional Agent
Purpose: Plan non-functional testing (NFT) across performance, security, usability, accessibility, scalability.
Inputs:
- Non-functional requirements from strategy
- Business-critical quality attributes
- Performance benchmarks and SLAs
- Security and compliance requirements
Outputs:
- Non-Functional Test Matrix (NFR × Test Type)
- Performance Test Plan (load, stress, endurance)
- Security Test Plan (SAST, DAST, penetration, compliance scanning)
- Usability Test Plan
- Accessibility Test Plan
- Scalability Test Plan
Knowledge Base Files:
standards/iso-29119.json - NFT frameworksstandards/tmap.json - non-functional testing patternstechnique-patterns.json - NFT technique definitions
Non-Functional Test Matrix Format:
| Quality Attribute | NFR | Test Type | Technique | Success Criteria | Owner |
|---|
| Performance | Response time < 2 sec | Load testing | JMeter scenarios | P99 < 2 sec at 1000 users | Perf Engineer |
| Security | PCI DSS compliance | Penetration testing | OWASP Top 10 | Zero critical vulnerabilities | Security Lead |
| Usability | Task completion > 80% | Usability testing | User study (5 users) | 80%+ task completion | UX Researcher |
| Accessibility | WCAG 2.1 AA | Accessibility testing | Axe/lighthouse | Zero violations | QA Lead |
Performance Test Scenarios:
- Baseline: Establish current performance metrics
- Load Test: Normal production load + headroom
- Stress Test: Beyond expected load until failure point
- Endurance Test: Sustained load over extended period
- Spike Test: Sudden traffic spikes
Security Test Coverage:
- OWASP Top 10: Injection, broken auth, XSS, CSRF, etc.
- PCI DSS requirements (if payment processing)
- API security (authentication, authorization, data encryption)
- Dependency vulnerability scanning
- Code security scanning (SAST)
N_network: Network/E2E Agent
Purpose: Plan end-to-end and chain testing across system components and external integrations.
Inputs:
- System architecture and data flow
- External system integrations
- User journeys and business processes
- System dependencies
Outputs:
- End-to-End (E2E) Test Scenarios
- E2E Chain Cards (swimlane diagrams)
- Integration Test Matrix (system × system)
- Data Flow Test Mapping
- Dependency and Critical Path Analysis
Knowledge Base Files:
standards/iso-29119.json - integration testing frameworksstandards/tmap.json - chain testing patternstemplate-analysis.json - E2E scenario templates
E2E Chain Card Format:
Chain: Customer Registration and First Purchase
Actor: New Customer
Steps:
1. Web Portal: Submit registration form
→ Data validation: Email format, unique check
→ Output: User record created in CRM
2. CRM System: Send welcome email via Email Service
→ Integration: Email Service API call
→ Output: Email sent, delivery confirmed
3. Web Portal: Redirect to product catalog
→ Integration: Product API call
→ Output: Catalog loaded with personalized recommendations
4. Web Portal: Checkout process
→ Integration: Payment Gateway API
→ CRM: Update customer purchase history
→ Inventory: Decrement stock
→ Fulfillment: Create order
→ Output: Order confirmation email
5. Email Service: Shipment notification
→ Integration: Tracking system API
→ Output: Tracking link sent to customer
Critical Data Points:
- Customer ID consistency across systems
- Email delivery confirmation
- Payment transaction integrity
- Inventory accuracy
Integration Test Matrix:
| System 1 | System 2 | Interface Type | Test Type | Success Criteria |
|---|
| Web Portal | CRM | REST API | Contract testing | API response schema matches |
| CRM | Email Service | SMTP | Data integrity | Email delivered within 5 min |
| Web Portal | Payment Gateway | HTTPS | Security | TLS 1.2+, no man-in-middle |
| Fulfillment | Inventory | Database | Data consistency | Stock counts match bidirectionally |
E_environment: Environment Agent
Purpose: Generate environment specifications and infrastructure requirements for all test levels.
Inputs:
- Test levels and scope
- Performance requirements
- Integration dependencies
- Tool requirements
- Data volume and complexity
Outputs:
- Environment Specification Document
- Infrastructure Requirements (compute, storage, network)
- Environment Provisioning Checklist
- Data Seeding and Refresh Procedures
- Environment Maintenance Plan
Knowledge Base Files:
standards/iso-29119.json - environment frameworkstemplate-analysis.json - environment specification templates
Environment Specification Structure:
1. Environment Topology
Dev Environment:
- 2x Web servers (load balanced)
- 1x API server
- 1x PostgreSQL (single instance)
- 1x Redis cache
- Mock external services: Payment Gateway, Email Service
QA/Test Environment:
- 4x Web servers (load balanced)
- 2x API servers
- 1x PostgreSQL (with replication)
- 2x Redis cache (replicated)
- Real external service connections (sandbox)
Performance Test Environment:
- 8x Web servers
- 4x API servers
- 1x PostgreSQL optimized (dedicated storage)
- Load balancer with auto-scaling
- Monitoring: Prometheus, Grafana
UAT Environment:
- Production-like configuration
- All external services in production sandbox
- Data masking applied
2. Resource Requirements:
- CPU/Memory/Storage specifications
- Network bandwidth and latency constraints
- Database size and backup requirements
- Third-party service sandboxes/accounts
3. Configuration Management:
- Environment variables and secrets management
- Version control for environment definitions
- Infrastructure-as-Code (Terraform, CloudFormation) templates
- Environment consistency verification
4. Data Seeding:
- Base dataset size and refresh frequency
- Synthetic data generation rules
- Realistic data distribution
- Compliance-aware masking (PII, PCI)
D_data: Data Agent
Purpose: Plan test data strategy, data masking, synthetic data generation, and data lifecycle management.
Inputs:
- Data types and volume from scope
- Privacy and compliance requirements
- Performance testing data needs
- Test level data requirements
Outputs:
- Test Data Master Sheet
- Data Masking Policy
- Synthetic Data Generation Rules
- Data Refresh and Cleanup Procedures
- Data Traceability and Audit Log
Knowledge Base Files:
standards/iso-29119.json - test data frameworkstemplate-analysis.json - data management templatesterminology.json - data classification terms
Test Data Master Sheet Format:
| Data Type | Volume | Source | Generation Method | Masking Rules | Refresh Frequency | Owner |
|---|
| Customer Records | 100K | Production (masked) | Subset + synthetic | Hash PII, mask email | Weekly | Data Eng |
| Transactions | 1M | Production (anonymized) | Subset + replay | Remove cardholder name | Weekly | Finance |
| Product Catalog | 10K | Source system | Direct sync | No masking | Daily | Catalog Mgmt |
| Test-Only Records | N/A | Synthetic | Faker library (Python) | N/A | On-demand | QA Lead |
Data Masking Policy:
PII Classification:
- Level 1 (High Risk): Payment card numbers, SSN, bank accounts
- Masking: Hash (SHA-256), never store plaintext
- Level 2 (Medium Risk): Names, emails, phone numbers
- Masking: Partial mask (first 2 chars), character substitution
- Level 3 (Low Risk): Job title, company, location
- Masking: No masking required
Data Generation Rules:
Customer Names: faker.name()
Email Addresses: faker.email() with domain mapping
Phone Numbers: Valid format (555-XXX-XXXX for test)
Credit Cards: Valid Luhn checksum, non-functional (4532 test range)
Addresses: Realistic distributions by geography
Dates: Relative to current date, realistic ranges
Product IDs: Existing IDs from product system
Data Refresh Cycle:
- Development: Refresh on-demand (manual)
- QA/Test: Refresh weekly (automated)
- Performance: Refresh before performance test run
- UAT: Refresh before each UAT cycle
- Production: Never use production data in lower environments
Compliance & Audit:
- Data access logging (who accessed what when)
- Audit trail for data modifications
- Retention policy (delete after X days)
- GDPR/CCPA compliance (right to deletion)
Output Templates
1. Master Test Plan (MTP)
- Project identification
- Test objectives aligned to business goals
- Scope statement (in/out of scope)
- Test approach and strategy reference
- Schedule and milestones
- Resource plan with roles
- Risk and contingency plan
- Entry and exit criteria (organizational)
- Deliverables list
- Metrics and reporting
2. Level Test Plans (LTP)
One LTP per level (Unit, Component, Integration, System, SIT, UAT):
- Level scope and objectives
- Techniques and coverage targets
- Entry criteria (level-specific)
- Exit criteria (level-specific)
- Test case inventory
- Schedule and resource allocation
- Environment requirements
- Risk mitigation for level
3. Non-Functional Test Matrix
Spreadsheet with quality attributes, NFR mappings, test types, success criteria, and resource allocation.
4. E2E Chain Cards
Swimlane diagrams (text or visio) showing:
- Actors and systems involved
- Step-by-step data flow
- Integration points
- Critical data validation points
5. Environment Specification
Technical document with topology, resource specs, configuration, and data seeding procedures.
6. Test Data Master Sheet
Spreadsheet with data types, volumes, generation methods, masking rules, refresh schedules, and ownership.
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 by level and context
- template-analysis.json (108 templates): MTP, LTP, NFT, E2E, environment, and data templates
- standards/iso-29119.json: ISO/IEC 29119 testing standard structures and definitions
- standards/ieee-standards.json: IEEE standard references (830 for requirements, 1012 for testing)
- standards/tmap.json: TMap methodologies, best practices, and frameworks
- ontology.json: Testing domain classification and relationships
Invocation Examples
Example 1: Generate Complete Test Plan from Strategy
User Input:
Create a test plan for our payment module project:
- From the test strategy generated previously
- 3-week timeline
- 8 developers, 3 QA testers
- Need performance testing (< 2 sec response time)
- PCI DSS compliance required
- Production-like QA environment
Agent Pipeline:
- P_plan creates MTP with 3-week schedule, alignment to strategy objectives
- L_levels defines 6 level test plans (unit through UAT) with entry/exit criteria
- A_allocation distributes 8 developers and 3 QA across levels, allocates tools (Selenium, JMeter)
- N_nonfunctional plans performance testing (load scenarios), security testing (OWASP scanning)
- N_network defines E2E chains: registration, payment processing, refund scenarios
- E_environment specifies 3 environments (dev, QA, perf test) with load balancer setup
- D_data creates test data strategy with 100K masked customer records, synthetic transaction data
Output:
- Master Test Plan (20 pages)
- 6 Level Test Plans
- Performance Test Plan with JMeter scenarios
- Security Test Plan with OWASP Top 10 coverage
- E2E Chain Cards (8 critical paths)
- Environment Specification (infrastructure-as-code templates)
- Test Data Master Sheet (data generation rules, masking policy)
Example 2: Plan Non-Functional Testing for Performance-Critical System
User Input:
Our API must handle 10K requests/second during peak load.
E-commerce platform with payment processing.
SLA: 99.99% uptime, p99 response time < 500ms.
Generate the non-functional test plan.
Agent Pipeline:
- N_nonfunctional creates NFT matrix with performance, security, and scalability testing
- N_network identifies integration bottlenecks (payment gateway, inventory, analytics)
- E_environment specifies perf test environment with auto-scaling infrastructure
- A_allocation allocates performance engineer and infrastructure resources
- D_data plans synthetic transaction dataset (1M records) for realistic load simulation
Output:
- Performance Test Plan with load/stress/endurance/spike scenarios
- Load test data (1M+ synthetic transactions)
- Infrastructure scaling policy
- SLA monitoring and alerting setup
Integration with Other Skills
Inputs from open-testing-design:
- Test Strategy Table (techniques, intensities, risk classes)
- Quality Engineering Strategy Table (preventive/static/dynamic measures)
- Exit criteria and coverage targets
Integration Points:
- Test levels use techniques selected in design skill
- Risk classes determine level intensity and resource allocation
- Exit criteria from design become acceptance gates in plan
Output for Other Skills:
- Test plans feed into
opentestai skill for test case generation
- Environment specs inform CI/CD pipeline setup
- E2E chain cards inform test automation script structure
For Document Generation: Use docx skill to create formatted MTP and LTP documents
For Spreadsheet Output: Use xlsx skill to create resource matrices, NFT matrix, and test data master sheet
Algorithm Summary
Level Planning Algorithm
FOR EACH test_level (unit, component, integration, system, sit, uat):
1. Look up level definition in standards/iso-29119.json
2. Identify techniques applicable to level (from technique-patterns.json)
3. Determine risk-based intensity (from strategy):
- Class A risks: thorough coverage at this level
- Class B risks: standard coverage at this level
- Class C risks: light coverage or coverage only
4. Set entry criteria: prerequisites from previous level + env readiness
5. Set exit criteria: technique coverage + defect/quality metrics
6. Calculate effort for level using technique factors
7. Allocate resources proportional to effort
8. Create LTP with templates from template-analysis.json
Environment Specification Algorithm
FOR EACH test_level:
1. Identify external system integrations needed
2. Determine data volume requirements (from scope)
3. Select environment tier (minimal/standard/full):
- Unit/Component: lightweight, local or containerized
- Integration/System: full topology with mocks or sandboxes
- SIT: production-like, real external systems (sandbox)
- UAT: production-equivalent with masked data
4. Allocate infrastructure resources (compute, storage, network)
5. Define environment provisioning (IaC templates, Docker, Kubernetes)
6. Create data seeding procedures
7. Set refresh frequency based on test execution rate
8. Document maintenance and troubleshooting procedures
Test Data Generation Algorithm
FOR EACH data_type:
1. Classify by privacy/sensitivity level (PII/confidential/public)
2. Determine required volume and distribution
3. Select generation method:
- Production subset (masked)
- Synthetic generation (Faker, data factories)
- Combination (seed + synthetic variants)
4. Apply masking rules per classification level
5. Validate generated data (Luhn checksum, format rules)
6. Create refresh procedures (weekly, per-execution, on-demand)
7. Document audit trail and compliance adherence
8. Test data traceability (which dataset used in which test run)
Quality Assurance
The PLANNED pipeline ensures:
- Test plans align with test strategies from design skill
- All test levels have clear entry/exit criteria
- Resources are appropriately allocated to risk-based priorities
- Environments support all test level requirements
- Test data is realistic, compliant, and managed
- Non-functional testing covers SLA/performance/security requirements
- E2E testing validates complete business processes
Plan Quality Validation:
- All levels reference applicable techniques from strategy
- Entry criteria are measurable and achievable
- Exit criteria are specific and objectively verifiable
- Resource allocation totals match availability
- Environment specifications include all external system integrations
- Data masking policy covers all PII classifications
- Non-functional test matrix covers business-critical quality attributes
