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. Who they’re for: Test leads/QA managers who want to give their teams the freedom of the exploratory testing 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. 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. 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. 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. 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. 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: 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. Testlio can help – schedule a free demo today.