Writing test cases
For QA engineers, writing test cases is one of the main activities that must be done on a regular basis. For experienced QA engineers, we have probably written millions of test cases over the life of our careers.
Since you are reading this article, I am going to assume that you are new to this or are wanting to see how other QA engineers write their test cases.
This article is specific to end-to-end front end test cases. These are scenarios where a user is using a web application, desktop application, or mobile application to perform some function.
I will briefly introduce you to the two major styles of writing test cases.
Purpose of test cases
Let’s start off by answering the question, “Why do we write test cases?”.
There are a few reasons.
- Make sure the feature is working as expected
- Document functionality from a user point of view
- Document the history of when that functionality was working
- Helps to expose bugs in the software
Structure of a test case
The structure of a test case can vary depending on who is writing them. But the main concept will always be the same.
- You need to tell what the test is about.
- You need to tell how to execute the test.
- And you need to tell what you are expecting the test to have accomplished.
A test case can typically come in two different forms. Traditional or BDD.
The purpose of both forms is the same. To test the feature. The only difference is the format that they are written in.
The traditional approach is pretty flexible in how the user wants to define the test cases.
However, all test cases usually always have these elements:
- Execution steps
- Expected results
Pretty simple right?
Sometimes there is a need to add more details into the test case.
Here are additional sections that may be added:
- Attachments of data to use
Here is an example of a test case using the traditional method:
Title: User can login
- Enter a valid username and password
- Click the “login” button
- User is logged in
- User is redirected to the home page
BDD (Behaviour Driven Development)
The BDD approach, or Behaviour Driven Development, the goal of the test case is the same at the traditional approach but the format is more set in stone.
Here is the structure:
Well, that is different.
“GIVEN” is the context or the purpose of the test. Basically it is what we used for a title in the traditional approach.
“WHEN” are the actions taken for the test. Comparing with the traditional approach, these are the execution steps.
“THEN” is the expected result.
There is also “AND” that can be used after any of the keywords to add additional steps or clarity.
Here is an example of the BDD method:
GIVEN a user logs in
WHEN the user enters a valid username and password
AND clicks the login button
THEN the user is logged in
AND the user sees the home page