Test an agent reply and the status that goes with it

Failure modes in this flow

Both halves of the action need checking, and the status has to be checked somewhere other than the page that set it.

• The right ticket is open - 4409, identified by number and subject.
• The reply is recorded - the exact text appearing in the conversation.
• The status changed - Pending on the ticket fields.
• The queue agrees - the same status on the row in the ticket list.

Checking the list view is what makes this more than a form test. A ticket detail page that shows Pending while the queue still shows Open means the next agent picks up a ticket that is already handled, and the customer gets two replies.

Writing the objective

The reply text is asserted in the conversation rather than in the compose box, which proves it was posted rather than merely typed.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/zendesk-clone-app/agent?reset=true
max_steps: 45
tags: [zendesk, support, agent]
---

# Zendisk 30.2: Agent reply and status

Catalog objective: reply as an agent and set the status to pending.
Key assertion: the reply is recorded and the status change sticks.

## Open the ticket
Click "Open" on ticket 4409 and verify the page title reads "#4409 · Cannot download my August invoice".

## Write a reply
Type "I can see the failure in our logs and a fix is going out today." into "Public reply".

## Submit as pending
Click "Submit as Pending" and verify the conversation now contains that reply text.

## Verify the status changed
Verify "Status" in the ticket fields now reads "Pending", then click "← All tickets" and verify the 4409 row shows a status of "Pending".

Navigating back through the all tickets link, rather than reloading, is what would expose a list served from cache after the update.

The assertions in detail

A ticket, a reply, a status and the queue.

The reply and the status are asserted separately because a submit that posts the text and fails to move the status is a realistic and common half-failure.

Running it locally

kane-cli testmd run tests/zendesk/agent-reply-status_test.md

Add an internal note, since a note that posts as a public reply is a support incident rather than a bug.

Queue state drives who does what next. Evidence based QA covers keeping proof, and Kane CLI as a QA agent covers building the suite around it.