Test return initiation end to end

The flow under test

Return initiation is a multi-stage form wearing a simple interface. Each stage gates the next, so a failure early on produces a confusing error late, and the test has to be able to say which stage actually broke.

• Eligibility - the order has to be in a state that allows a return, and the page has to say so.
• Reason capture - the dropdown has to render with its label and offer the reasons the policy expects.
• Method selection - choosing pickup over drop-off has to register and stay selected through submission.
• Confirmation - an RMA number and a refund amount have to come back, because that is what the shopper screenshots.

Splitting those into four steps means the result file names the stage that failed. A single end-to-end assertion would only tell you the RMA never appeared.

The test file

The step ceiling is raised to 45 here because the flow is longer than the others in this set. Each step quotes the string the page has to show before the next one is allowed to start.

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

# ShopKart 1.5: Return initiation

Catalog objective: start a return on a delivered order.
Key assertion: return confirmation with a return authorization number.

## Open the delivered order
Click "Return or replace items" on order "112-4419602-7831456" and verify the order detail page shows "Delivered Friday, September 5".

## Start the return
Click "Return or replace items" in the Returns section and verify a reason dropdown labelled "Why are you returning this?" is shown.

## Choose a reason and method
Select "Item arrived damaged" as the reason, click "Schedule a pickup", and verify "Schedule a pickup" is selected.

## Submit the return
Click "Submit return" and verify the page shows "Return started" with a return authorization starting with "RMA-" and a refund line containing "$86.39".

The final assertion checks a prefix rather than a fixed value, since an RMA number is generated per return. Asserting that it starts with "RMA-" and that the refund line contains $86.39 keeps the test meaningful without pinning it to one record. Run it with:

kane-cli testmd run tests/amazon/return-initiation_test.md

The run

Four passes, with the reason and method step the slowest at 50.9 seconds because it involves a dropdown selection and a radio choice before its assertion.

---
test: ../return-initiation_test.md
status: passed
started: 2026-09-15T09:14:17.121Z
duration_s: 160
session_id: 077b93a2-c075-463f-b358-1190e0f2398a
---

# ShopKart 1.5: Return initiation - Result

## Open the delivered order ✓ passed (32.2s)
md5: 7e059382d4a65ad8ad64b74fd6184f20
Click "Return or replace items" on order "112-4419602-7831456" and verify the order detail page shows "Delivered Friday, September 5".

## Start the return ✓ passed (40.9s)
md5: 5eb18ec40ccc70c46f04518e64780a31
Click "Return or replace items" in the Returns section and verify a reason dropdown labelled "Why are you returning this?" is shown.

## Choose a reason and method ✓ passed (50.9s)
md5: 7621632bff75cbbc785285d088834d96
Select "Item arrived damaged" as the reason, click "Schedule a pickup", and verify "Schedule a pickup" is selected.

## Submit the return ✓ passed (33.4s)
md5: d733c7cc338f88e565c47717aac47426
Click "Submit return" and verify the page shows "Return started" with a return authorization starting with "RMA-" and a refund line containing "$86.39".

The 160 second total is the longest run in the ShopKart set, which is what a four-step form flow costs. That is still faster than creating a delivered order by hand to test it once.

Reading the evidence

You end up with a returns regression test that can run on every release, written in language the support team could review. The assertions double as a record of what the return confirmation is contractually required to show.

Returns and order tracking share a starting point, so the two tests make a natural pair in a post-purchase suite. For scaling past a handful of flows, going from a PRD to evidence covers designing a suite against requirements rather than one test at a time, and Claude Code with Kane CLI shows the same flow driven from an AI coding agent.