Enrollment & Claims Platform Modernization

Manual test execution capacity under the dual-shore model. Test design and defect triage remain the program's. Issued under the governing master agreement.

SOW-003 · Offshore Manual Test Execution Capacity

1 · Parties and Instrument

2 · Scope

The program runs a dual-shore test model. Test design, defect triage and release decisions stay onshore with the Client's QA lead; manual execution runs offshore. This Statement of Work buys the execution capacity and nothing else.

The split is not a cost decision alone. A supplier paid by the hour should not be the party deciding how many hours of testing are needed, nor whether a defect is a defect. Keeping design and triage with the Client removes that conflict entirely, and it is why the scope below reads as narrowly as it does. The Vendor executes what it is given, reports what it observes, and proposes a severity that the Client sets.

In scope. Manual execution of Client-authored test cases in Client-provided environments; defect raising with reproduction steps, evidence and environment detail; re-test of resolved defects; daily execution reporting; and a named coordination lead attending the Client's daily test stand-up.

Out of scope. Test case design, which is the Client's. Deciding severity or priority — the Vendor proposes, the Client sets. Automation of any kind; this engagement is manual execution only. Any access to production, which the Vendor never receives. Any work on records outside the agreed masked test data set.

Anything not described in this section is out of scope. In particular, a request to investigate a failure outside an assigned test case is a variation, however small it appears at the time.

3 · Approach

Execution runs in cycles opened and closed by the Client. Within a cycle the Vendor works an assigned set of cases, reports daily on what was planned against what was executed, and raises defects with enough evidence that the onshore team can triage without a conversation. The measure of a good execution team is not how many defects it raises but how few are returned as tester error.

The engagement is staffed with a named coordination lead and named testers. Continuity matters more than headcount in manual execution: a tester who has run a cycle knows which parts of the application are fragile, and that knowledge is lost entirely when the person is replaced. The Vendor therefore commits to a turnover ceiling rather than only to a team size.

Reporting is designed so the Client can see trouble early. The daily report distinguishes cases blocked from cases failed, because the two have different owners: a failure is the program's defect to fix, while a blocker is usually an environment or data problem on the Client's side. Conflating them hides the Client's own bottleneck inside the supplier's numbers.

Evidence is captured as the work is done rather than reconstructed at the end. The exit evidence pack is a by-product of daily discipline, not a separate effort, and it is written to be sufficient for the Client's SOX control testing without further Vendor input.

4 · Delivery Phases

Phase 1 — Mobilization

A named, inducted team with proven environment access before any case is executed against a real build.

Phase 2 — Cycle execution

Assigned cases executed and reported daily, with defects raised to the agreed evidence standard.

Phase 3 — Cycle close and evidence

Each cycle closed with a reconciliation against plan, and evidence sufficient for the Client's control testing.

5 · Acceptance

Each Deliverable is submitted with the evidence its acceptance criteria call for. The Client has the stated Review Period to accept, or to reject in writing with specific, criterion-by-criterion reasons. Silence for the whole Review Period is acceptance — deemed acceptance — because a program cannot hold a supplier to a date while leaving its own review open-ended.

A rejection must identify which criterion failed and how. An objection that the Deliverable is not what was expected, where it meets every stated criterion, is a variation rather than a rejection. The Vendor re-submits within ten Business Days and a second Review Period of five Business Days runs. A Deliverable rejected twice on the same criterion is escalated rather than looped.

The Review Period is deliberately short and deliberately symmetrical. The Client gains a fixed window in which to find defects; the Vendor gains certainty that the window closes.

6 · Timeline and Resourcing

The engagement runs from execution to warranty exit at program closeout on Nov 2, 2027, across the cycles the Client opens. Capacity is drawn down against a capped envelope rather than committed as a fixed team for a fixed period, so a cycle that is not opened costs nothing.

The table below shows who is involved on each side. The offshore rows are named because they appear in the program's own Resource Plan with their hours; the Client rows are shown because the Vendor's dates depend on them.

7 · Fees and Payment

Charged monthly in arrears on hours actually worked and evidenced, at the rates in the rate card, against a capped envelope of $947,000.

• Hours are evidenced by the daily execution reports. An hour without a corresponding execution record is not payable.
• The Vendor notifies the Client in writing on reaching 80% of the envelope. Work beyond the cap requires an executed variation before it is performed.
• Re-test of a defect caused by the Vendor's own execution error is not chargeable.
• Time lost to blocked environments is reported but not charged as execution.

Invoices are payable thirty days from receipt of a correct invoice. The Client may withhold the disputed portion of an invoice, and only that portion.

8 · Assumptions

The dates and the price in this Statement of Work rest on the following. Each is stated so that its failure is visible rather than argued about later; where one fails, the consequence is handled under Project Variations.

• Test cases, scripts and expected results are supplied by the Client before a cycle opens. The Vendor does not author them and does not infer them.
• Test environments are stable and available during the Client's business day. Environment downtime is reported as blocked, not failed, and is not chargeable as execution.
• Masked test data meeting the agreed profile is available. The Vendor never receives production data.
• Defect triage and severity decisions are returned within one Business Day, so re-test capacity is not left idle.
• The capped envelope of $947,000 is a ceiling, not a commitment. The Client pays for capacity used.
• Tester access to the Client's environments and defect tool is provisioned before mobilization completes.

9 · Project Variations

Either party may propose a variation. The Vendor prices it within five Business Days, stating the effect on fees, on dates, and on any other Deliverable. No variation takes effect until both parties sign, and work performed in anticipation of one is at the Vendor's own cost — the clause exists so that goodwill work does not arrive later as an invoice.

Where an assumption in the preceding section fails, the consequence is handled here rather than absorbed silently. A failed dependency moves the affected dates by the period of delay and no more; it does not reopen scope or price unless the parties agree that it should.

A variation that alters the program baseline set at the Nov 3, 2026 milestone is additionally subject to program change control and the Change Control Board, not to this SOW alone. A change within the SOW is a commercial matter between the parties; a change to the baseline is a program matter that other work packages depend on.

10 · Terminology

11 · Governing Agreement

This Statement of Work is issued under the Master Services Agreement between the parties and creates no rights independent of it. Warranty, limitation of liability, intellectual property, confidentiality, data protection, insurance, termination and dispute resolution are governed by the MSA and are not restated here. Restating them invites the two documents to disagree, and a Statement of Work that contradicts its own master agreement is worse than one that is silent.

Where the Vendor handles protected health information, the parties' Business Associate Agreement governs and prevails over both this SOW and the MSA to the extent of any conflict. On any other matter the order is: the BAA, the MSA, this SOW, then an executed variation, which prevails over this SOW only on the matter it changes. The Vendor's standard terms — in a portal click-through, an invoice footer or an order acknowledgement — are excluded.

12 · Execution

Executed following the approval convention this suite uses in SOW-001: the Vendor / Procurement Manager signs for the Client, the Vendor signs through its own authorized representative, and the internal approvals below are recorded separately. ⚠ The Program Manager approves but does not sign — program authority is not signing authority, and the separation is deliberate.

⚠ The Vendor is deliberately unnamed throughout this suite, so the vendor signature line carries a role rather than a person. That is the convention, not an omission — and an unexecuted Statement of Work does show a blank signature line on both sides. The Client side names individuals because they are the program's own people, who appear by name across the rest of the suite.