# Authoring and maintaining test cases

> Find, write, and keep Test Manager test cases current with Delegate, including fixing steps that break after a UI update.

Find existing test cases, draft new ones from a plain-English description, and keep them current as the application changes, including catching and fixing steps that break after a UI update.

## Prerequisites

Complete the one-time setup in [Setting up and running your first test case](installing-delegate-for-the-testing-profile.md) — no additional setup is needed for these tasks.

## Finding test cases to run

1. Enter a prompt to list or search test cases, for example: *"List the test cases in project MYAPP"* — or narrow it: *"Find test cases containing 'login' in project MYAPP"* or *"Show test cases created by me in project MYAPP."*

**Result**

**Delegate** searches Test Manager and returns the matching test case names, ObjKeys, and IDs.

:::tip
Use either the name or the ObjKey when asking **Delegate** to run one.
:::

## Writing a new test case from scratch

1. Describe the flow you want to test, for example: *"Help me write a test case for the password reset flow — user enters their email, receives a reset link, clicks it, sets a new password, and can log in with it."*
2. Ask **Delegate** to run the new test case to validate that the steps work as written.

**Result**

**Delegate** turns the description into a structured list of atomic steps with an expected result for each. You can also ask "What edge cases should I cover for this flow?" to surface scenarios you might have missed. Review the draft and adjust element names and values to match your actual UI; **Delegate** does not know your application until you show it or paste acceptance criteria.

When you ask **Delegate** to run the test case, it executes it end-to-end, showing which steps passed and which caused a pause, a sign the wording needs adjusting. Fix any flagged steps and add the test case to your test set once it passes cleanly. Budget 15–20 minutes for a new test case.

:::note
If you have acceptance criteria in Jira, see "Reading a ticket and drafting test cases from it" on the [Testing with Jira integration and reporting](testing-with-jira-integration-and-reporting-use-case.md) page — it automates the description and drafting steps above.
:::

## Finding and fixing stale test cases

1. Run the affected test case or test set as usual after a UI change.
2. If a step's element has moved or been renamed, tell **Delegate** what changed, for example: *"Rewrite this step — the button is now called 'Sign In' not 'Login'."*
3. Once a quarter, ask **Delegate** to list stale test cases, for example: *"List all test cases in project MYAPP that have not been executed in the last 60 days."*

**Result**

When a step's element has moved or been renamed, **Delegate** pauses mid-run and shows you what it sees — treat every pause as a maintenance flag, not just a failed run. After you describe the change, **Delegate** updates the step description, ready to re-run. The quarterly stale-test-case list gives you candidates to either re-activate or retire deliberately.

### Writing steps Delegate can execute reliably

The golden rule: write steps the way you would explain them to a new colleague, not the way you would write code.

| Element | Good example | Problematic example |
| --- | --- | --- |
| Action | "Click the Login button" | "Interact with auth element" |
| Expected result | "The dashboard page loads" | "System responds correctly" |
| Specificity | "Enter 'admin@example.com' in the Email field" | "Fill in credentials" |
| One thing at a time | One action per step | "Log in and navigate to settings and change password" |

Name the element you are interacting with, state what success looks like in the Expected Result field, keep steps atomic, avoid internal jargon, and include test data explicitly. Navigation, form-fill, and verification steps are handled most reliably; file uploads/downloads, elements inside iframes/popups, and timing-dependent steps may need extra guidance.

### Handling sensitive data in test steps

Never enter real credentials or Personally Identifiable Information (PII) into test case steps. Step content passes through AI when **Delegate** executes it, and Test Manager content is visible to your whole team by default.

Use a dedicated test account and password, a test mailbox, clearly fictional names and addresses, your payment provider's sandbox card numbers, and records that only exist in staging.

:::important
Maintain a separate, secured test-credentials reference (for example, a password manager) that the team consults, rather than writing real values into steps.
:::