Request info

How to Write a Test Case for Your Project and Your Team

Every team and organization has its protocols. There is no one way that teaches indisputably how to write a test case.
The writing comes down to the project and the team. Actually, QA managers are wise to have a few different methods they can turn to, allowing for the fluid application of the test case format that truly fits.
To that end, here are five different methods with examples, explanations, writing tips, and project pairings.

But first, a quick overview: test cases break down an app or web page into one test at a time. They can be used for an entire test cycle or only for certain functions. While they typically direct testers, they can also be written more loosely.

Structured exploratory test cases

These test cases are as brief as can be. They are “high-level” considerations within each feature or area of a product.

Fail pass structured exploratory testing.

Where they fit: Products with uncomplicated steps and actions and/or testing cycles where user-centric exploration is desired

How to write them:

  1. Break down a product into its areas or functions
  2. Divide each area into tasks
  3. Request a pass/fail result for each task
Pass fail reporting methods

Classic test cases

While there’s no set one way to do it, the format for test cases that most quickly comes to mind for many in the QA world includes a name, description, preconditions, and steps with a final expected result.

Who they’re for: Test leads/QA managers who need to tightly manage a testing team, whether for time or project restrictions.

Where they fit: Critical functions of an app—anything that requires clear, perfect testing.

How to write them:

  • Identify a critical function to test
  • Name it and describe it clearly using verbs where possible
  • Break the test down into no more than 8 directive steps
  • Describe the expected result
  • Depending on how/where your testers report, add field for “actual result,” “pass/fail,” and “comments”

Valid/invalid test cases

Valid or invalid test cases

Who they’re for: QA managers with an experienced team who will benefit from the use of quick validation exercises over potentially lengthy test cases

Where they fit: big complex projects with multiple steps and multiple pre-conditions for each test case

How to write them:

  1. Strategize which test cases to cover in each sheet (by area or function)
  2. Write the headings for your columns—ID, scenario, action, the tools and data types that fit the project, and finally the expected result
  3. In rows, create the initial scenarios, such as login, logout, forgot password, and the base critical functions
  4. Add more column headings as you go along (new scenarios will make you think of more)
  5. For each scenario row, mark whether the data or tool is valid, invalid, or non-applicable

Verify-using-with-to test cases

Simplified test case brakdown verify-using-with-to

Who they’re for: QA managers assigning projects to beginning testers or employees in other roles who are temporarily filling in as testers OR QA managers looking for another way to structure exploratory tests

Where they fit: Projects of any size and nature—this test case style is more about language (either not scaring away new testers or providing exploratory freedom to experienced testers by leaving out specific steps)

How to write them:

  1. Start with one action
  2. “Verify” serves as both the name and description of the test
  3. “Using” is the tools and data that the tester will use
  4. “With” is a list of any necessary preconditions or givens
  5. “To” is the expected result

Testable use cases

Who they’re for: QA managers that want to get a jump start on writing test cases before the product code is even finished and/or who want to structure exploratory testing with not just user personas (AKA user stories) but with more specific user goals

Where they fit: large, complex projects whose end goals can have multiple pathways, typically enterprise software

How to write them:

  1. Start with a goal
  2. Write in verb-driven name and description
  3. Write in actors (can be job titles or user titles) and preconditions
  4. Write flows NOT STEPS—meaning keep the flow technology-neutral by not directing the tester, but instead writing in terms of the user and the system
  5. Write an end result that reflects what other users or areas (if any) are affected, so they will also be validated by tester
Jumbotron image