| name | test-planning |
| description | Plan test cycles with resource allocation, entry/exit criteria, environment requirements, defect management, and regression test selection for the Talosix EDC platform. |
| allowed-tools | Read, Grep, Glob |
Test Planning
Purpose
Create actionable test plans for specific test cycles within the Talosix EDC platform release process. While the test strategy defines the overall approach, the test plan specifies the concrete activities, assignments, schedules, and criteria for a particular test cycle.
Context: Test Cycles in Clinical Trial EDC
Talosix typically runs these test cycles per release:
- Smoke Test Cycle: Quick validation that core functions work after deployment (30 min - 1 hour).
- Regression Test Cycle: Verify existing functionality is not broken by new changes (1 - 3 days).
- Feature Test Cycle: Thorough testing of new or modified features (varies by scope).
- Integration Test Cycle: Validate integrations with external systems (RTSM, ePRO, safety DB).
- UAT Cycle: Business user validation of workflows (3 - 5 days typically).
- Pre-Production Validation: Final verification in staging environment (1 - 2 days).
Each cycle has its own plan with specific scope, resources, and criteria.
Workflow
- Identify the test cycle type and its position in the release timeline.
- Define scope by selecting test cases from Zephyr Scale based on the release content.
- Allocate resources with named assignments where possible.
- Specify environment and data requirements.
- Set entry/exit criteria with measurable thresholds.
- Define defect management workflow for the cycle.
- Select regression tests using the risk-based approach.
- Output the plan in the format below.
Test Plan Document Structure
1. Test Cycle Identification
Cycle Name: [e.g., "Release 4.2 System Test Cycle 1"]
Cycle Type: [Smoke | Regression | Feature | Integration | UAT | Pre-Prod]
Release: [Release version]
Planned Start: [Date]
Planned End: [Date]
Zephyr Test Cycle: [Link or key to Zephyr Scale test cycle]
Plan Author: [Name]
Plan Version: [Version with date]
2. Scope
Test Cases Included
List test case selections from Zephyr Scale:
| Folder / Suite | Test Case Count | Priority Breakdown | Selection Rationale |
|---|
| /CRF Data Entry/Lab Values | 24 | 8 Critical, 10 High, 6 Medium | Modified in this release |
| /Query Management | 18 | 5 Critical, 8 High, 5 Medium | Regression -- dependent module |
| /E-Signatures | 12 | 12 Critical | Regulatory -- always tested |
| /Audit Trail | 8 | 8 Critical | Regulatory -- always tested |
Total Test Cases: [Sum]
Estimated Execution Time: [Hours/days]
Exclusions
- Test cases excluded from this cycle with justification.
- Modules not affected by the release changes.
3. Resource Allocation
| Tester | Role | Assigned Suites | Availability | Estimated Effort |
|---|
| [Name/TBD] | QA Engineer | CRF Data Entry, Edit Checks | 100% | 3 days |
| [Name/TBD] | QA Engineer | Query Management, SDV | 100% | 2 days |
| [Name/TBD] | QA Lead | E-Signatures, Audit Trail, Oversight | 80% | 2 days |
Notes:
- Include backup assignments for critical suites.
- Account for defect retesting time (typically 20-30% of execution time).
- Include time for test environment setup and data preparation.
4. Entry Criteria
Define what must be true before the test cycle begins:
| Criterion | Verification Method | Owner |
|---|
| Build deployed to test environment | Deployment confirmation from DevOps | Release Manager |
| Smoke tests passing | Automated smoke suite green | QA Lead |
| Test data loaded and verified | Data verification checklist | QA Engineer |
| Test environment stable (no active deployments) | Environment calendar confirmed | DevOps |
| All test cases reviewed and up to date in Zephyr | Zephyr Scale audit | QA Lead |
| Previous cycle blocking defects resolved | Jira filter verification | QA Lead |
| Required integrations available | Integration health check | DevOps |
Entry Decision: All criteria must be met. QA Lead makes the go/no-go call.
5. Exit Criteria
Define what must be true for the test cycle to be considered complete:
| Criterion | Target | Measurement |
|---|
| Test execution rate | >= 95% | (Executed / Planned) test cases |
| Critical test case pass rate | 100% | All Critical priority tests pass |
| High test case pass rate | >= 95% | High priority tests passing |
| Overall pass rate | >= 90% | All executed tests passing |
| Open Critical defects | 0 | No unresolved Critical defects |
| Open High defects | <= 2 | With documented workarounds |
| Regulatory test cases | 100% pass | All audit trail, e-sig, access control tests pass |
| Regression test cases | >= 95% pass | No unexpected regression failures |
Exit Decision: QA Lead reviews metrics and recommends cycle closure. Release Manager approves.
Conditional Exit: If exit criteria are not met, document deviations with risk assessment and obtain sign-off from the Release Manager and Product Owner.
6. Test Environment Requirements
Environment: [QA / UAT / Staging]
URL: [Environment URL]
Application Build: [Build number or commit SHA]
Database: [Database version and instance]
Test Data Set: [Data set identifier]
Browser Requirements:
- Chrome (latest stable)
- Firefox (latest stable)
- Edge (latest stable)
- Safari (latest stable, macOS only)
Required Integrations:
- [Integration Name]: [Status: Available / Stubbed / Mock]
- [Integration Name]: [Status]
Environment Restrictions:
- [e.g., "No deployments during test execution window"]
- [e.g., "Shared environment -- coordinate with team X"]
Test Data Requirements
| Data Category | Description | Setup Method |
|---|
| Studies | At least 2 active studies with different configurations | Seeded via setup script |
| Sites | 5+ sites per study across multiple countries | Seeded via setup script |
| Subjects | 50+ subjects per study at various stages | Seeded via setup script |
| Users | Users for each role type with appropriate permissions | Provisioned in environment |
| CRF Data | Completed CRFs with mix of clean and queried data | Generated via data loader |
| Queries | Mix of open, answered, and closed queries | Generated from edit checks |
7. Defect Management Process
Defect Workflow for This Cycle
New -> Triaged -> In Development -> Ready for Retest -> Retested -> Closed
-> Reopen (if retest fails)
-> Deferred (with justification and risk note)
Severity Classification
| Severity | Definition (EDC Context) | Examples |
|---|
| Critical | Data loss, security breach, regulatory non-compliance, system unusable | Audit trail not recording, e-sig bypass, data corruption |
| High | Major workflow blocked, no workaround or degraded workaround | Cannot save CRF, query workflow stuck, export produces wrong data |
| Medium | Feature impaired but workaround exists | Sorting not working on table, filter resets unexpectedly |
| Low | Cosmetic, minor usability, documentation | Misaligned label, typo in message, tooltip missing |
Defect Triage Process
- Frequency: Daily during active test execution.
- Attendees: QA Lead, Dev Lead, Product Owner.
- Decisions: Severity confirmation, assignment, fix-in-release vs. defer.
- Defect fields required: Steps to reproduce, expected result, actual result, severity, screenshots/video, environment, test case link.
Retest Protocol
- Retesting is performed by the original reporter or assigned tester.
- Retest must use the same environment and data conditions as the original test.
- If the fix introduces side effects, expand retest to include related test cases.
- Document retest evidence in Zephyr Scale execution results.
8. Regression Test Selection
Selection Strategy
Use a risk-based approach to select regression tests:
Always Include (Core Regression):
- Authentication and session management.
- Audit trail generation and viewing.
- E-signature workflows.
- Role-based access control verification.
- CRF data entry save and retrieve.
- Query create, respond, close lifecycle.
- Subject enrollment basic flow.
- Data export in primary format.
Impact-Based Selection:
- Identify modules modified in the release.
- Map module dependencies (use code analysis or architecture diagrams).
- Select regression tests for directly modified modules (full coverage).
- Select regression tests for dependent modules (critical and high priority only).
- Select smoke-level tests for indirectly affected modules.
Historical Defect Analysis:
- Include tests for areas with high defect density in recent releases.
- Include tests for previously deferred defects that may resurface.
- Prioritize tests that caught regressions in the past 3 releases.
Regression Suite Maintenance
- After each release, review failed regression tests for inclusion in the automated suite.
- Remove redundant or outdated tests quarterly.
- Add new regression tests for every Critical/High defect found in production.
9. Schedule
| Day | Activity | Owner |
|---|
| Day 0 | Entry criteria verification, environment setup | QA Lead, DevOps |
| Day 1 | Smoke test execution, critical path testing | QA Lead |
| Day 1-2 | Feature test execution (new/modified features) | QA Engineers |
| Day 2-3 | Regression test execution | QA Engineers |
| Day 3 | Regulatory test execution (audit trail, e-sig) | QA Lead |
| Day 3 | Defect retest cycle | QA Engineers |
| Day 4 | Exit criteria review, metrics compilation | QA Lead |
| Day 4 | Cycle closure and reporting | QA Lead |
Adjust timeline based on scope. Include buffer days for defect fix-and-retest loops.
10. Reporting
Generate the following reports from Zephyr Scale at cycle completion:
- Test Execution Summary: Pass/Fail/Blocked/Not Executed counts by suite.
- Defect Summary: Open/Closed/Deferred by severity.
- Requirement Coverage: Percentage of Jira requirements covered by executed tests.
- Risk Items: Any exit criteria not met with documented risk acceptance.
- Cycle Metrics: Execution rate, pass rate, defect find rate, retest rate.
11. Communication
| Event | Channel | Audience | Frequency |
|---|
| Cycle kickoff | Meeting | QA team, Dev leads, PM | Once at start |
| Daily status | Slack / Email | QA team, Dev leads, PM | Daily during execution |
| Blocker escalation | Slack + Meeting | QA Lead, Dev Lead, RM | As needed |
| Cycle completion | Email + Report | All stakeholders | Once at end |
Guidelines
- Always check the codebase for recent changes (git log, modified files) to inform regression selection.
- Reference specific Zephyr Scale test cycle keys and folder paths when available.
- Adjust scope and timeline based on the actual release content -- do not copy a previous plan verbatim.
- For hotfix releases, use a condensed plan focusing on the fix verification plus targeted regression.
- Include contingency plans for common blockers (environment issues, resource unavailability).
