Skip to main content

What Is a Test Case?

Understand a Vansah Test Case, its readable key, script formats, properties, versions, and links to Jira work items and test executions.

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.

Vansah Test Case showing its headline, description, precondition, version menu, and properties

Understand the Test Case key

Vansah assigns a readable key when a Test Case is created. For example, DEMO-C105 means:

  • DEMO is the Jira space key.

  • C identifies a Test Case.

  • 105 is 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.

Did this answer your question?