- Overview
- Quickstart
- Trust and compliance
- Governance
- Features
- Cartographer
- Delegate for Testing
- Reference
- Troubleshooting
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 — no additional setup is needed for these tasks.
Finding test cases to run
- 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.
Use either the name or the ObjKey when asking Delegate to run one.
Writing a new test case from scratch
- 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."
- 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.
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 page — it automates the description and drafting steps above.
Finding and fixing stale test cases
- Run the affected test case or test set as usual after a UI change.
- 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'."
- 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.
Maintain a separate, secured test-credentials reference (for example, a password manager) that the team consults, rather than writing real values into steps.