Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

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

DZone's Guide to

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

Teams often like to have more than one way to write test cases. Here are several types of test cases, how to write them, and where they fit best.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

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.

Structured-exploratory-testing.png

Who they’re for: Test leads/QA managers who want to give their teams the freedom of the exploratory method while ensuring product coverage.

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

How to Write Them

  • Break down a product into its areas or functions.
  • Divide each area into tasks.
  • Request a pass/fail result for each task.

Because we value the results of exploratory testing (but still want to oversee testing efforts) we use this method often. We call them “task lists” and while pass/fail is the most common input we request from testers, we do have a variety of reporting options built into our platform that we assign ahead of time, including text commentary and multiple choice responses.

pass-fail-reporting-methods.png

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.

 classic-test-cases-expected-result.png

Because these are the densest method we’re describing, be sure to practice your skills at brevity. Include only information that is necessary and progresses the tester forward (otherwise you’ll end up with some lengthy test cases).

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

Typically written in Excel, the valid/invalid format for test cases has the goal of cramming the maximum amount of information in the minimum amount of space by doing away with steps. Instead, QA managers create columns for each data set, tool, or object and rows for each test case. Testers then interpret the information to come up with the logical steps. 

valid-invalid-test-cases.png

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

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

Verify-Using-With-To Test Cases

These simple test cases break down info into easy-to-grasp language.

verify-using-with-to-test-cases.png

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

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

Testable Use Cases

Use cases are often written by those outside of QA, such as business analysts. Use cases capture what a software product does, not how it does it. They aren’t necessarily designed for testing, but they can be modified for testing, providing the benefit of user-centric, strategic testing that is focused on business or product goals.

use-cases-that-can-be-tested.pngWho 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

  • Start with a goal.
  • Write in verb-driven name and description.
  • Write in actors (can be job titles or user titles) and preconditions.
  • 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.
  • Write an end result that reflects what other users or areas (if any) are affected, so they will also be validated by tester.

While some of these methods might stretch your conceptualization of test cases, that’s a good thing. What matters is finding the right format for your project.

Have you tried all of these? I’d be really curious to see where you think they best apply. Let me know in the comments below!

The post "How to Write a Test Case for Your Project and Your Team" appeared first on Testlio.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
devops ,test case ,software testing

Published at DZone with permission of Dayana Stockdale, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}