Hurrah, welcome to Lesson #5. This is the last lesson (also my favorite one) of the series of 5 lessons to help you design effective test case.
If you are still being with me and enjoy my course so far, I really appreciate your effort spent because not so many people can commit their learning in self-pace course. Great job!
In lesson #4, I taught you how to write your first test cases. I also assigned you an exercise in which you needed to apply what you had learned to design complete test cases. It’s okay if you couldn’t complete the exercise….don’t feel bad.
As promised, here is the sample test case for exercise I gave in Lesson #4. Take a look and see how they look like.
Anyway, here’s lesson #5: Good practices and FAQs
In today’s lesson, I would like to share with you some good practices (sorry, I hate “best practices” term) in designing test case and some frequently asked questions (with my answers).
Alright, let’s go!
Here are some good practices to have an effective test design:
- Your test cases should be a mix of positive, negative and scenarios cases
- Apply technique such as boundary, decision table, equivalence class where your application has boundary related requirement like textbox, dropdown, etc.
- A test case must have at least one verification point
- Your test case always has “Traceability” so that you can know where you get this requirement from
- The expected result should be clear and specific
- Reusability: Your test case should be reused. If it’s not reused or you just use it once, you need to consider if you should write test case or not
- Maintainability: You test case should be written in a way that reduce your maintaining effort. You also consider to design your test case in high-level style
- You can always add more test cases where you find fit. There’s no a fixed test case number.
Some Frequently Asked Questions:
1)How many test cases are enough?
I think this is a wrong question. The right question to me is “how many good test cases you have?”
You can always write as many test cases as you wish, so the number of test cases does not mean anything to me. Instead of chasing the numbers, I prefer to focus on the quality of your test cases.
I would rather have 10 good test cases than 100 test cases which do not reveal anything about the system under test. In general, good test cases are test cases:
- Ability to reveal potential problem in your system
- Provide a good coverage of the system
- A mix of functional, negative, scenarios cases
- No duplicate
2) How can I write test case without documents?
No or lacking document situation is not uncommon these days. This is especially true when you are in Agile shop where team often focus on do things which brings value (more often they don’t see the value in write documents), so you may not see many documents in Agile shop.
As a tester, you do not always need documents to test, but you need this one:
“Requirements”
As I already shared in my previous lesson, you need to understand the requirement of a feature before writing test case for it. If this requirement is not documented, you can go and ask. I would ask questions (and let people think I’m stupid) to understand requirements rather than assume and test the wrong requirement.
3) What are the attributes of a good test case?
- Ability to reveal the potential problem in your system
- Reproducible: Tester can follow and execute the test
- Understandable: Easy to understand by all people who might be interested in
- Test single set of functionality: If the test fails, you know exactly what went wrong. This is not always practical, but it is ideal.
- Good naming convention: Have clear, easy to understand test case name, test case description
- Independent: one test case shouldn’t be based on the results of another
4) What’s difference between test case and test suite?
Basically, a test case is a single test to verify a specific test objective. For example, you may have these two test cases:
- A test case to verify login function with a valid account.
- A test case to verify login function with invalid account.
Meanwhile a test suite is a collection or group of test cases. Take the example above, you can group those two test cases into a test suite. In other words, you have a Login test suite consisting of these two test cases.
5) Should I use Test case or checklist?
It depends on the context.
If you need a very detailed step-by-step test case, your team has many new testers or your project does not have a tight schedule, you can start with detailed test cases. Detailed test case can help you maintain the consistency in the output of expected results.
Meanwhile, checklist is very handy. If you need a very simple check of the main functionalities of your system, you can use checklist. However, to use checklist, your team needs to reach a certain level of maturity to keep the test consistent.
6) How to reduce the maintenance effort with test cases?
There are several ideas:
- Do not hard-code your test data or value in test case
- Use high-level business test steps instead of detailed steps to execute
- Use checklist
- Do not create test cases if your system is changed frequently and not stable
7) How to know the coverage of our test cases?
To measure the coverage, you need to define what you want to measure coverage against. Such as requirements, environments, platforms, etc.
Also, you can add the Traceability field in your test case to trace where this test case is derived from.
8) Who should review my test cases?
More often, test case is reviewed by senior tester, test lead or sometimes your peer testers. The idea is to have a fresh view when reviewing a test case.
9) Who should write test case?
Anyone can write test case. Developers, product managers sometimes also write tests for their purposes, but testers do it the most.
10) What are the best tools to manage test case?
There are many tools out there to choose from. You may want to take a look at the list of tools here: https://en.wikipedia.org/wiki/Test_management_tools.
The key thing is that you have to understand what problem you are trying to solve so that you can select the right tool for you. Sometimes, all you need is a simple Excel spreasheet.
Here’s my favorite quote: “A fool with a tool is still a fool”
Well, that’s all for lesson #5. It’s also the last lesson in the series of my mini course: Design Effective Test Case in 5 Days.
Congratulations! Great job!
Final thought
I hope you enjoyed the course so far and that the course is helpful for you. I also hope that after this course, you know how to design effective test case if you are assigned this task in your project.
I know this is not the best course in the industry to teach you how to write test case, not to mention my course is still in the first version, but I hope you can learn a thing or two from this course.