Test order tracking and the delivery timeline

Failure modes in this flow

A tracking page fails in ways that do not throw errors. The most common is a stage marker that drifts out of sync with the status text above it, so the page says one thing in the summary and another in the timeline.

• The list and the detail disagree - the orders list promises a delivery date the detail page does not repeat.
• The timeline stalls - the carrier record advances but the current stage marker stays where it was.
• The tracking id goes missing - the carrier line renders empty and the shopper has nothing to paste into a carrier site.

Each of those is a text level assertion, which is exactly what a plain English test is good at. The test quotes the strings a shopper reads and fails when they stop matching.

Writing the objective

The objective is written as three steps that follow the shopper: see the order, open its tracking, read the timeline. Specific values are quoted so a stale fixture cannot pass by accident.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/shop-clone-app/orders?reset=true
max_steps: 40
tags: [amazon, e-commerce, tracking]
---

# ShopKart 1.4: Order tracking

Catalog objective: open recent orders and track a shipment.
Key assertion: status timeline renders with the current stage.

## Confirm the order list
Verify the orders page lists "3 orders" including order "112-8830571-2094318" with status text containing "Arriving Tuesday, September 16".

## Open tracking for the in-transit order
Click "Track package" on order "112-8830571-2094318" and verify the detail page shows "Arriving Tuesday, September 16" and "ShopKart Logistics · Tracking ID TBA304991285001".

## Confirm the timeline stage
Verify the timeline lists the steps "Ordered", "Shipped", "Out for delivery" and "Delivered", and that "Shipped" is marked "Current status".

The third step is the one worth copying into your own suite. It asserts the full set of stages and then asserts which one is marked current, so a timeline that renders all four labels but highlights the wrong one fails. Run it with:

kane-cli testmd run tests/amazon/order-tracking_test.md

Running it locally

All three steps passed, and the timings fall as the run goes on because the browser is already warm and the pages get simpler.

---
test: ../order-tracking_test.md
status: passed
started: 2026-09-15T09:12:21.091Z
duration_s: 101
session_id: c30457ab-e1da-4e30-89ba-2d498ca92026
---

# ShopKart 1.4: Order tracking - Result

## Confirm the order list ✓ passed (34.2s)
md5: 39d69838e2c9d76c77d9cfbb15cacdad
Verify the orders page lists "3 orders" including order "112-8830571-2094318" with status text containing "Arriving Tuesday, September 16".

## Open tracking for the in-transit order ✓ passed (43.5s)
md5: 36cf0ed56714bbed68c838cec2c329c1
Click "Track package" on order "112-8830571-2094318" and verify the detail page shows "Arriving Tuesday, September 16" and "ShopKart Logistics · Tracking ID TBA304991285001".

## Confirm the timeline stage ✓ passed (21.7s)
md5: dfbd93e8fad2ff55b0a13be74d844d24
Verify the timeline lists the steps "Ordered", "Shipped", "Out for delivery" and "Delivered", and that "Shipped" is marked "Current status".

One warm browser is reused across all three steps, so session state carries over and the run does not pay a fresh startup cost per step.

Putting it in CI

The result is a post-purchase check that runs in under two minutes and covers the surface that support tickets actually come from. It needs no fixtures beyond the app's own seeded data and no selector maintenance.

Tracking pairs naturally with returns, since both start from the same orders list. Generating test cases with Kane CLI is the fastest way to draft the neighbouring flows, and the Kane CLI introduction covers the basics if this is your first run.