In this post, we’ll cover the basics of writing a test case and go over how to manually test a login form. Please feel free to add your own examples and advice in the comments below. This is meant as a beginner tutorial for those who are new to testing, so if you’ve got some great advice – share it!
But first…what’s a test case?
Test cases are the bread and butter of testing. The main purpose of writing test cases is to validate the testing coverage of the application.
This means that a test case defines a set of conditions (e.g. inputs, actions, expected responses), which determine whether or not an application is working correctly. Learning to write an effective test case is a skill that is well worth mastering and can make your testing cycle much more efficient.
To state the obvious: it will come in handy!
The format of a test case
Test cases can be written out in lines on a page, but it is better to write them in tabular form. It’s easier to view a test case in this format and many companies choose to use Excel sheets for their templates.
Your test case should always include the following columns or fields: Test case ID, Test case description, Preconditions, Test Input, Steps, Expected result, and Actual result.
In general, these are the key elements in a test case, but there are additional fields of information that you may encounter in examples and choose to include in your own.
Example: The login form
We have created a test case to test a function of an e-shop login form for registered customers. Our example includes some fields that were not mentioned above in order to provide an example of other types of information you could include.
We’ll write our test case in lines for the purpose of this post, but normally we would use a tabular format.
Project name: exampleshop.testomato.com
Page name: Login screen
Test case ID: TC-01
Test case description: Verify the following text fields in the Login screen – Username, Password
Pre-existing conditions: Login screen must exist
Test Input: N/A
Item to test: All fields are left blank and Login button is clicked
Steps: Click Login button
Expected result: The warning message (“Warning: No match for E-Mail Address and/or Password.”) should appear when the required fields are left blank and Login button is clicked.
Actual result: The warning message (“Warning: No match for E-Mail Address and/or Password.”) appears when the required fields are left blank and the Login button is clicked.
Remember, when you’re writing your steps to execute you can use short keywords to describe the actions that you wish to be followed. You can also consider color coding specific fields for better organization within your table.
Add more test cases and scenarios
When it comes to testing your application, it’s helpful to try and imagine what a person using it would do in a real-time environment. Visualizing what a user would do in various scenarios will help you find mistakes more easily.
It’s important to note, in the example above we showed you how to process the test case manually. However, it can also be automated (more on that below).
Here are a few more test cases, which can only be done manually:
- Username and Password fields appear in the proper position
- Username and Password fields have the same font and size
- Username and Password fields are properly aligned
- Check the Forgotten Password hyperlink is visible
- The Login button is visible and active
These examples are just some of the possible combinations and scenarios that you could create. Learning to generate a variety of ideas for tests that cover a wide area will force you think both creatively and analytically.
Do you have some more advice you’d like to share? Do you think this post was helpful?
As always, we’d love to hear what you’ve got to say. Thanks for reading and happy testing!