Join our Discord
UI Script examples
Browse the UI Script library on GitHub, and read what each Test Management surface hands your callback before you adapt a script.
Every UI Script lives in the samples repository on GitHub. Each script is one .js file, in a folder named for the surface it runs on. Copy a script into a new UI Script in Global Settings, select that surface, and save. Reload Test Management before you test it.
The scripts use sample field names from demo projects. Swap in the names your own project uses before you enable a rule.
Treat every script in the library as a starting point. Test it in a sandbox project and confirm the behavior before you enable it on a production project.
For the meaning of every TM function the scripts call, see the TM toolkit reference. For the difference between internal_name and label, see Fields in UI Scripts.
Scripts by surface
Open the folder for the surface your rule runs on:
| Surface | Contents |
|---|---|
| Add Result and Update Result | Rules that require Notes or a linked defect before a Failed result saves. Each surface needs its own script. |
| Test Case Results Section | Custom buttons that file a pre-filled bug, open a runbook, or run your own dialog handler. |
| Test Case Form | Validation rules, field behavior, and custom buttons and dialogs. |
| Test Run Form | Naming conventions, conditional required fields, hide and lock rules, and pre-filled defaults. |
| Test Plan Form | Naming conventions, conditional required fields, and start and end date rules. |
| Exploratory Session Form | Naming conventions, conditional required fields, and timebox rules. |
What each surface hands your callback
Every callback receives an object describing the open form or the test case on screen. Read the matching table before you write a comparison.
Add Result and Update Result
A save callback on a result surface receives a formState with these keys:
formState key |
Value |
|---|---|
status |
The chosen result, shaped as { id, label }. It carries no internal_name, so compare label. |
notes |
The Notes field as a rich-text HTML string. It is an empty string when blank. |
defects |
An array of the defect objects linked on the dialog. It is an empty array when none are linked. |
customFields |
The values of your result custom fields |
Test Case Results Section
A button callback on the results section receives a context with these keys:
context key |
Value |
|---|---|
surface |
The string test_case_results_toolbar
|
projectId |
The ID of the project |
testCaseId |
The ID of the test case |
testCaseTitle |
The title of the test case |
testCaseDescription |
The description as a string |
testCasePreconditions |
The preconditions as a string |
testCaseSteps |
An array of step objects shaped as { number, content, expected, result }
|
testCaseCustomFields |
The custom field values on the test case |
latestResultStatus |
The status ID of the latest result |
latestResultComment |
The comment on the latest result, as a string |
Test Case Form
Both the Create Test Case form and the Edit Test Case form fire on this surface. Tell them apart with context.mode, which contains create or edit. The formState carries these keys:
formState key |
Value |
|---|---|
title |
The title as a string |
priority, state, caseType, automationStatus
|
System field objects shaped as { value, label, colour, internal_name }. Compare internal_name. |
owner |
The owner as a user object |
steps |
An object shaped as { count, items }, where each item contains { step, result, test_data }
|
preconditions, description
|
Rich-text HTML strings. Strip the tags before you test for emptiness. |
requirements |
An array of the linked requirement objects |
tags |
An array of the tags on the test case |
reviewers |
An array of the assigned reviewers |
reviewStatus |
The review status as a string |
templateId, folderId
|
The IDs of the template and the folder |
fields |
An object of your custom field values, keyed by display name |
The context on this surface is { surface: "test_case_form", mode, projectId, testCaseId }.
Create-issue addresses for your tracker
A script cannot call an API in the background, so a toolbar button hands the tester off with TM.openUrl instead. To point a script at your own tracker, swap the base address and the parameter names:
| Tracker | Create-issue address for TM.openUrl
|
|---|---|
| Jira | https://<YOUR_JIRA_DOMAIN>.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=<PROJECT_ID>&issuetype=<ISSUE_TYPE_ID>&summary=<TITLE>&description=<DESCRIPTION> |
| Azure DevOps | https://dev.azure.com/<YOUR_ORG>/<YOUR_PROJECT>/_workitems/create/Bug |
| Any other tracker | Your tracker’s own create-issue address, with its own parameter names |
Next steps
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
Thank you for your valuable feedback!