Test Cases

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: this section defines which actions should be taken while running a test case and the expected results for each step. For example, if I want to test my software module that provides GPS for connectivity, I'll need to explain which action is needed to be performed and what will be an expected result:
  
  
  Test Case can consist of several steps that need to be performed; for every new step, hit the "+ Add Step" button on the bottom.
  
  If you have Steps that will apply to several Test Cases of a Project and will have matching properties everywhere across the board, you can save yourself lots of manual labor by creating Shared Steps. Once you have at least one Shared Step created, you will see a button "+ Add Shared Step" available:
  
  
  When configuring a Case Step, you can customize it using the buttons to the top-right from the "Expected result" field:
  
  
  • Add Input Data: this button creates an extra field for you to provide information that will be necessary to perform a step (login, password, specific command, etc.)
    
  • Add Attachment: a Test Step can have files attached to it, too, which are independent of the entire Test Case attachment and only pertain to a Test Step in question:
    
  • Create Shared Step: you can create a Shared Step from a Step you are currently configuring if you anticipate that this step will be frequently re-used across the entire Project:
    
  • Clone Step: if your next step is going to need only minor changes, you can avoid composing it from scratch by cloning an existing step and making minor edits to a cloned copy:
    
  • Delete Step: remove a Step from your Test Case if it is no longer necessary:
    
  • Move Up / Move Down: once you have multiple Steps in a single Test Case, you can change the order they should be performed in by hovering over the digit to the left of step Action and dragging the step to a different desired position:
    
    
    

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.