QA Team: Charter, Postman/Newman Process, and Incident Routing

First broad introduction of the QA team to the organization. This session explains the team’s charter, how Postman/Newman testing is wired into staging deploys, and how QA incidents are categorized and routed to owning service teams.

QA Recording

TL;DR

The QA team was newly formed in 2025 and focused on service continuity at the API/service layer (MAP environment). Scope is backend/API behavior and cross-service integrations, not frontend UI quality.

Out of scope at recording time: load testing, security audits, usability, and accessibility.

Core toolchain: Postman collections executed by Newman in Jenkins on staging deploys, with HTML reports posted to a shared Slack reporting channel.

Incident routing is formalized: QA confirms reproducibility, logs a QA incident, then classifies as bug, testing-process issue, or environmental issue and routes accordingly.

Long-term model: QA bootstraps and scales testing practice, then ownership of service-specific test scripts shifts to service teams.

Team and Charter

The team was introduced as a newly formed function with PM, automation lead, and automated test execution support roles.

Primary goal:

  • Detect issues that would break service consumers before production impact.

Primary testing objectives:

  • contract validation

  • regression safety

  • smoke coverage

  • deeper functional and integration checks for continuity across dependent services

Important boundary:

  • End-to-end validation is done for MAP backend workflows and dependencies only, not web/mobile UI layers.

Why Staging Is the Primary Test Environment

Testing is centered in staging because it is the closest practical mirror to production and exposes multi-team configuration interactions that local environments often miss.

Runs can be automated on deploy and manually triggered as needed. Future intent discussed: scheduled interval runs (for example hourly/daily/weekly), tuned per service.

Postman/Newman Implementation

Postman Structure

Key patterns described:

  • workspaces aligned to Bitbucket project boundaries

  • one collection per service

  • collection-level shared auth/header config (for example JWT header)

  • foldering by domain/flow (for example staff vs veteran, booking vs requests)

Variables strategy:

  • environment variables for static per-environment values

  • collection variables for runtime-changing values during a run

JWT Retrieval Improvement

A major workflow improvement was direct JWT retrieval in staging for both veteran and staff flows, removing manual token extraction from UI sessions.

Data-Driven Iterations

Collections can run against JSON iteration datasets (ICN/EDIPI/site combinations), enabling scenario coverage across multiple patient/service contexts in one execution.

Newman in Pipeline

Newman executes collections in Jenkins against staging with collection, environment, and data files. Results are shared as human-readable HTML reports in Slack, making outcomes visible beyond QA engineers.

Report Anatomy and Failure Analysis

The report flow includes:

  • run summary (time, collection, environment, duration)

  • request/test totals, failures, skips

  • per-request request/response details

  • assertion-level pass/fail diagnostics

  • iteration-by-iteration context

An example discussed in-session showed a failed booking assertion that was ultimately a test-data constraint issue (request limit) rather than a service defect, illustrating why triage classification matters.

QA Incident Routing Process

  1. Detect issue (automated report, manual staging test, or stakeholder feedback).

  2. Reproduce and validate.

  3. Log under QA board with QA labeling.

  4. Categorize:

    1. Bug → create/route bug ticket in owning service Jira project (for example CKM, Veos/VOSR, CES), link back to QA incident.

    2. Testing process issue → QA fixes script/pipeline issue and reruns.

    3. Environmental issue → track and monitor; escalate as bug only if persistent/recurrent.

This preserves traceability from detection through service-team resolution.

Operational and Collaboration Notes

The session highlighted a current visibility gap: bug notifications concentrated in a QA Slack channel where PM coverage was inconsistent. Team discussion leaned toward broader PM presence for rotation/coverage.

Release-flow placement was clear: Newman runs automatically on staging deploy, so QA is continuously in the background rather than requiring ad hoc pre-release tagging for each deployment.

Why This is in the Knowledge Base

This is the foundational reference for engaging with the QA team: what they test, what they do not test, how automated staging validation works, and how incidents are routed to owning engineering teams. It is especially relevant for planning test ownership, interpreting Newman signals, and avoiding ambiguity during defect triage.