The governing quality document for MedConnect Mobile — the migration of ACME Health's patients and providers off CareLink Classic onto a native mobile app and provider web console. It defines how two Scrum teams build quality in across eight two-week sprints and two releases, and it is deliberately not a phase-gated test plan: there is no test phase in this program, because there is no point in the schedule where testing could sit.
7
QA embedded in squads
2
Scrum teams
8
Two-week sprints
2
Releases, both gated
DoD
The quality gate
The central premise. On a waterfall program, testing is a phase you can point to. Here it is a property of every story. A story is not "developed then tested" — it is not done until it is tested, and the Definition of Done is the enforcement mechanism. This strategy therefore spends most of its length on how quality is built into the sprint, and comparatively little on end-of-program test execution, because by design very little quality work happens there.
01 Purpose, Scope & Quality Objectives
MedConnect Mobile carries an unusual quality burden for an eighteen-week program: it is a clinical application handling PHI on personal mobile devices, delivering live video consultations through a third-party SDK, and migrating historical patient data off a platform whose vendor has announced end-of-support. Any one of those would justify a formal quality approach. Together they mean the program cannot rely on velocity alone as evidence of progress.
In scope
- The native patient mobile app (iOS and Android) — Falcon squad.
- The provider web console, platform services, and integrations — Anchor squad.
- PulseConnect video SDK integration and telehealth session behaviour.
- Data migration from CareLink Classic, including the Sprint 7 historical archive migration.
- Non-functional quality: security, privacy, accessibility, performance under degraded network conditions.
Out of scope
- Internal testing of the PulseConnect SDK itself — covered by vendor attestation and the executed BAA (assumption A-01), not re-tested by this program.
- CareLink Classic's own defects, except where they affect migration fidelity.
- ACME Health enterprise systems beyond the integration points this program consumes.
Quality objectives
| Objective | How it is met |
|---|---|
| No clinical workflow reaches a provider unvalidated | DoD requires clinical workflow sign-off (decision DEC-01) for scheduling, visit-launch and notes-handoff stories |
| No PHI exposure on device or in transit | Security and privacy checks in DoD; Compliance checkpoint before each release (DEC-02) |
| Video consultations work on real-world networks, not just office wifi | Degraded-network and device-matrix testing (Sections 07–08) |
| Migration is provably complete and accurate | Reconciliation testing and a validation report gating Release 2 (dependency D-03) |
| Regression cost stays flat as scope grows | Automation-first pyramid; regression suite owned by the squads (Section 06) |
02 Test Organization — Embedded, Not Downstream
Seven QA practitioners sit inside the two squads rather than in a separate QA function. There is no hand-off point and no test manager outside the teams; the Scrum Masters own flow, the QA Leads own approach, and the whole squad owns quality.
| Name | Role | Squad | Focus |
|---|---|---|---|
| E. Marchetti | QA Lead | Falcon (Mobile App) | Test approach, device matrix, release readiness for the patient app |
| R. Sato | QA Automation Engineer | Falcon | Mobile UI automation, CI integration, regression suite |
| A. Novak | QA Tester (Manual) | Falcon | Exploratory testing, usability observation, accessibility checks |
| N. Osei | QA Lead | Anchor (Platform/Integration) | API and integration test approach, contract testing, migration validation |
| V. Tran | QA Automation Engineer | Anchor | Service and contract automation, pipeline gating |
| M. Chen | QA Analyst (Manual) | Offshore — shared | Regression execution, migration reconciliation checks |
| P. Kumar | QA Analyst (Manual) | Offshore — shared | Regression execution, cross-device verification |
Wider quality accountabilities
| Who | Quality role |
|---|---|
| C. Tyrrell — Product Owner | Owns acceptance criteria quality; accepts or rejects stories at Sprint Review |
| Dr. L. Nguyen — CMIO | Clinical workflow sign-off under DEC-01; clinical safety judgement |
| T. Brannigan — Compliance & Security Director | Compliance checkpoint before each release (DEC-02); privacy and security assurance |
| D. Whitfield / A. Singh — Engineering Leads | Unit and contract test standards, code review, pipeline health |
| J. Marsh / R. Okafor — Scrum Masters | Protect in-sprint test capacity; surface quality impediments |
Offshore boundary. The two offshore analysts work exclusively with synthetic or de-identified data. No production PHI is accessible offshore — a constraint that shapes how migration reconciliation is split between onshore and offshore hands in Section 09.
03 Testing Within the Sprint
Quality activity is distributed across the existing ceremonies rather than added as extra meetings.
| Ceremony | Quality activity | Output |
|---|---|---|
| Backlog Refinement | Three-amigos review (PO, engineer, QA): is this story testable? What are the edge cases? What data is needed? | Acceptance criteria sharpened; test data needs identified before the sprint |
| Sprint Planning | Test tasks estimated as part of the story, never as separate "testing stories" | Capacity reflects the true cost of done |
| Daily Scrum | Blocked-in-test items raised same day; no story sits untested to the end of the sprint | Flow protected; late-sprint test crunch avoided |
| Sprint Review | Demo of working software on a real device; PO acceptance | Acceptance evidence recorded against the story |
| Sprint Retrospective | Escaped defects and flaky tests reviewed as process signals, not blame | Quality improvement actions in the next sprint |
Anti-pattern explicitly rejected. "Develop in sprint N, test in sprint N+1" is not permitted. It converts Scrum into two-week mini-waterfalls, hides defects behind a velocity number that looks healthy, and would make the DoD meaningless. If a story cannot be tested within the sprint, it is too big and is split at refinement — the same reasoning behind decision DEC-03.
04 Definition of Done as the Quality Gate
The Definition of Done is the program's single enforceable quality gate. A story that does not meet every applicable criterion is not done, regardless of sprint boundary or demo pressure.
| DoD criterion | Applies to | Evidence |
|---|---|---|
| Unit tests written and passing in CI | All stories | Pipeline green on the merge commit |
| Acceptance criteria verified by QA | All stories | QA sign-off on the story |
| Automated regression updated where behaviour changed | All stories | Regression suite commit linked |
| Tested on the current device matrix | Mobile app stories | Device coverage recorded (Section 07) |
| Security and privacy checks completed | Any story touching PHI | Checklist complete; escalation to Compliance if flagged |
| Accessibility checks completed | Patient- and provider-facing UI | Screen-reader and contrast verification |
| Clinical workflow sign-off | Scheduling, visit-launch, notes-handoff stories | CMIO or delegate approval — added by DEC-01 at Program Kickoff |
| No open high or critical defects on the story | All stories | Defect log clear |
05 Risk-Based Test Depth
Not every story warrants the same rigour. Depth is set by clinical and data consequence, not by story size.
| Tier | Characteristics | Examples | Required depth |
|---|---|---|---|
| Clinical / PHI | Affects a clinical decision, a live consultation, or patient data | Visit launch, clinical notes handoff, migration of patient records | Full DoD incl. clinical sign-off, security checks, device matrix, exploratory testing, regression, Compliance checkpoint |
| Patient-facing | Patient experience without direct clinical consequence | Booking and reschedule UI, notifications, profile | Full DoD incl. accessibility and device matrix; exploratory testing |
| Internal / supporting | No direct patient or clinical impact | Admin tooling, internal reporting, developer utilities | Standard DoD; automated coverage; proportionate manual verification |
06 Test Pyramid & Automation Strategy
Automation is what makes eight sprints of accumulating regression affordable for a seven-person QA bench. The shape is deliberate: heavy at the base, thin at the top.
Pipeline gating
| Trigger | What runs | Gate |
|---|---|---|
| Every commit / pull request | Unit, component, static analysis, dependency scan | Blocks merge on failure |
| Merge to main | Contract and integration suites | Blocks promotion to the test environment |
| Nightly | Full regression + UI automation across the device matrix | Failures triaged at the next Daily Scrum |
| Release candidate | Full regression, E2E critical path, performance, security scan | Blocks release readiness sign-off |
Flaky tests are treated as defects. A test that fails intermittently is worse than no test, because it trains the team to ignore red. Flaky tests are quarantined within one sprint and either fixed or deleted — never left failing in the suite.
07 Mobile-Specific Testing
A patient's phone is not a controlled environment. The device matrix is reviewed each release and deliberately weighted toward the older, slower, and smaller end of the estate, because that is where a telehealth app fails first.
| Dimension | Coverage | Why it matters here |
|---|---|---|
| OS versions | Current and two prior major versions, iOS and Android | Patient devices are not centrally managed and update slowly |
| Device classes | Flagship, mid-range and low-end handsets; small-screen and large-screen | Video plus UI on a low-end device is the realistic worst case |
| Network conditions | Wifi, 5G, 4G, throttled 3G, intermittent loss, handover between networks | A consultation that drops when a patient walks between rooms is a clinical failure, not a cosmetic one |
| Interruption handling | Incoming call, backgrounding, lock screen, low battery, OS notification | Video session must survive or recover gracefully |
| Permissions | Camera, microphone, notifications — granted, denied, revoked mid-session | Denial paths are the most common real-world support issue |
| App store readiness | Store review guidelines, privacy labels, build signing, staged rollout | A store rejection is a release-blocking event outside the team's control — checked before submission, not after |
08 Telehealth & Video Session Testing
Video is delivered through the PulseConnect SDK. The program does not test the SDK itself; it tests the program's use of it and the patient-visible outcome.
| Area | What is tested | Acceptance basis |
|---|---|---|
| Session establishment | Join from invite, waiting room, provider admit, late join, re-join after drop | All paths succeed within agreed time on the standard device matrix |
| Audio/video quality | Behaviour under bandwidth degradation; graceful fallback to audio-only | Session remains usable rather than failing outright |
| Screen share | Provider-initiated share, permission prompts, share of clinical content | Directly tied to risk R-02 — screen-share required unplanned vendor configuration; regression-protected once resolved |
| Session integrity | Only intended participants can join; session ends cleanly; no residual access | Security verification and Compliance checkpoint |
| Recording & retention | Whether recording is enabled, consent capture, retention behaviour | Compliance sign-off; no ambiguity permitted |
| Clinical continuity | Notes handoff after session; visit record written correctly | Clinical workflow sign-off under DEC-01 |
09 Data Migration Testing
The Sprint 7 historical migration is the program's single largest quality exposure — risk R-01 anticipates exactly that legacy archive records will surface data-quality issues. Migration is therefore tested as a first-class deliverable, not as a cutover task.
| Stage | Test activity | Owner |
|---|---|---|
| Pre-migration profiling | Profile CareLink Classic archive data; quantify completeness, duplicates, orphaned records | N. Osei + Data Migration Specialist |
| Mapping validation | Verify field-level mapping rules against clinical expectations | QA + Dr. L. Nguyen (CMIO) |
| Trial migration | Full dry run into a staging environment; defect capture and rerun | Anchor squad |
| Reconciliation | Record counts, control totals, and sampled field-level comparison old vs new | Onshore for PHI-bearing samples; offshore for synthetic and count-level checks |
| Exception handling | Verify that unmigratable records are quarantined, reported, and visible — never silently dropped | N. Osei |
| Validation report | Formal migration validation report submitted to Compliance | Anchor QA Lead → T. Brannigan |
Release 2 is gated on this. Dependency D-03 makes Release 2 cutover conditional on Compliance sign-off of the full historical migration validation report. Migration testing is not on the critical path by accident — it is the critical path into Release 2.
10 Compliance, Security & Privacy Testing
| Area | What is verified | Gate |
|---|---|---|
| PHI at rest on device | Encryption, no PHI in logs, caches, screenshots or backups; secure wipe on logout | DoD security check; Compliance checkpoint |
| PHI in transit | TLS configuration, certificate pinning, no PHI in URLs or analytics payloads | Security scan; blocks release |
| Authentication & session | Session timeout, re-authentication, device loss handling, token expiry | Security testing |
| Audit logging | Access to patient records is logged and attributable | Compliance verification |
| Vendor scope | PulseConnect processing stays within the executed BAA (assumption A-01) | Compliance confirmation per release |
| Consent | Consent captured and recorded where required for a telehealth session | Clinical + Compliance sign-off |
Two checkpoints, not one. Decision DEC-02 placed a Compliance review before both Release 1 and Release 2 rather than a single end-of-program gate. On a program shipping a pilot to real patients in Release 1, deferring compliance assurance to the end would mean exposing patients before the review that was meant to protect them.
11 Accessibility Testing
The patient population for a telehealth app skews older and more health-impaired than a general consumer audience. Accessibility is treated as a functional requirement.
- Target: WCAG 2.2 AA for the provider console and patient app, plus platform accessibility conventions on each mobile OS.
- Screen readers: VoiceOver (iOS) and TalkBack (Android) verified on core journeys — booking, joining a visit, viewing notes.
- Visual: contrast ratios, dynamic type and large-text scaling without layout breakage, no colour-only status indicators.
- Motor: target sizes, no reliance on precise gestures, adequate time limits with extension where clinically safe.
- Cadence: checked per story in DoD; audited in full before each release.
12 Cross-Team Contract Testing
Two squads with genuine runtime dependencies is where integration defects hide until late. Both realized dependencies on this program ran in the same direction — Falcon consuming Anchor services.
| Dependency | Risk if untested | Control |
|---|---|---|
| D-01 — Falcon booking/reschedule UI depends on Anchor's availability engine | UI built against assumptions; breaks on integration | Consumer-driven contract tests published by Falcon, verified in Anchor's pipeline |
| D-02 — Falcon video join flow depends on Anchor's video SDK integration | Video join fails only in the assembled system | Contract tests plus an early joint E2E on the critical path |
| R-03 — cross-team dependencies surfacing late in a sprint | Schedule impact within the sprint | Dependencies flagged at joint refinement; contract published before the consuming story starts |
The rule: a contract is published and verified before the consuming story enters a sprint. A dependency discovered during a sprint is treated as an impediment, escalated same-day between Scrum Masters — the response that resolved issue I-01.
13 Release Testing & Pilot Strategy
| Release | Scope | Test approach | Gate |
|---|---|---|---|
| Release 1 — MVP to pilot cohort | Core booking, video visit, notes handoff | Full regression, E2E critical path, device matrix, accessibility audit, security scan, clinical sign-off | Compliance checkpoint (DEC-02) + PO acceptance |
| Release 2 — full rollout + historical migration | Remaining scope, full patient population, archive migration | All of the above, plus migration reconciliation and the validation report | Compliance sign-off of migration validation (D-03) |
Holding Release 1 to a pilot cohort (decision DEC-04) is itself a quality control: it converts the first live release into a bounded feedback exercise, with real clinical usage observed at small scale before exposure widens. Pilot findings feed the backlog directly rather than becoming post-launch escalations.
Rollback
A rollback runbook exists for each release and is rehearsed, not merely written. Issue I-02 records that the runbook story was descoped from formal Sprint 5 board tracking and completed manually — accepted as a one-off, but the rehearsal requirement stands: an untested rollback is an assumption, not a control.
14 Defect Management
| Severity | Definition | Response |
|---|---|---|
| Critical | PHI exposure, clinical safety impact, consultation cannot proceed, or data loss in migration | Stop-the-line; fixed before any further story is accepted |
| High | Core journey broken with no workaround on a supported device | Fixed within the sprint; blocks the story's DoD |
| Medium | Impaired function with an acceptable workaround | Prioritized into the backlog by the PO |
| Low | Cosmetic or minor usability | Backlog |
Defects found within the sprint on an in-progress story are simply work — they are fixed, not logged as defects, because logging them would create administrative noise without improving the product. Defects that escape a sprint or a release are always logged, and their root cause is a standing retrospective input.
15 Test Environments & Test Data
| Environment | Purpose | Data |
|---|---|---|
| Local / CI | Unit, component, contract execution | Synthetic fixtures |
| Integration | Cross-squad integration and contract verification | Synthetic, referentially consistent |
| Device lab | Real-device mobile testing across the matrix | Synthetic patient accounts |
| Staging | Release-candidate regression, E2E, migration dry runs | De-identified production-derived |
| Production (pilot) | Release 1 pilot cohort with live monitoring | Live PHI — onshore access only |
- No production PHI in any non-production environment. De-identification retains realistic shape and volume so migration and performance testing stay meaningful.
- Clinical realism matters. Test patients include the awkward cases — long medication lists, historical name changes, duplicate records — because those are what break a migration.
16 Quality Metrics
| Metric | Why it is tracked | Target |
|---|---|---|
| Escaped defects per release | The honest measure of whether DoD is working | Zero critical; downward trend overall |
| Automated regression coverage of critical journeys | Determines whether regression stays affordable | 100% of critical path automated by Release 1 |
| Regression suite duration | A slow suite gets skipped | Nightly suite completes within the overnight window |
| Flaky test rate | Leading indicator of suite trustworthiness | < 2% of runs; quarantine within one sprint |
| Stories rejected at Sprint Review | Signals acceptance-criteria or DoD weakness upstream | Trend toward zero; investigated at retro |
| Device matrix coverage per release | Prevents silent narrowing of tested devices | 100% of the agreed matrix |
Quality metrics are reported on the Program Dashboard and reviewed at retrospectives. Velocity is deliberately excluded from this list — it measures throughput, not quality, and using it as a quality proxy is how teams end up shipping fast and wrong.
17 Risks to the Test Approach
| Risk | Impact on quality | Mitigation |
|---|---|---|
| R-01 — legacy archive data quality | Migration testing expands late; Release 2 gate at risk | Profiling before Sprint 7; exception handling designed in; reconciliation automated |
| R-02 — video SDK screen-share configuration | Vendor-dependent behaviour outside team control | Early spike; regression-protected once configured; vendor escalation path in the Vendor Management Plan |
| R-03 — late cross-team dependencies | Integration defects found at sprint end | Contract-first approach (Section 12); joint refinement |
| In-sprint test capacity squeezed by delivery pressure | DoD quietly eroded; defects escape | Test tasks estimated within the story; Scrum Masters protect capacity; DoD is not negotiable at Sprint Review |
| Device matrix drift as OS versions release mid-program | Coverage silently narrows | Matrix reviewed each release; coverage reported as a metric |
Governing relationship. This strategy sits beneath the Program Charter and Program Management Plan, and is the parent of the Definition of Done, which is where it becomes enforceable day to day. Changes follow the program's change-handling process; changes affecting clinical sign-off or compliance checkpoints additionally require CMIO and Compliance endorsement.