Skip to main content

Test Cases format for GAT

How to write and prepare test cases for running them with GAT.

K
Written by Karol Topolski
Updated over 2 weeks ago

Introduction

When launching a test with Global App Testing that includes test cases, you will need to provide the test cases. This guide explains how to write and prepare them for the best possible results.

If at any moment you are not sure how to prepare test cases for execution with GAT, please speak to your GAT Project Manager.

Import options & file types

We support three ways to import your test cases into the platform:

  1. Live connection with Google Spreadsheet – sync test cases directly.

  2. CSV file upload – supports multiple common file types (e.g., .csv, .xlsx, .xls).

  3. Integration with Zephyr Squad or Zephyr Scale – import directly from your test management system.
    ​

Test case structure

Each test case should contain the following columns:

  • Test case ID (mandatory) – A short, unique ID (e.g., TC-01).

  • Section (optional) – Useful for grouping test cases into logical sections.

  • Name – A short, clear title (recommended under 48 characters).

  • Preconditions – Conditions that must be true before execution (e.g., “User is logged in”).

  • Steps – One or more steps describing what the tester should do.

  • Expected results – What the tester should see or verify after completing each step.

  • Additional information (optional) – Any specific attachments the tester should provide.
    ​
    ​

Unique identification of a test case

Each test case must have a unique and consistent ID and name. If two test cases share the same ID but have different titles, the platform will alert you and prompt a fix before import.

Working with multiple steps

Option 1 – One step per row

  • Each row represents a single step with its corresponding expected result.

  • If the Test case ID and Name are left empty, the row is treated as a continuation of the test case above.

  • If the Test case ID and Name match a previous row, the step is added to that test case.

  • This format provides clearer reporting, as testers can indicate exactly which step failed.
    ​

👉 Important: One step with one expected result ensures that each expected outcome receives its own pass/fail status.

Option 2 – Multiple steps in one cell

  • All steps can be placed in the same cell (one per line, numbered).

  • The expected results must also be listed and numbered accordingly.

  • In this option, one pass/fail result is applied to the entire set of steps.
    ​

👉 Note: Even if steps are combined, the 10 steps + 10 expected results rule still applies. It's worth mentioning that one step should not involve multiple actions; for example, if one step involves buying a product, that would translate to several actions, and we advise considering this when writing them.

Best practices and guidelines

⏱️ Size and execution time

  • A test case should have no more than 10 steps.

  • An average test case should take no more than 3 minutes to execute.

  • If execution takes longer, consider splitting it into separate test cases to keep focus clear and improve accuracy.
    ​

🧭 Clarity

  • Provide clear, simple instructions.

  • Avoid terminology unfamiliar to testers.

  • Ensure instructions are self-contained within the test case (not in separate documents).
    ​

🔄 Flow of testing

  • Testers execute test cases in order.

  • Structure test cases logically so that running them in sequence reflects the correct testing flow.

  • Consider adding a preparation test case at the start of the suite if needed.
    ​

✅ Summary

  • One expected result per step = one clear pass/fail.

  • Keep test cases under 10 steps and 5 minutes to execute.

  • Use one of three supported import options: Google Spreadsheet, CSV upload (multi-file), or Zephyr Squad/Scale integration.

  • Clear, structured test cases lead to faster, more accurate execution and better results.

Did this answer your question?