Test cases define what you're testing, how to test it, and what the expected outcome should be.
Overview
A test case is the fundamental unit in Qase. Each one captures a testing scenario — the steps to execute, the data to use, and the result you expect. Test cases live inside test suites, which give them structure, and get executed through test runs, which give them results.
Every test case receives an auto-generated identifier combining the project code and a sequence number (e.g., DEMO-42). Use this identifier to search, reference, and trace cases across runs and defects.
Creating test cases
Quick creation
The fastest path: click + Create quick test inside any suite row in the repository. Type a title, press Enter, and you have a case. This is useful for brainstorming coverage — capture the scenario now, fill in details later.
Detailed creation
Click + Case above the suite tree to open the full creation form. This gives you access to every field, step definition, and attachment option before saving. Use this when you're writing cases that will go straight into a test run.
After saving, you can:
Save and create another to keep building out a suite
Send to review to route the case through your team's review process
Test case fields
System fields
Field | Purpose |
Title | The scenario name — make it descriptive enough to understand without opening the case |
Status | Active, Draft, or Deprecated. Draft cases won't appear in plan selection by default |
Description | Additional context, background, or scope for the scenario |
Suite | Which test suite this case belongs to |
Severity | Trivial, Minor, Normal, Major, Critical, or Blocker |
Priority | Low, Medium, or High |
Type | The testing type — functional, regression, smoke, etc. |
Layer | End-to-end, API, or Unit |
Is Flaky | Marks unstable tests so your team can track and address them |
Milestone | Links the case to a release milestone |
Behavior | Destructive, Negative, or Positive |
Automation Status | Manual or Automated |
To be automated | Checkbox for manual cases earmarked for future automation |
Muted | Muted cases still run but won't affect the overall run status — useful for known-flaky tests |
System fields can be toggled on or off per-project from the Configure fields button in your workspace's Fields settings. You can also create custom fields with different data types to capture information specific to your team's workflow.
Conditions
Pre-conditions describe what must be true before executing the case (e.g., "User is logged in with admin role"). Post-conditions describe cleanup or verification steps after execution. These appear as dedicated sections in the case form.
Steps
Steps define the execution sequence. Qase supports two formats:
Classic steps — Each step has three parts:
Action: What to do
Data: Input values or test data for this step
Expected result: What should happen
Gherkin steps — Write steps in Given/When/Then syntax for teams using BDD.
Steps support nesting (child steps under a parent) for complex multi-part actions. You can also insert shared steps — reusable step sequences maintained in one place and referenced across multiple cases.
Attachments
Upload images, screenshots, videos, or documents directly to a case for additional context. Maximum file size is 128 MB per attachment.
Parameters
Parameterized cases run multiple times during a test run — once per parameter combination. Add parameters with multiple values, and Qase automatically creates separate run instances for each combination.
Tags
Tags are lightweight, workspace-level labels you can apply to test cases, defects, and test runs. Unlike structured fields like severity or priority, tags are freeform — create them on the fly to categorize work in whatever way makes sense for your team (e.g., login, regression-candidate, sprint-12, payments).
Once created, a tag is available across all projects in your workspace.
Creating tags
You can create tags in several places:
From a test case — while creating or editing a case, type a new tag name in the Tags field and confirm
From a test run — add tags during run creation or editing
From a defect — apply tags when filing a defect manually
From Workspace settings — go to Workspace → Tags to pre-create tags before they're needed
When typing a tag name, Qase shows existing tags as suggestions. Select one to reuse it, or finish typing to create a new one.
Bulk editing tags
You can manage tags across multiple test cases at once from the repository view:
Select the cases you want to update
Use the bulk edit action to add or remove tags
To replace tags, remove the old ones first, then add new ones. Your case selection is preserved between operations, so you don't need to re-select.
Workspace tag management
Workspace admins can manage all tags from Workspace → Tags. This view shows every tag in the workspace with the count of entities it's applied to. From here you can:
Search for tags by name
Filter tags to find specific ones
Delete tags in bulk to clean up unused or duplicate labels
We recommend periodic tag cleanup — tags are easy to create, which means they accumulate fast. A monthly review of the Tags workspace page helps keep them useful.
Editing and bulk operations
Quick editing
Click any test case in the repository to open its preview sidebar. All properties — including steps, description, and conditions — are editable directly from this preview without opening the full form.
Bulk actions
Select multiple cases using the checkboxes in the repository view to:
Edit properties across all selected cases (severity, priority, tags, milestone, etc.)
Start an express test run with just the selected cases
Delete cases in bulk — if delete confirmation is enabled in project settings, you'll need to type
CONFIRMto proceed
Searching and filtering
Use the search box above the repository to find cases by title, ID (DEMO-42), suite name, or field content. Apply filters to narrow by severity, priority, automation status, tags, or any other field — filters combine with AND logic.
FAQ
Can I restore a deleted test case?
Yes. Deleted cases go to the Trash Bin, accessible from the three-dot menu in the repository. You can restore them from there.
How do test case IDs work?
Each case gets a unique ID combining the project code and a sequential number (e.g., DEMO-9). IDs are permanent — they don't change if you move a case between suites. Use the full ID (with project code prefix) when searching.
What's the difference between severity and priority?
Severity describes the technical impact of a failure (how bad is it?). Priority describes when it should be addressed (how urgent is it?). A cosmetic typo on the login page might be Minor severity but High priority if it's customer-facing.
Should I use Classic or Gherkin steps?
Use Gherkin if your team practices BDD and wants steps aligned with feature files. Use Classic for everything else — it's more flexible and doesn't require a specific syntax. You can set the default step type per project in project settings.
Do tags sync across projects?
Yes. Tags are workspace-level. A tag created in one project is immediately available in every other project, and in defects and test runs as well.