During testing, a QA engineer faces lots of documentation and different kinds of artifacts. Checklists, test suits, test scenarios, test plans, test reports, test analysis – these are just some items on the list of documentation a QA engineer should be able to interact with and create. Today, we will tell you about one of those significant artifacts – manual test cases.
A Test Case: Definition and Purpose.
A test case is a set of actions executed to verify a particular feature or functionality of your software application.
The purpose of a test case is to verify that a certain feature works as expected, to confirm that the functionality, UI/UX, and other parameters of a system satisfy all the related standards, guidelines, and customer requirements.
Differences Between a Test Case and a Checklist
We use test cases on complicated projects, for example, where human life depends on system behavior. These projects may be in the sphere of fire alarms, health care, finance, etc. Here you need to test very carefully and thoroughly.
A QA checklist is a to-do list for controlling the accuracy of testing processes.
Usually, there is no need for test cases when you work with simple systems – websites, mobile apps, etc. Often, there are only one or two QA engineers in the team who know their product. The time spent creating and maintaining test cases will never pay off. In this case, creating a checklist with features to test is usually a more rational decision.
Positive, Negative, and Destructive Test Cases
Positive test cases use valid inputs to verify that a software product is doing what it’s supposed to do. The purpose is to make sure the system doesn’t spit out errors when it’s not supposed to. In general, positive testing ensures that the system meets the requirements under positive scenarios in day-to-day use. For example, if a password field should accept ten characters, a user can create such a password.
Negative test cases use invalid inputs and verify that the software is not doing what it is not supposed to do. Negative testing intends to ensure that the system validates against invalid inputs by throwing errors or otherwise not allowing the system to perform in a certain way. Back to our example, a user shouldn’t be able to create a password that consists of 11 characters.
Destructive test cases are created to learn what the system can handle until it breaks or “destructs.” Load testing and script injections are common approaches to destructive testing. QA engineers can use one of the following techniques:
- applying a significant load to the system that results in a failure;
- injecting JavaScript into a web form with malicious intent;
- fast-clicking in an attempt to break a webpage, etc.
Attributes of a Manual Test Case
Just like all the testing artifacts, a test case has a specific format and features the following attributes:
- ID – a unique combination of letters and numbers.
- Summary – the main idea of a test case, a brief description of its contents. For example, a manual test case for login page can look like this: “Check customer login with valid data.”
- Preconditions – a list of actions to perform before executing a test case. The credentials can be also included if needed.
- Steps – a description of the actions required for verification.
- Postconditions – a list of actions that return the system to its original state (if needed).
- Expected result – what we expect after successful test case execution.
- Actual result – what we get after test case execution (if needed).
- Status – Success, Failed, Blocked (if needed).
Also, some extra attributes may be necessary for some test cases:
- Environmental needs – special hardware, software, facilities, etc. required for the execution of the test case and not listed in the associated test design specification.
- Special procedural requirements – special setup, execution, or cleanup procedures unique to this test case.
- Intercase dependencies – test cases to execute before this test case.
Properties of a Good Test Case
First of all, a test case shouldn’t be dependent, related, or linked to other test cases. This artifact should be complete and self-sufficient. You should also avoid vague explanations of steps or expected results. Any constraints, lack of necessary information, or excessive details make test cases less efficient.
In short, a test case should be:
- easy to understand and execute for all team members;
- accurate;
- easy to trace as per requirements;
- repeatable;
- reusable.
Best Practices of Test Case Writing
When talking about best practices, we imply the rules that help create simple, understandable, and useful test cases:
- Before starting a new test case, make sure it won’t be duplicating any of those already existing in the system.
- Be sure that a test case covers 100% of the requirements you are to verify.
- Keep in mind the theory of testing techniques, such as Boundary Value Analysis, Equivalence Partition, State Transition Technique, Error Guessing Technique, etc.
- Besides addressing system requirements, always remember about an end-user who will interact with the system.
- Remember to include the credentials if they are necessary for test execution.
- Take care of QA engineers who will work with this test case in the future. In particular, make sure all the links are correct and clickable. Please, don’t use links to prod.
- Use the imperative mood, for example: go to the homepage, enter data, click on this, etc. Such wording makes it easier to understand the test steps and execute them faster.
How to Write Better Test Cases: Formatting
Usually, QA engineers use Excel sheets to write manual test cases. Also, you can use test management tools, like TestRail, for creating and maintaining the test cases. Below, you may find an example of a manual test case.
How to Write Test Cases in Manual Testing: Examples
Positive Test Case
Let’s try to create our own manual test case of search functionality for an e-commerce website named FootWear. We’ll start with a positive test case.
ID: FWSF-1 (It’s best to use numbers in ascending order. FWSF = FootWear Search Functionality. Try to come up with a combination of letters that relates to the project or functionality you’re going to test).
Summary: Check search results with a valid input (we can learn what values are valid in requirements).
Pre-conditions: To have pre-configured products from different categories displayed on the website (To test the functionality, we need to have items available for search. You can configure this in the Admin panel or Database).
Steps to reproduce:
- Open the Homepage (the link is not obligatory, it can make the test case more difficult to maintain in the future).
- Enter a keyword related to an available product name into the search field.
- Perform the search by clicking on the search icon or pressing Enter.
- Check the results.
Expected result: All the relevant results are displayed on the Search Results page.
Destructive Test Case
Here is one more example – a destructive test case.
ID: FWSF-2.
Summary: Check the search sustainability to SQL injections.
Pre-conditions: Prepare an SQL query you’re going to inject into the search query.
Steps to reproduce:
- Open the Homepage.
- Enter an SQL query into the search field.
- Perform the search by clicking on the search icon or pressing Enter.
- Check whether the results are displayed correctly without error messages on the search results page.
Expected result: Displaying of warning messages should be disabled to protect from SQL injections.
Negative Test Case
Finally, here’s a negative test case.
ID: FWSF-3.
Summary: Check input for the invalid values.
Pre-conditions: Note invalid values for the search input field from the system requirements.
Steps to reproduce:
- Open the Homepage.
- Enter the combination of invalid values into the search field.
- Perform the search by clicking on the search icon or pressing Enter.
- Check whether the warning message Please use only valid characters is displayed.
Expected result: The warning message Please use only valid characters is displayed. It is possible to proceed with the search.
To Sum Up: Testing Your Test Case
Today, we’ve explained the basics of test case writing. Here’s one more tip: to check how good your test case is, show it to a person who doesn’t know anything about the project you’re working on. The questions you are going to hear will help to define the weak points of your test case. So pay attention to these moments and try to make changes ASAP. Otherwise, it will take much more time and effort to maintain test cases in the future.
