The setting

Meridian Pay runs cloud payroll for small businesses. A four person QA team is the last check before every pay run, and payroll bugs move real money, so the work is careful and evidence driven.

Every mission on this path happens at the same company, so context carries over the way it does in a real job: the data you cleaned in mission two is the data the finance lead questions in mission four.

The missions

1. test planstarter

Write the test plan for Meridian's direct deposit split feature

You are a QA engineer at Meridian Pay, a cloud payroll service for small businesses. Product is shipping a direct deposit split feature that lets an employee route one paycheck across up to three bank accounts, and it goes to beta in two weeks.

You deliver: A written test plan for the direct deposit split feature with scoped test cases, edge cases, and a list of spec gaps to resolve.

Scored on: Rule coverage, Edge cases caught, Concrete cases, Spec gaps listed.

Working from: deposit_split_spec.md.

2. exploratory charterstarter

Charter an exploratory session on Meridian's timesheet import screen

Meridian lets admins bulk import employee hours from a CSV before each pay run. The import screen was rebuilt last sprint and has no automated coverage yet. You have one afternoon to explore it.

You deliver: A set of session based exploratory test charters for the timesheet import screen, ordered by risk.

Scored on: Charter structure, Risk ordering, Quirk coverage, Testable missions.

Working from: timesheet_import_notes.md.

3. bug reportcore

File the bug for Meridian's overtime miscalculation before payroll runs

A beta customer says their crew was overpaid last week. You reproduced it. Overtime is being calculated on daily hours instead of the weekly rule Meridian follows, and payroll runs tonight.

You deliver: A bug report for the overtime miscalculation with reproduction steps, expected versus actual pay, and a justified severity.

Scored on: Names the broken rule, Reproduction steps, Expected versus actual, Severity justified.

Working from: overtime_repro.md, overtime_rules.md.

4. regression mapcore

Build the regression map for Meridian's tax table release

The tax table update for the new quarter is code complete. A full regression pass takes the team three days and you have one and a half. You need to decide what actually gets retested.

You deliver: A regression map linking each change to the areas that must be retested, with priorities and rationale.

Scored on: Change tracing, Shared code caught, Priority ranking, Scoped out clearly.

Working from: change_log.md, module_map.md.

5. release riskstretch

Write the go or no go risk assessment for Meridian's Q3 release

It is go or no go day for the Q3 payroll release. As the QA engineer on the release you own the risk call that leadership signs off on. Payroll bugs move real money, so this note carries weight.

You deliver: A release risk assessment with a defended go, no go, or go with conditions recommendation.

Scored on: Blocker identified, Risk by area, CI signal judged, Defensible recommendation.

Working from: open_bugs.csv, release_checklist.md, ci_flaky_log.md.

How the scoring works

Each deliverable is graded against the rubric written for that mission. Separately, every mission on every path is graded on how you used AI, against the same four criteria:

  • Understood the task. The learner framed the goal for the assistant clearly instead of pasting the brief and hoping.
  • Grounded in the material. The learner directed the assistant into the provided files and based the work on them, not on invented facts.
  • Verified the output. The learner checked claims, numbers, or coverage against the source material before submitting.
  • Iterated with judgment. The learner refined weak parts of the draft with specific follow-ups rather than accepting the first answer.

Both scores, with the work behind them, go on your proof profile. That is what makes a claim like "I can use AI for manual qa" something an employer can check.