Hey there,
Hope you are still with me…I also hope that you did your homework too 😀
Anyway, here are my sample answers for exercise in lesson #3.
In last lesson #3, you learned about the importance of requirement, why we needed to collect requirement and how we did that.
Now that you have a list of requirements. Our next step is to write test cases for these requirements.
That’s the whole purpose of Lesson #4 today: Design your first test case
What is a test case and why you need it?
Test case is one of the most common elements in software testing. However, test case is also one of the most confusing and misleading terms.
Let’s take a look at some definitions:
Here’s how Wiki defines test case:
A test case, in software engineering, is a set of conditions under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do.
A test case is a document, which has a set of test data, preconditions, expected results and post-conditions, developed for a particular test scenario in order to verify compliance against a specific requirement.
IEEE standard:
A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
Here’s my definition:
Test case is an idea you want to test a specific feature or function of the system
Yeah, it’s that simple. Don’t try to complicate things at this point. Let’s stick with one definition that makes sense for you.
Here are the main components of a test case:
Test case name: Your test case name should be clear and reflect what component you are testing on.
Ex:
- TC_Login_Valid_01
- TC_Login_Valid_02
- TC_Login_Invalid_01
Test case description: Describe what you want to test or the goal you want to test. My suggestion is to put the test requirement description into this field.
Pre-condition: Describe necessary preparation before you run this test case. This will help testers can run the test properly. Ex: What browser, support device, softwares are needed, etc.
Test case step: Describe the necessary steps to execute the test. There are two schools of writing test case step:
Detailed steps and high-level steps
Here’s an example of detailed test steps:
- Step 1: Navigate to “http://mail.google.com”
- Step 2: Enter user name
- Step 3: Enter password
- Step 4: Click Sign in button
With this style, steps are very detailed and specific. This will help testers can follow exactly and maintain the consistency in the result. However, the drawback is that it not only takes more time to write but also makes your tests easy to break.
What do I mean when I say “easy to break”? I’ll explain…
Take example above, what if Google changed the address of gmail from http://mail.google.com to something different like https://gmail.google.com or they changed the “Sign in button” into “Submit button”? Now you need extra effort to go back and update your steps.
Don’t worry! There’s another way to write test case step
High level test case
Here’s how high-level style looks like:
- Step 1: Navigate to Gmail
- Step 2: Login with valid account
As you can see, with this style, you basically may avoid extra effort to modify your test cases step when requirement changes while it still maintains enough information for testers to follow and execute the test. However, writing test step this way can give room for deviation when performing the test and the test result may not be consistent.
I often choose the high-level style, but this is just me. You should choose what fits for you and your team.
Expected result: What you expect when you perform a step or verification point. The expected result needs to be clear and specific.
Actual result: What you observe when you perform a step or verification point
Test data: The inputs used for a step such as account information, website address, input values, etc.
Priority: The priority of this test case. It depends on different projects. Basically, it follows the MoSCoW method. E.g.: Must have– Should have-Could have-Wont have. If you don’t like this method, you can define your prioritization list such as Highest-High-Medium-Low. It works just fine.
Created By: Name of tester who designed this test case.
Test result: The result when executing this test case:
- “Passed”: The expected result and actual result match
- “Failed”: The expected result and actual result do not match
- “Not tested”: The test hasn’t been executed yet
- “N/A” (Not applicable): The test is not applicable in the system
It depends on the projects. You can add more fields or remove unnecessary fields in your test case template accordingly. Things are even easier for you if you are using a test management system tool to manage your test cases.
That’s all for lesson #4.
To practice what you have learned so far, I have an exercise for you 😀
No, you don’t like exercise? Oh, come on! this is the last yet important exercise in this course.
In this exercise, you will be assigned to design test case for the password recovery feature of Skype. This exercise may take you 15-30 minutes
Here’s the instruction:
- Download the test requirement and test case template
- Download the functional requirement document of this Skype feature
- Collect requirements from this document and put them into Test Requirement sheet
- Write test case for collected requirements and put them into Test Case sheet
- That’s it
I will send you my sample test cases in next lesson. However, I would recommend you sit back and do this exercise. You can only improve your test design skills just by practicing it.
Happy homework!
We are almost complete this course, just one more lesson to go. In next lesson, I will share with you some good practices to have an effective test case design and frequently asked questions (with my answers too). So stay tuned!
What’s next?
Do your homework 😀