Test Strategy — Product or Programme Name

Version: 1.0 Author: Name / QA Lead Date: YYYY-MM-DD Status: Draft / Approved Audience: Engineering, Product, Leadership

---

1. Purpose and Scope

Describe why this document exists and what product, platform, or programme it covers. A strategy is org-level — it should remain stable across individual releases.

---

2. Testing Philosophy

State the team's guiding principles for quality. Examples: "quality is everyone's responsibility", "shift left — test as early as possible", "automation is the floor, not the ceiling".

---

3. Testing Scope

3.1 In Scope

List product areas, system boundaries, and test types covered by this strategy.

3.2 Out of Scope

List what is explicitly excluded and why — e.g., third-party SLAs, areas owned by another team.

---

4. Test Types and Ownership

Test Type	Purpose	Owner	Tooling
Unit	Purpose	Dev	Tool
Integration	Purpose	Dev / QA	Tool
API	Purpose	QA / SDET	Tool
UI / E2E	Purpose	SDET	Tool
Exploratory	Purpose	QA	SBTM charters
Performance	Purpose	SDET / Platform	Tool
Security	Purpose	Security / QA	Tool
Accessibility	Purpose	QA / Design	Tool

---

5. Test Environments

Environment	Purpose	Managed By	Refresh Cadence
Dev	Purpose	Team	Cadence
QA	Purpose	QA Ops	Cadence
Staging	Purpose	Platform	Cadence
Performance	Purpose	SDET	Cadence

---

6. Test Data Strategy

Describe how test data is created, managed, and cleaned up. Address sensitive data handling (PII masking, synthetic data, sandbox environments).

---

7. Automation Strategy

Describe the automation philosophy and pyramid target.

Target pyramid:

• Unit: X% of coverage
• Integration / API: X% of coverage
• E2E: critical paths only / X flows

Frameworks: List chosen frameworks and rationale.

CI integration: Describe when tests run in the pipeline.

Flaky test policy: How flaky tests are identified and handled.

---

8. Defect Management

Describe the defect lifecycle, triage cadence, and severity / priority definitions.

Severity	Definition	SLA to fix
Critical	Definition	SLA
High	Definition	SLA
Medium	Definition	SLA
Low	Definition	SLA

---

9. Quality Gates

Define the criteria that must pass at each pipeline stage or release milestone.

Gate	Criteria	Blocks
PR merge	Criteria	Yes / No
QA sign-off	Criteria	Yes
Release to production	Criteria	Yes

---

10. Metrics and Reporting

List the metrics tracked and the cadence and audience for each report.

Metric	Target	Reported to	Cadence
Test pass rate	≥ X%	Audience	Sprint
Defect density	≤ X per release	Audience	Release
Automation coverage	≥ X%	Audience	Monthly
Flaky test rate	≤ X%	Audience	Weekly

---

11. Roles and Responsibilities

Role	Responsibilities
QA Lead	Strategy ownership, stakeholder reporting, triage chair
QA Engineer	Test design, manual execution, defect logging
SDET	Framework development, automation maintenance, performance testing
Developer	Unit tests, test-environment support, fixing defects
Product Owner	UAT, acceptance criteria, risk prioritisation

---

12. Document History

Version	Date	Author	Change
1.0	Date	Name	Initial release

Test Strategy — Veridia Payments Platform

Version: 2.1 Author: Priya Mehta, Head of QA Date: 2024-01-15 Status: Approved Audience: Engineering, Product, Compliance, Leadership

---

1. Purpose and Scope

This document defines the testing strategy for the Veridia Payments Platform — a cloud-native fintech SaaS product serving B2B clients in the UK and EU. It covers all product areas across four quarters of the 2024 programme and supersedes v1.0 (dated 2023-02-10).

The strategy applies to the core platform (payments, ledger, reconciliation, reporting) and the merchant-facing dashboard. It does not cover white-label integrations delivered by third-party partners.

---

2. Testing Philosophy

• Quality is a shared responsibility across engineering, product, and design — QA is the facilitator, not the gatekeeper.
• Shift left: QA joins requirement refinement so defects are caught before code is written.
• Automation is the floor for regression; exploratory testing is the ceiling for discovery.
• Risk-based prioritisation: testing effort concentrates on payment processing, data integrity, and regulatory compliance.

---

3. Testing Scope

3.1 In Scope

