How to write test cases for software: examples and tutorial

Having fun writing test cases It may not seem like such an important part of development. But for a software tester to do their job to the best of their ability, they need a clear set of steps to follow and a clear definition of what is being tested.

Everyone from NASA and GE to enterprise-level corporations can benefit from teams that operate at their best. Writing great test cases is just one more way to improve team efficiency and effectiveness, and Parasoft is all about empowering teams to do just that.

In this blog, we cover the following topics related to how to write a test case:

1. What is a test case?
2. test script vs. test case
3. Different types of test cases
4. How to write software test cases
5. Standard test case format
6. Best practices for writing test cases
7. Test Suite vs. Test Plan
8. Test case writing tools

A test case is exactly what it sounds like: a test scenario that measures functionality on a set of actions or conditions to verify the expected result. They apply to any software application, can use manual testing or automated testing , and can make use of test case management tools.

One key thing to remember when it comes to writing test cases is that they are intended to test a basic variable or task, such as whether or not a discount code is applied to the correct product on an e-commerce web page. This allows a software tester more flexibility in how they test code and features.

Test Script vs. Test Case

The difference between test cases and test scripts should also be clarified. A test script is a short program intended to test certain functions. A test case is a document with steps that need to be completed as planned in advance.

Think of test cases as a meticulously planned trip and test scripts to be more like a quick trip to the grocery store.

Different types of test cases

Test cases can measure many different aspects of code. The steps involved may also be intended to induce a failure outcome rather than an expected positive outcome, such as when a user enters the wrong password on a login screen.

Some examples of common test cases would be the following:

Test cases can be applied to any number of functions found in any given software. Some of the most popular include:

• API test example  , See it in action.
• UI test example  , See it in action.
• Unit test example  , See it in action.
• Load and performance test example  , See it in action.
• security test
• SQL queries
• Low-code application testing

An example of a popular test case

Test cases are useful in a variety of software scenarios. Everything from banking to personal software requires a test case application. For example, if the goal is to have sensitive data encrypted, the software must have features that work as intended.

But functional testing is only one aspect of writing a test case. Software testing should vigorously challenge all aspects of the code, from performance to compatibility to security. This is why personal encryption software needs to be tested so thoroughly, especially when it comes to things like web APIs .

How to write software test cases

Test case writing varies depending on what the test case is measuring or testing. This is also a situation where sharing test assets between development and test teams can speed up software testing. But it all starts with knowing how to write a test case effectively and efficiently.

 

Test cases have some integral parts that must always be present in the fields. However, each test case can be broken down into 8 basic steps.

Step 1: Test Case ID

All test cases must carry unique IDs to represent them. In most cases, following a convention for this naming ID helps with organization, clarity, and understanding.

Step 2: Description of the test

This description should detail what unit, feature, or function is being tested or what is being verified.

Step 3: Assumptions and preconditions

This implies that the conditions are met before the execution of the test case. An example would be requiring a valid Outlook account to sign in.

Step 4: Test Data

This relates to the variables and their values ​​in the test case. In the example of an email login, this would be the username and password for the account.

Step 5: Steps to execute

These should be easily repeatable steps executed from the perspective of the end user. For example, a test case for logging into an email server might include these steps:

1. Open the web page of the email server.
2. Introduce your user name.
3. Enter the password.
4. Click the “Enter” or “Login” button.

Step 6: Expected Result

This indicates the expected result after the execution of the test case step. Upon entering the correct login information, the expected result would be a successful login.

Step 7: Actual Result and Postconditions

Compared to the expected result, we can determine the state of the test case. In the case of email login, the user will be logged in successfully or not. The postcondition is what happens as a result of running the step, such as being redirected to the email inbox.

Step 8: Wrong Password

Determining pass/fail status depends on how the expected result and the actual result compare to each other.

Same result = Pass
Different results = Fail

Standard unit test case format

Each part of a well-written unit test will define several core aspects including:

1. Functions performed by the test
2. Data used in the test
3. Expected result of test execution
4. Ensuring that the test was run in isolation from other parts of the code base

It is important to know that the standard format for well-written tests consists of the following parts:

• Meaningful name of the test method
• Controlled or simulated data to be used for testing.
• Method or unit under test (the part of the code we are testing)
• apply an affirmation
• Running the unit test in isolation

 

Is there a test case template?

As mentioned, there is a standard test case format. However, the test case template is likely to vary from company to company and even team to team. Instead, a test case template is the document with a list of test scenarios and subsequent test cases.

Example quality test case

Although test cases will vary depending on the type of test and the general field of testing, building a quality test case boils down to the few reliable elements above. Remember: the test method name must include the method or unit under test and what the expected result is.

It should also be noted that each unit must be tested in isolation. In this case, “isolation” means keeping tests focused as much as possible to run only the part of the application we’re testing.

This example comes from a banking-related test case:

 

