As promised, here’s the first lesson in a series of 5 lessons to help you design effective test case
I’m very excited that you decided to join this mini course and that you want to improve yourself to become a better tester.
Anyway, in the next few days, you will be getting 5 in-depth lessons from me that will walk you through step-by-step to design your test cases. The guide is based on my own experience and I will share them all with you for free. Here are some suggestion from me to learn this course the best:
- Do not skip any lesson.
- Spend 30 minutes (or less) a day to go through my lessons.
- Do your homework. I have some homeworks for you, but they are extremely easy.
- Ask me your question. While learning, if you have anything unclear, just reply the email and ask me your questions. I will find time and answer them all.
Here are several things to keep in mind:
- This course alone will not make you become an expert. You need to practice, practice and practice
- What I shared in this course is based on my own experience in my previous projects. It means that this is not one-size-fit-all guide
That’s all. Are you ready to go?
Let’s jump in!
Lesson #1 : Introduction and concepts
I don’t know you, but if you are in software testing, there’s an activity you must be familiar with (or if not, you will do it at some point of time in your journey):
It’s Test Case Design (or some may call it “Test Case Writing” or “Test Procedure Writing”)
Before going into details of designing test case, let’s say:
You are a new tester and assigned to a project call “The ACME”. Since the project is new and still in the initial phase, your manager wants you to design test cases for this project. This is a challenging task for you because you’re new in software testing and not familiar with this testing activity. To make thing more challenging, you are the only tester in this project and you have to figure it out by yourself.
It’s apparent that you need some help.
The good news is that you have a good friend, Thanh (yeah, it’s me :-)). Thanh has been a tester for 10 years and he’s willing to help you out.
For the next couple of days, I will walk you through step-by-step to help you design effective test cases.
Alright, here we go:
First thing first…
What is a test case design and why you need it?
Test design is defined as an activity in which you will write tests so that you can test your system. These written tests are called test cases
“But, why I need to write test cases? I thought I just need to jump right into the system, start to explore and report bugs” You might ask…
I’m glad that you ask this question. It’s always critical to understand “Why you do what you do”
There are a few reasons why you need to design and write out your test cases:
- Tracking your test coverage:
Let’s consider your system under test as a Disneyland park, which you want to explore. Of course, you can just buy tickets and explore the park as you wish. While it’s fun to do that, there are great chances that you will miss interesting places. In this case, all you need is a map of the park. Similar in your project, you need a map to know what you need to test, what you have tested, what you don’t need to test.
- Maintain consistency:
Let’s say you can brainstorm 100 test cases to test your system, but you don’t write them out. You memorize them. Unless you are a genius, there’s no way to remember all these test cases and things entailed such input data, step to perform the test, where to look at the result, what’s expected. If you have a written test cases, you don’t have to rely on your memory to do this test to maintain consistency.
Now you are the only tester in the project. What if your manager added another tester in your project and your manager wanted him to perform the same test as you did. What you simply need to do is to give him your well-written test cases and he can follow these exact tests to perform the test. It’s as simple as that.
- Easy to automate:
Also, if you are planning to do an automated test in your project, these detailed test cases are perfect inputs for your test automation.
While these written test cases have their own values, there are some caveats you need to know too:
- Time-consuming. The whole test design activity costs you a lot of time and may discourage you.
- More effort to maintain.
This is quite straight forward. Since you write everything down, you will take more effort to keep your test cases up-to-date if there are changes in your system. It means that when you have a new build, you need to go back and update your test cases accordingly.
I have just shared with you the pros and cons of having scripted test cases. Understanding these pros and cons is important because no project is exactly the same. If you find your cons outweigh the pros, you need to re-consider if you should have detailed and scripted test cases or not.
At this point, I assume you understand these pros and cons and you decide to design your test cases.
To make the test design process systematic, here’s the process we need to follow:
I will walk you through each phase of this process, but here’s the sneak peak for you:
- Collect Test Artifacts: In this phase, you will need to collect all your test artifacts to prepare for designing test cases such as FRS, UI Wireframe, Use Case documents
- Collect Requirements: In this phrase, you will collect requirements from test artifacts and put them into Test Requirement Template
- Write Test Case: You will write detailed test cases based on collected requirements
That’s all for Lesson #1.
In next lesson, we’ll start with the first phase: Collect Test Artifacts.