Ready to write functional test cases that testers can action on and that, combined, thoroughly cover the product?
Functional test cases are what QA managers write in order to assign testing for functional requirements to others on the team.
Think of a test case like a task. A functional test case assigns the testing of a function or feature in order to see if it produces the expected result.
Every new feature and function must be tested before release, and most need to be continuously tested.
For example, you might test a photo upload feature. When you add a photo, does it get added to the digital asset library? When you add a tag to that photo, does it get saved in the photo’s metadata? When you later search that tag, does the photo you added to the tag appear in the digital asset library’s search results?
Inexperienced testers might assume that testing features is the only kind of testing that exists, but QA pros know that there are many other types of testing such as performance, usability, and scalability. As a refresher, here’s how functional testing differs from nonfunctional testing.
Learn more about our expert, fully managed functional testing.
Steps for writing functional test cases
Now that we understand what functional test cases are, let’s look at what they include and how to write them.
A functional test case should have these features:
- Description or name of the function or feature
- Preconditions for being able to test it (such as being logged in as a user with a certain access level or paid subscription plan)
- The steps required to test it
- The expected result
When all of this is included, the tester has everything they need to satisfy the requirement of the test case. In the description section, you can also write the location of the function, if the app is very large and complex with many different feature areas, or if the same function exists in different feature areas.
These are the steps you should follow when writing functional test cases:
1. Determine what areas need to be covered
The first step is to take a bird’s eye view of the testing project and consider what needs to be tested. Talk with product leaders to learn more about the new updates or features being released, and understand the depth and breadth of the testing required.
2. Working in a doc or spreadsheet, list all functions and features
Now it’s time to get into the details. Start listing all of the functions and features that need to be included in the testing round.
Go from memory on what you know of the product, include the new features that have been described to you, and also login and play around with the app to recall any additional functionality in those product areas.
3. Explore the product to determine if any tests can be separated or combined
The next step is to consider your list against the actual product. As you explore the product, decide whether or not test cases could be combined (such as download as a PNG and as a JPG) or if you need to break up one concept into multiple test cases (such as upload a photo, add a photo tag, search a photo tag).
4. Write each individual test case
Now it’s time to write the test cases inside of your test management tool. This tool should be designed for managing testing and/or development tasks, so that you can input the information needed on the test case, assign it to a tester, and allow them to connect this test case to a bug report if needed.
Use this as a template for what to include:
- Expected result
5. Assign the test cases to testers
There is some strategy required when assigning test cases to testers. You don’t want to do it at random, otherwise, testers will all have to be in different parts of the app instead of dividing and conquering.
Divide the number of test cases by the number of testers to know approximately how many test cases each person should have. Let’s say that number is 20. Look at your overall list of test cases and methodically choose 20 cases for one tester at a time.
Group the test cases by:
- User type
- Access type
- Product area
- Feature release
For important features and brand new releases, make sure to have some overlap, so that two or more testers are assigned to the same case.
6. Create and assign any exploratory test prompts as well
In addition to pre-defined test cases that ensure excellent product coverage, you should include exploratory tests, which allow testers to use the app more naturally, as a real user would.
Write some prompts, such as “Edit a video with captions, subtitles, and an intro slide” or “Manually add a new lead to the CRM” and allow testers to fulfill that demand using any steps they require. They can then submit bug reports for any issues encountered along the way.
Examples of functional test cases
Here are some examples of functional test cases to help solidify what we’ve learned.
Example 1) Assign a new task
Description: Add a new task and assign it to a user.
Preconditions: The user getting assigned should have email notifications turned on.
1– Create two user profiles with email addresses.
2– Using one of the accounts, create a new task.
3– Assign that task to your other user account.
Expected result: The user should receive an email notification that they have been assigned to a task.
Example 2) Download as JPG
Description: Download your design as a JPG file.
Preconditions: You should have added one item to the blank canvas and be logged in as a paying user.
1– Login as a paying user.
2– Open a new canvas and add one headline or icon.
3– Download the image as JPG.
Expected result: You should be given 3 options for file size and resolution and then the file should download according to what you select.
Example 3) Email reminder
Description: Notification to follow up via email with someone who doesn’t respond.
Preconditions: You are signed in as a user with a Pro plan.
1– Login as a user with a Pro plan.
2– Send an email to a test lead and select to send notification if no reply within 1 day.
3– Wait 1 day to receive the bell notification in your inbox.
Expected result: You will receive a bell notification in your email inbox.
How to ensure that your functional test cases cover the product area
Most likely, you need to do some form of regression testing in order to cover areas of the product that could be affected by any of the new updates or product releases you’re testing.
That’s why, aside from the core feature or functionality you’re responsible for testing, you should also list out areas that may be affected by this function as well as any product areas that are prone to breakage due to a high volume of usage or code complexity.
Plan your test cycles over at least two or three days, so that you can study test coverage with fresh eyes. Always open the app while strategizing and writing test cases so you can be sure you’re not missing a function or feature you would have forgotten without actually looking at the app.