With this method name, we know that this is a unit test that is:

• Testing the ‘isOverDrawn()’ method.
• The balance used for the controlled data was 500.
• The expected result is true.

A meaningful method name allows anyone reviewing the results to understand what the unit test was testing. In addition, it indicates the data to be tested, the expected result, and what was tested.

If the test fails, knowing the expected result is critical to facilitating troubleshooting and ensuring no regressions are introduced .

Test case data

The data used must be sufficient to run the test. For unit testing, we want to make it as simple as possible to test the most basic unit of our application. The data can be as simple as creating a string or an object variable for which you can control the data. Or a mock framework can be used for testing if a dependency is not available or you need that dependency to be in a specific state.

Have enough to test that part if it is enough. You do NOT need to configure all parts of the application for the test to run.

All of this affects how the unit test will behave, since this is the data that is used for the unit test execution. As such, this part of unit testing is the most time consuming as it requires some understanding of the code you are testing in order to know what data to use for testing.

Keep it simple by using only the parts necessary for the code being tested. Mocks are very useful in this phase, as they allow you to control how the methods of those objects will behave when interacting with your test.

For example, given the following data:

 

We avoid the “real client class” by using a mock of the “client class” to test isolation. We don’t want to introduce or configure another object for this test, as it adds another layer of maintainability for that object and doesn’t affect the result of the method under test.

The next variable to create is the “starting balance”, something known to your code knowledge. The next line shows the Account object being created along with the mock and Beginning Balance to prepare the method we’re testing with the data we just used.

So, in this example, the account object is set up with the mock customer, since we don’t care about the data in the customer object, and we pass in an initial balance that we can control for our test.

The next line defines the input since the method under test requires a number to be used. We define the “balance” to be used in the method we are testing. The method is then executed and the result of the method is stored in our variable for us to use later.

apply an affirmation

Once the test can complete successfully (because it runs from start to finish with no exceptions or errors), it’s time to apply an assertion to the unit test. Without the assertion, the unit test is meaningless, as there is nothing you enforce to make sure it works as intended.

Collecting the coverage of which lines were executed indicates what was executed, but does not provide enough detail to determine the following:

• Whether the code behaves as expected.
• If the code meets the quality objectives.
• Whether the data returned is the expected data.

An affirmation can be as basic as:

 

As long as the unit test contains an assertion that verifies the result of the method under test, this is a meaningful unit test.

 

By applying the standard unit test format, a team can more easily maintain, read, and/or update tests to easily see where more tests can be applied to the rest of the application.

What are the best practices for writing quality test cases?

The way you write effective tests and test cases can be optimized over time. Some and best practices include the use of strong titles, strong descriptions, and keeping the language concise and clear.

But you’ll also want to include preconditions, assumptions, and expected results. All of this information is relevant to the software tester, especially when determining whether the test case should be a “pass” or a “fail” instead.

A cheat sheet for creating test cases that work well is as follows:

• Keep things simple and transparent.
• Make test cases reusable.
• Keep test case IDs unique.
• Peer review is important.
• Test cases must take into account the end user or defined requirements.
• Specify the expected results and assumptions.

Simple, unique, specific, open to feedback, and focused on reuse – that’s the way to a great test case. For a more visual look at how to write a quality test case, check out Parasoft’s webinar on the topic.

Test Suite vs. Test Plan

The other aspect of a test case involves test suites and test plans. These differ in key ways and both are vital for accurate test case development.

A test suite comes into play for test cases in terms of the source code, the collection of dependencies, or the suite of tests to be performed on the code. Test suites allow you to categorize test cases in a way that aligns with any analysis or planning need.

This means that the main functions of the software can have their own set of tests, while another set of tests is for a specific type of test, such as smoke or security. Think of test suites as a shelf to organize your test cases.

What is a test plan?

Rather, a test plan is more like the umbrella that covers all test suites. If the test cases are books and the test suites are bookshelves, the test plans are the room that contains the bookshelf.

Test plans are generally set up in terms of manual tests, automated tests, and a general format of how to perform the tests. They will test the software from the ground up using test suites and test cases before implementing changes or adding new features.

Best Test Case Writing Tools

Parasoft generally develops its tools and suites with the “George Jetson” theory in mind. In other words, we want our clients to be able to “press a button” and have everything well taken care of. While this is not totally realistic, tools that have this focus on automation are the best to use when it comes to writing test cases.

Not only can they help with automation, but they can also help from the very beginning of development. After all, it’s very easy to get bogged down in little details or features. One might forget that the software just has to work first. That’s where a Java unit testing tool like Parasoft Jtest comes in.

This tool allows both beginners and experts to improve their unit testing skills faster as well as unit testing experience. After establishing a foundation, it runs the unit tests and then guides the user to ensure the tests are meaningful. When you can understand the kinds of things to look for in a test, test case writing becomes less intimidating.