How to Write Functional Test Cases for Thorough Coverage

Ready to learn how to write functional test cases that testers can action on and that, combined, thoroughly cover the product?

Broadly, functional software testing is defined as a type of black-box testing method that focuses on the functionality of a software product. Functional testing is designed to ensure a web or mobile software application meets its requirements and specifications by executing test cases from the user’s perspective. 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 smoke testing, exploratory testing, performance testing, and usability testing. As a refresher, here’s how functional testing differs from nonfunctional testing.

4 Differences Between Functional Testing vs. Nonfunctional Testing

Learn more about our expert, fully managed functional testing.

Types of Functional Testing

There are several functional testing types, each targeting different aspects and stages of the software lifecycle.

Unit Testing

Unit testing focuses on the smallest testable parts of an application, such as functions, methods, or classes, and serves as the first line of defense against errors. The goal of unit testing is to catch bugs early in the software development cycle before they escalate into more expensive, complex problems. 

To ensure unit tests are thorough, developers employ various testing techniques, including: 

• Statement Coverage: Ensures all executable statements in the source code are run at least once
• Branch Coverage: Ensures each possible outcome from every decision point is executed
• Decision Coverage: Ensures every condition affecting a decision is tested

Regression Testing 

In software development, whenever something new is implemented—new features, updates, or bug fixes—there’s a chance something will break. This is exactly what regression testing aims to avoid. It ensures new code changes don’t introduce new defects or impact existing software functionality. 

Integration Testing

Individual application modules may function optimally on their own. However, issues may arise when integrated with other components. Integration testing assesses the compatibility of these different modules, their communication with each other, and whether data flows seamlessly between them.  

It’s particularly necessary for complex applications such as banking apps, which often rely on interconnected components and third-party tools. 

Integration testing strategies include:

• Incremental Testing: Modules are integrated one by one, and testing happens with each addition. The goal is to identify which specific integration causes issues.
• Top-Down Integration Testing: Top-level modules are first tested, followed by lower-level ones. This approach helps identify issues with the application’s major functions early in the process.
• Bottom-Up Integration Testing: In contrast to the top-down approach, this testing technique first evaluates the lowest or innermost modules and then works its way up. It enables teams to test the application’s fundamental or core components early on.
• Hybrid (or Sandwich) Integration Testing: Hybrid testing combines both top-down and bottom-up testing strategies. It’s especially useful for complex applications like operating systems or large e-commerce platforms.

Sanity Testing

Sanity testing is a subset of regression testing, and it’s quick and non-exhaustive. It ensures changes to the software build are working as expected and do not negatively impact the application’s major functionalities. A sanity test typically happens after smoke testing has been completed.

It’s conducted on new builds with minor fixes or functional improvements and serves as a checkpoint to determine if the software build should be passed on for further, more detailed testing.

Smoke Testing

Smoke testing is a quick, preliminary test that ensures the critical functionalities of a new build are working properly. Much like a gatekeeper, it determines whether a build is stable enough to undergo the next level of testing.

Smoke testing and sanity testing are both basic checks that assess a product’s readiness for further testing, but there are some key differences. Sanity testing ensures that specific functions are working properly after changes, while smoke testing evaluates the overall stability of a build.

How To Write 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. 

This is our step-by-step guide 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 manual 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:

• Description
• Preconditions
• Steps
• 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. 

Three Examples of Functional Test Cases

Here are some examples of functional test cases to help solidify what we’ve learned. 

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.
Steps:
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.

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.
Steps:
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. 

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.
Steps:
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.

Functional Test Case Writing Best Practices 

Writing functional test cases—like the functional testing examples outlined above—is critical to ensuring your application meets requirements. Some best practices to keep in mind:

Prioritize the Right Test Cases

Testing takes time and resources, so prioritize test cases based on importance or impact on critical functionalities—for example, the payment processing aspect of an e-commerce site. This way, they get the attention they deserve and you can allocate time and resources accordingly. 

Create Reusable Test Cases

Test case preparation can be time-consuming. Design reusable test cases that you can customize for multiple scenarios. Create test case templates that cover all the essential elements but can also be adapted to accommodate various features and functionalities. This streamlines the testing process and ensures accuracy and consistency across all tests.

Review and Update Regularly

Software within Agile development frameworks requires constant iteration and testing. This means test cases should accurately represent the current state of the software and align with the latest software changes. Up-to-date test cases should provide clear and relevant information during testing and help teams identify areas for improvement. 

It’s important, therefore, that you regularly review and update test cases, incorporating product updates or new requirements as needed.

Incorporate Peer Feedback

“Two heads are better than one,” like that old adage used to say. When creating test cases, enlist the help of a team member to function as another set of eyes and peer reviewer of your work. Collecting real-time feedback and tester input can help you uncover oversights and optimize the application from the end user’s perspective.

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. Be open to re-evaluating processes, which can improve outcomes and reduce software testing costs. 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.

Looking for more insights? Read The Ultimate Guide to Functional Testing.