A Test Case describes what to test, how to test it, and what should happen. In Vansah, you can reuse a Test Case across Jira work items, Test Folders, and Test Plans, then record a separate Test Run each time you execute it.
What a Test Case contains
Part | Purpose |
Headline | A short title that describes the behavior being checked. |
Description | The objective, scope, or supporting context for the test. |
Precondition | The setup needed before testing, such as an active test account. |
Test Script | The actions or script used to perform the test, with expected results where applicable. |
Properties | Information such as Status, Type, Priority, Labels, Components, Owner, Assignee, and Estimated Time, where available in the current context. |
Links and evidence | Related work items, folders, plans, executions, and supporting attachments. |
Understand the Test Case key
Vansah assigns a readable key when a Test Case is created. For example, DEMO-C105 means:
DEMOis the Jira space key.Cidentifies a Test Case.105is the case number assigned within that Jira space.
Use the Test Case key to recognize the case in Vansah and in integrations that support it. Select the relevant version as well when the workflow requires one.
Choose the script format
Format | Use it for |
Multi Steps | A sequence of actions with test data and expected results for individual steps. |
Plain Text | Instructions written as a single text script. |
BDD (Gherkin) | Behavior examples written with syntax such as Given, When, and Then. |
Automation | An automation script managed through Vansah’s supported automation workflow. |
The script format is separate from the Test Case’s Type, such as Functional. Type classifies the test; the script format determines how its script is represented.
Keep properties and results separate
The Test Case’s Status describes its configured state. It is different from an execution result such as Passed or Failed. Use the statuses available in your Jira space rather than assuming every space has the same status names.
Owner: responsibility for the Test Case itself.
Assignee: responsibility in the linked requirement or testing context. The same case can have different assignees in different contexts.
Labels and Components: help classify and find tests. The label picker can include both existing Jira labels and Vansah labels.
Estimated Time: the estimated time to perform the test.
Recording a result creates or updates execution information for a Test Run; it does not turn the Test Case itself into a Jira work item.
Use versions and links
Test Case versions let you maintain different versions of the case and its script. A folder, work item, or plan can use a selected version. Check that selection before editing coverage or executing the test.
The default version and the version selected for an existing link are different concepts. Changing the default does not mean every existing link has switched to that version.
Linking an existing case reuses it. Cloning creates a separate case. See Test Case Versioning and Link Test Cases to Work Items and Test Folders.
Example: test a successful sign-in
Headline: Sign in with an active account.
Precondition: An active test account exists and the sign-in page is open.
Action | Expected result |
Enter a valid test email address and password. | The entered details are accepted by the form. |
Select Sign in. | The account’s home page opens. |
Create the Test Case once, link it to the sign-in requirement, and execute it when testing that requirement. Record what actually happened in the Test Run and add evidence or a defect if needed.
Next: Create a Test Case. For automation, use the relevant test results integration guide and its verified request format.

