Modern Quality and Test Strategy

Modern testing is not a list of tools and it is not a project to automate everything. It is an operating system for quality: define what must be true, identify the most damaging failures, test each risk at the lowest effective layer, collect evidence, and make an explicit release decision.

Who this wiki is for

QA/QE engineers, test leads, developers, engineering managers, product owners, data engineers, AI engineers, security specialists, SRE/DevOps teams, and interview candidates.

Example system

The source uses PeopleFlow AI, a fictional multi-tenant HR and payroll SaaS with a React UI, Java/Spring Boot services, REST APIs, PostgreSQL, Redis, Kafka, ETL/data-mart workloads, legacy migration, and a RAG policy assistant on AWS/Kubernetes.

Its highest risks include incorrect payroll, sensitive-data exposure, cross-tenant leakage, silent migration errors, partial failure across services, peak month-end load, and plausible but incorrect AI answers.

Quality operating model

flowchart LR
    A[Business journeys] --> B[Risk model]
    B --> C[Test design]
    C --> D[CI and deployment gates]
    D --> E[Release evidence]
    E --> F{Residual risk acceptable}
    F -->|Yes| G[Progressive release]
    F -->|No| H[Fix disable or defer]
    G --> I[Production assurance]
    I --> J[Incidents feedback and drift]
    J --> B

Core principles

1. Quality is owned by the team. QA leads risk coverage and independent evidence, but developers, Product, security, data, AI, performance, and operations retain domain responsibilities.
2. Test at the lowest effective level. Prove business rules mainly through unit, component, API, and contract tests; reserve UI end-to-end testing for a small set of critical journeys.
3. Prevent before detecting. Review requirements, examples, data contracts, threats, observability, and testability before implementation.
4. Use one risk model with specialized evidence. Deterministic code, data pipelines, and probabilistic AI need different techniques but one release-governance model.
5. Production is observed, not used as the first test environment. Pre-production reduces known risk; controlled production checks detect real-environment problems.
6. Accept no unexplained data difference. Every processed or migrated record must have a known outcome.
7. Critical failures override averages. A high overall pass rate cannot compensate for a privacy leak or broken payroll journey.

Wiki map

mindmap
  root((Modern Quality))
    Risk and governance
      Critical journeys
      Risk tiers
      Release decision
    Test architecture
      Static and unit
      API and contracts
      Integration and E2E
      Exploratory
    Data quality
      Pipelines
      Reconciliation
      Migration
    AI quality
      Evaluation dataset
      Groundedness
      Safety and refusal
      Drift
    Non-functional
      Performance
      Security
      Resilience
      Accessibility
    Production
      Observability
      Progressive delivery
      Incident feedback

Read the child pages

• Risk model and release governance
• Layered test architecture
• Data pipeline and migration quality
• Testing AI and RAG features
• Performance, security, resilience, and production
• Hands-on Playwright starter
• Vietnamese edition

Source note

The strategic framework, product example, example thresholds, and release sequence are derived from Testing Tailieu.docx.pdf (26 pages, revision August 2026). Navigation, diagrams, condensed explanations, Playwright setup, and external links are editorial additions. Tool versions and external documentation should be rechecked before implementation.