Introduction
When launching a test with Global App Testing that includes test cases - you will need to provide the test cases. This guide will explain how to write and prepare the test cases for the best possible result.
If at any moment you are not sure on how to prepare test cases for execution with GAT - please speak to your GAT Project Manager.
File type
We accept test cases in most common spreadsheet formats:
Google Spreadsheet
Excel file
CSV file
When making the request, please provide a link to a location on the web where the test cases can be accessed.
Test case structure
Test cases need to have the following properties (columns)
Test case ID (mandatory) - each test case should have a short unique ID. Recommended format: "TC-01", but any short unique string (up to 10 characters) will work fine.
Section (optional) - if you have a large number of test cases it may be useful to group them into sections. Test cases belonging to the same section will be grouped in the UI of the platform.
Name - a short title describing the test case. Up to 255 characters, but it's best to keep it under 48 for easy reference.
Preconditions - a list of conditions that need to be true for the test case results to be valid. Example - the user needs to be logged in. Please note that preconditions should contain instructions, only conditions to verify. If you need the tester to perform certain actions - add them to the steps, not preconditions.
Steps - one or more (not more than 10) steps that give instructions on what the testers should do.
Expected results - for each step (where applicable) you can provide an expected result, what the tester should verify after completing the step. When the expected result does not match the actual result, the test case will be marked as failed.
Additional information required - a list (one per line) of questions which testers will need to provide answers for.
Attachments required - a list of specific requested attachments that need to be provided by the tester.
Unique identification of a test case
It is important for us to be able to identify a test cases within the suite you provide. For this we need to make sure
Working with multiple steps
Test cases most often have more than one steps to execute. There are 2 ways how you can provide multiple steps.
Option 1 - one step per row
You can have a separate row for each step. This will make it easier to match expected results with steps and you don't have to number them.
Multiple rows will be combined to the same test case as steps if the following is true:
The test case ID and name are empty - then the row will be a step in the test case directly above it.
The test case ID and name are the same as in another row - then the row will be added as an additional step to the same test case.
This the format we recommend. It makes test cases easier to maintain and with this format the testers will give you additional information by reporting which individual step failed when a test case fails.
Option 2 - multiple steps in the same cell
You can provide all steps in one row by putting them all in the same cell, one per line, and numbering them.
In this option the expected result column should also contain multiple results numbered the same way as the steps, so that the testers know which expected result matches which step.
How to collect information from testers
If you want testers to provide additional information when completing the test (for example, provide the transaction ID of a purchase they make within the test case) - you can specify that in your test cases.
List the individual items the tester will need to provide in the Additional information required column (one per line). If you have multiple steps in different rows, this information needs to be provided in the first row of the test case.
When completing the test case, the tester will be prompted to provide the requested information, which will then be available for you to see through the platform.
Column names
We don't mind how you name the columns, as long as it's clear what is in what column. So don't worry if your columns are named differently to what is listed above.
Best practices and guides
If you want the best possible result, please follow these best practices when writing or preparing your test cases
How big is too big?
When writing test cases, please bare in mind the recommended size.
A test case should not be longer than 10 steps.
An average test case should take no more than 5 minutes to execute.
If the test cases are significantly bigger than these guidelines we reserve the right to charge more for their execution. If in doubt - please speak to your GAT Project Manager.
The clearer it is - the better results will be
When writing or preparing test cases, please make sure you are providing clear and reasonably easy to follow instructions. Avoid using terminology that can be unfamiliar to our testers.
Maintain the flow of testing
The testers will be asked to execute test cases in order from the first to the last. Try to structure your test cases in such a way, that executing the test cases in order will automatically mean that the testing is completed correctly.
For example, this can include adding a preparation test case at the beginning of the test and ordering the test case in a logical end-to-end testing flow.
Include all instructions in test cases
If a tester needs to do something - please make sure it is reflected in the steps of a test case. Avoid adding instructions in supporting documents. If needed - add test cases that instruct testers on how to prepare for the next section of testing.