Test Cases
Test Case is a set of testing procedures, necessary inputs, execution conditions, and expected results that define a single test that needs to be executed successfully to achieve a testing objective. In Qase, Test Cases are exactly that - you can define various parameters and expected outcomes of a particular testing scenario. Let's get into creating a new Test Case.
There are a couple of ways to create a new Test Case. First is a "quick create": hit a button "+ Create case" in a Suite where you want it to be added, give your new Test Case a title - and that's it; other case details can be added later:
The second method allows you to fill out your new Test Case in full detail. Start by hitting the "+ Case" button above the Suite structure of the repository:
You are prompted to configure your new Test Case and provide all information about it that should be considered.
Test Case parameters and properties are divided into several sections:
- Basic: here, you will define the following Test Case properties:
-
- Title: define the name of a test case
- Status: can be either Active, Draft, or Deprecated
- Description: additional details for more context about a test case
- Suite: choose here which Test Suite your new case belongs to
- Severity: can be either Trivial, Minor, Normal, Major, Critical, Blocker, or Not Set
- Priority: can be either Low, Medium, High, or Not Set
- Type: select what type of testing is applicable for your test case
- Layer: pick a layer of the test case, whether it's an end-to-end, API, or a unit test
- Is flaky: if a test case is unstable, you can mark it as flaky
- Milestone: select whether a test case is related to one of your Milestones, which you can create separately
- Behavior: can be either Destructive, Negative, Positive, or Not Set
- Automation Status: you can choose from Automated, To Be Automated, or Not Automated
NB: default fields can be optionally switched on and off via the "Configure fields" button:
-
- Conditions: in this section, you can specify what should have taken place before the Test Case can be performed (Pre-conditions) and what actions should be performed after the Test Case has been performed (Post-conditions).
- Custom Fields: it is impossible to predict what kind of unique parameters or properties your Test Case will require, which is where Custom Fields can help you. You can create your own Custom Fields of various data types to store any additional information about your test cases that are not covered by default properties. If you do not yet have any Custom Fields created, you won't see this section in the Test Case configuration.
- Attachments: upload images, screenshots, video snippets, or other documents to your Test Case to add clarity or provide extra context.
- Params: you can configure your test case to be parametrized and to be performed during a test run in several iterations, depending on how many parameter values you define for it:
After you add such parametrized case to a test run, there will be several instances of it added to the run, each representing a specific param value: -
Steps to reproduce: there are two types of steps in Qase - Classic (consist of "Action", "Input Data" & "Expected Result" fields) and Gherkin (which can be represented in Raw or Steps formats). You can choose which type should be used as a default one when adding new steps in the Project Settings:
- Classic Steps consist of mandatory Action field, and optional Input Data and Expected Result fields:
Additionally, you can attach files, convert a classic step into a Shared Step, clone it or delete it using the controllers: - Gherkin steps:
- In Raw format, a Gherkin step is simply a field to insert Gherkin steps, the Gherkin syntax keywords will be highlighted:
- In Steps format, you can add each line separately and select keywords from a dropdown:
- In Raw format, a Gherkin step is simply a field to insert Gherkin steps, the Gherkin syntax keywords will be highlighted:
- Classic Steps consist of mandatory Action field, and optional Input Data and Expected Result fields:
NB: Classic steps can be converted into Gherkin and vice versa, but when converting an existing test case with Classic steps into Gherkin steps, partial data lost will be experienced:
- all shared steps will be transformed into regular steps
- all attachments to the steps will be lost
- if the steps fields data was in the markdown format, some formatting may be lost or enveloped in special symbols and/or tags
- comments and statuses of the steps will be lost
NB: Gherkin steps currently support only the following syntax keywords:
- Given
- When
- Then
- And
- But
Once you have filled in all the information about your Test Case, you can either:
- Send it to review: in this case, a new Test Case Review request will be created, and a person responsible for reviews will then give their decision on a submitted Test Case.
- Save your Test Case
- Save and create another
- Cancel: exit Test Case creation; your changes will not be saved.
Once the Test Case is saved, you will now see it appear in your Repository structure in relation to Test Suites and other Test Cases. Your Test Case will get an automatically assigned code, consisting of Project Code and a number (for example, "MR-1", where "MR" stands for project code and "1" tells this is the first Test Case in this Project):
If you click a Test Case in Repository view, a sidebar will open up on the right side of the screen, where you will be able to see your Test Case properties, as well as Edit, Clone, or Delete it:
If you have deleted a Test Case, it will reside in Trash Bin (Test Suites are deleted permanently):
From the Trash Bin, you can restore a previously deleted Test Case:
When in Repository view, you can apply Filters to find Test Cases with specific parameters:
In an example below, there are two filters applied - Cases that are of Blocker severity and that are automated:
To look up a test case by name, you can use the search box - simply start typing the name of a test case, and you will be shown matching test cases:
Once you have selected multiple Test Cases, you can perform bulk edits. Check the boxes of several Test Cases to:
- edit multiple cases' properties:
- perform an Express Test Run of selected Test Cases:
- delete Test Cases in bulk; when attempting to delete multiple Cases, you have to type "CONFIRM" into the field in order to prevent accidental deletion:
Import and Export Test Cases
Import: you don't necessarily have to create Test Cases from scratch if you already have them stored elsewhere - hit the "Import" button and bring your existing cases into Qase:
In the "Import" menu, follow the steps:
- Download samples of files that can be imported to get familiar with the format:
- Choose the source type of your imported Test Cases:
- Pick if Test Cases should be imported into an existing Suite:
- Choose a file that contains test cases:
- Opt to replace test cases if there're matches found among existing test cases or import test cases regardless of matching names:
- Confirm importing the file by hitting the "Import" button.
Export: if you need to export your existing test cases elsewhere or prefer to have a backup copy stored locally, you can export your repository:
- Choose which format you need your export to be in:
- Choose a Test Suite if you only want Test Cases from a specific Test Suite to be exported (if you don't select any Suite - "Not Selected" option - all Test Cases will be exported):
- Confirm with the "Export" button - and your file will start downloading.
Comments
0 comments
Please sign in to leave a comment.