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 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.
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 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:
Just like all the testing artifacts, a test case has a specific format and features the following attributes:
Also, some extra attributes may be necessary for some test cases:
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:
When talking about best practices, we imply the rules that help create simple, understandable, and useful test cases:
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.
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:
Expected result: All the relevant results are displayed on the Search Results page.
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:
Expected result: Displaying of warning messages should be disabled to protect from SQL injections.
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:
Expected result: The warning message Please use only valid characters is displayed. It is possible to proceed with the search.
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.
Result-driven QA isn’t always about planning and strategizing. Sometimes, the best thing for your product…
A flimsy UI doesn’t lead to customer frustration, negative reviews, and high churn. When people…
Good communicators tend to do much better in life. And this applies to software as…
You can’t know if anything is wrong until a problem pops up. That’s what someone…
What is the root of quality in software? A good budget, a smart strategy, customer…
We all want change sometimes. And wouldn’t it be perfect to have a person who…