• Payments engine: initiation, processing, settlement, reconciliation
• Merchant dashboard: onboarding, transaction history, reporting, webhook configuration
• Admin portal: user management, compliance flags, audit log
• Public API: REST endpoints documented in api.veridia.io/v2
• Mobile companion app (iOS and Android)

3.2 Out of Scope

• Infrastructure / cloud provisioning (owned by Platform SRE team)
• Third-party acquirer SLAs (tested by acquirer; Veridia performs integration testing only)
• Penetration testing (contracted to external security firm, quarterly)

---

4. Test Types and Ownership

Test Type	Purpose	Owner	Tooling
Unit	Component-level logic	Developer	Jest, JUnit
Integration	Service boundary contracts	Dev / SDET	Pact, REST Assured
API	Full API contract and regression	QA / SDET	Postman, k6
UI / E2E	Critical user journeys	SDET	Playwright
Exploratory	Discovery, edge cases, UX issues	QA	SBTM charters
Performance	Load, soak, spike on payment API	SDET	k6
Security	OWASP Top 10, auth boundary	Security / QA	OWASP ZAP, Burp Suite
Accessibility	WCAG 2.1 AA compliance	QA / Design	axe-core, manual

---

5. Test Environments

Environment	Purpose	Managed By	Refresh Cadence
Dev	Developer smoke tests	Dev teams	Per commit
QA	Feature testing and regression	QA Ops	Daily (overnight)
Staging	Pre-production, UAT, performance	Platform SRE	Per release branch
Performance	Load and soak tests	SDET	On demand

Staging mirrors production configuration. No real payment data or PII is used in any environment below staging.

---

6. Test Data Strategy

All test environments below staging use synthetic data generated by the veridia-test-harness CLI. PII is masked using the internal anonymisation service. Sensitive fields (account numbers, sort codes) are replaced with Luhn-valid test values.

Test merchant accounts and API keys are provisioned automatically as part of the environment setup job. Data is torn down after each test run in QA and restored from a golden snapshot.

---

7. Automation Strategy

Target pyramid:

• Unit: 70% of all logic paths, maintained by developers
• Integration / API: 20% coverage, SDET-owned, run on every PR
• E2E: 30 critical journeys in Playwright, run nightly and on release branches

Frameworks: Playwright (E2E), k6 (performance), Pact (contract), REST Assured (API).

CI integration: Unit and integration tests run on every PR (must pass to merge). E2E suite runs nightly and on release candidates. Performance suite runs before every staging deployment.

Flaky test policy: Any test failing more than twice in 5 runs is tagged @flaky and quarantined within 24 hours. Root cause must be identified within 48 hours or the test is removed until fixed.

---

8. Defect Management

Defects are logged in Jira under project VER-QA. Weekly triage every Tuesday at 10:00 UTC.

Severity	Definition	SLA to fix
Critical	Data loss, payment failure, security breach	Same business day
High	Feature broken with no workaround	Within 3 business days
Medium	Feature degraded, workaround exists	Within the sprint
Low	Cosmetic or minor UX issue	Backlog

---

9. Quality Gates

Gate	Criteria	Blocks
PR merge	Unit tests pass, no new Critical or High bugs	Yes
QA environment sign-off	≥ 95% test cases pass, 0 Critical defects	Yes
Release to staging	Full regression passes, performance SLAs met	Yes
Release to production	QA sign-off + PO UAT sign-off	Yes

---

10. Metrics and Reporting

Metric	Target	Reported to	Cadence
Test pass rate	≥ 95%	QA Dashboard	Per sprint
Defect escape rate	≤ 2 per quarter	Heads of Eng / Product	Quarterly
Automation coverage (API)	≥ 80% of endpoints	Engineering All-Hands	Monthly
Flaky test rate	≤ 3% of suite	QA Lead	Weekly
Mean time to detect	≤ 2 hours (CI)	QA Lead	Weekly

---

11. Roles and Responsibilities

Role	Responsibilities
Head of QA	Strategy ownership, stakeholder reporting, risk escalation
QA Lead	Sprint planning, triage chair, daily defect management
QA Engineer	Test design, manual execution, exploratory sessions
SDET	Framework development, automation maintenance, performance
Developer	Unit tests, environment support, defect fixes
Product Owner	UAT sign-off, acceptance criteria, risk prioritisation

---

12. Document History

Version	Date	Author	Change
1.0	2023-02-10	Priya Mehta	Initial release
2.0	2023-09-01	Priya Mehta	Added performance and accessibility sections
2.1	2024-01-15	Priya Mehta	Updated tooling, flaky test policy, metrics targets