The setting

Tidewell is an online grocery service that delivers same day in eight metro areas. Engineering ships to production twice a day, so the automated checks you build are the safety net that decides whether each deploy goes out.

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 targetstarter

Pick the first automation targets for Tidewell's regression suite

Tidewell's manual regression pass takes a full day and blocks the afternoon deploy. Your job this quarter is to automate the cases that give the most protection per hour of effort, starting now.

You deliver: A prioritized automation candidate list with a defended ranking and the cases to defer.

Scored on: Top candidates, Deferrals reasoned, Time saved estimated, Data driven.

Working from: manual_suite.csv.

2. selector strategystarter

Set the selector strategy for Tidewell's cart page

The cart page tests break every other sprint because the selectors chase styling and generated ids. Before you write more, you are setting the selector strategy the team will follow.

You deliver: A selector strategy for the cart page naming the fragile selectors, stable replacements, and hooks to add.

Scored on: Finds fragile selectors, Stable alternatives, Hooks to add, Follows standards.

Working from: cart_markup.md, automation_standards.md.

3. API testcore

Design the API tests for Tidewell's place order endpoint

Tidewell is exposing the place order endpoint to a new partner integration. Before it ships you need a written API test design that a partner engineer could also read to understand the contract.

You deliver: An API test design for the place order endpoint covering happy paths, validations, error codes, and spec gaps.

Scored on: Case completeness, Error code coverage, Catches the contradiction, Undefined cases flagged.

Working from: order_api_spec.md.

4. fixture designcore

Design the test fixtures for Tidewell's substitution engine

When an item is out of stock, Tidewell's substitution engine offers a replacement. It has almost no test data, so bugs slip through. You are designing the fixtures that will drive its tests.

You deliver: A test fixture design for the substitution engine mapping concrete data records to the rules they exercise.

Scored on: Concrete records, Rule mapping, Edge cases, Realistic data.

Working from: catalog_schema.md, substitution_rules.md.

5. CI reportstretch

Diagnose Tidewell's flaky deploy pipeline and write the report

Tidewell's deploy pipeline has gone from trusted to ignored. Engineers rerun red builds until they pass, which means a real regression could sail through. You are diagnosing the flakiness and writing the report that gets the pipeline trusted again.

You deliver: A CI health report classifying flaky versus real failures, likely causes, fixes, and the runtime problem.

Scored on: Flaky versus real, Evidence from data, Causes and fixes, Runtime flagged.

Working from: pipeline_runs.md, test_timing.csv.

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 automation qa" something an employer can check.