If you’re in software testing, you should be familiar with or at least heard people mentioning “test case design”. The reason it’s so so common is simply because it’s one of the most important activities in software testing. It’s a “make or break” for the quality of your testing. Disregard if you’re a seasoned testeror a new tester, in this post today, I’m going to explain everything you need to know about test case design …and hopefully, it can help you design your test effectively.
What is meant by test design?
According to ISTQB, Test design is “The process of transforming general test objectives into tangible test conditions and test cases.”
According to Wiki, “test design is the activity of deriving and specifying test cases from test conditions to test software“
If these definitions are still not so clear for you, let’s me define them again;
Test design is an activity where you list out the tests you need to execute for a feature, a component or a system under test.
It’s fine that you see my definition is even worse 🙂 …but I hope that you get the idea.
Benefits of test case design
“But why do we need to design tests. I thought I can just start to test?” You may ask.
Yes, that’s true.
You can just start testing without having this test design activity if the feature under test is very simple or maybe it’s one-time testing. However, for complicated features, you need to have a test design activity. There are some benefits of designing test cases. However, these are the main benefits:
- Tracking and tracing your test coverage:
For complicated use cases with many actors, decisions, conditions, etc, if you don’t design your test in advance, it’s very likely you’ll miss the test cases. Having a test design in place, you are always able to review and see if you are covering enough of the feature
- Reusability:
Now you are the only tester in the project. What if your manager added another tester to 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.
- Maintaining consistency:
Instead of writing our random test cases spontaneously, by applying the right software testing techniques in test design, you’ll always be able to generate test cases consistently and reliably.
What are steps of test design?
Test design process is different from company to company, however, these are the most common (and traditional?) steps to design test cases:
Step#0: Collect test artifacts (or documentation)
Simply put, test artifacts are the documents describing the feature/system under test. You’ll rely on these types of documents to understand the requirements of the features/system under test and then you’ll start designing and writing test cases for it.
What documents do I need?
Basically, below are documents that are often available for you to understand the feature/system:
- Functional Requirement Specification (FSR)
- System Requirement Specification (SRS)
- UI Mockup or UI Wireframe
- Use case
- Help file
- Release note
- or even in emails.
Again, this is different from team to team, company to company. Some will have better documentation while some not but it’s okay. You’re here to do your work not complaining about documentation stuff.
If you’re not sure or cannot find the right documentation, go ahead and ask your managers for these documents. Even in the worst cases, go ahead and talk with your developers about the feature/system under test.
The whole idea of this step is to have something you can rely on to understand the requirement of the feature so you can start designing your test.
Side-note: Maintaining documents and keeping them up-to-date is painful so don’t assume that all documents you have in your hands are well updated. Please be prepared to synchronize with the team about how a feature is actually built 😀
Step#1: Extract requirements
If you are lucky enough, you already had a list of requirements extracted from the documents for you. If not, you have to do this by yourself.
Here’s what you will do to collect the requirements:
- Read the document line-by-line
- Identify phrases that describe the requirements
- Skip phrase that’s not a requirement
- Take note of unclear requirements and ask product owner, project manager, and clients, to clarify them.
Here are two important questions you always ask yourself so that you can identify good requirements:
- Is this requirement clear? E.g.: Do I understand clearly what feature/functions are expected to work? What is the expectation here?
- Is this requirement testable? E.g.: Can I test it? Can I predict the expected result?
Step#2: Design your test ideas/test objective:
Based on the requirements you’ve collected, you now start to list out your test objectives/test ideas for your requirements.
This is where your creativity stands out. Use your creativity to create as many test ideas as possible to validate the requirement. However, in order to maintain consistency in the way you design test cases, it’s recommended to apply common test techniques to design your test ideas:
- Boundary Value Analysis
- Equivalence class partitioning
- Decision table
- State transitioning
- Error guessing
You can read more about these techniques in this post (https://www.botplayautomation.com/post/test-case-design-techniques). Btw, these are common test techniques in software testing, you can easily research more on the Internet.
You can track your test requirements in your test management tool or spreadsheet. You can also add some attributes for your requirement such as Priority, Type (Functional, Non-functional, Look and Feel, etc), Traceability, etc.
Format example is as below:
Step#3: Write your test cases
Now you should have a list of test ideas for your requirements and you basically finish test case design. You can start testing based on the test ideas you’ve listed. However, in order to fully complete the test design phase, you need to start adding details for your test case or the so-called “writing test cases”
In general, a test case contains the below components:
- 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, and software are needed, etc.
Test case steps: Describe the necessary steps to execute the test. There are two schools of writing test case steps:
Detailed steps and high-level steps.
Let’s take Gmail logging as an example. Here’s an example of details steps:
- Step 1: Navigate to “http://mail.google.com”
- Step 2: Enter user name
- Step 3: Enter password
- Step 4: Click Sign-in button
Here’s an example of high-level steps:
- Step 1: Navigate to Gmail
- Step 2: Login with valid account
There are some pros and cons to each style.
As you may observe, for detailed step test cases, the test steps are straightforward and easy to follow. This is good because it avoids any deviation during the test and maintains consistency. This is also easier for new tester to run these cases without even knowing much about the system under test.
However, the problem with this style is that 1) it’s time-consuming to write and 2) it’s time-consuming to update the test cases when the feature changes. If you’re in software industry, you should know feature change is an unavoidable part of software development process.
In order to minimize the effort of maintaining test cases, the idea is to write high-level test steps where detailed test steps are masked under high-level/logical test steps so we can reduce the impact of detailed changes. However, the problem with this style as you can guess is that it may create deviation among test runs and a bit challenging for testers who are not familiar with the feature/system under test.
Format example is as below:
What is a good test design?
This is a tough question.
“Good” is a quite subjective term. Good to me doesn’t necessarily mean good to you. However, let me try to list out some of the attributes considered a good test case design.
1) Ability to reveal potential problems in your system
You can write a dozen or hundred test cases for a feature but if these test cases are duplicates or do not add the chance to detect problems/defects when executing them, they are scraps.
Be creative and think of ideas/cases where the system may go wrong from the user’s perspective. Please noted that the test cases are there not only to confirm a feature works but also to reveal cases that may go wrong.
2) Provide a good coverage of the system
Your test cases should cover all the required features of the system under test. In order to know if you already covered enough, you should be able to trace back your test requirements/test cases to see from which requirements they are derived.
Your test cases should also be a mix of negative, positive, use scenarios test cases, etc
3) Maintainability
If your test cases are designed to run once or twice during the entire project life cycle, it’s ok to not put maintainability as your priority. However, if your test cases are part of a regression plan which you frequently run for each software release, you need to design test cases in way to help you spend less effort updating them in the long run. In this case, a high-level test case design style may be a choice for you.
If you keep these points in mind when you design your test cases, you should be fine.
Problems with test case design
“Problems? I thought test case design is best practice in software testing” you may ask.
It’s true that test design is a good practice in software testing. However, as in any practice, it has its own problem that you may need to take care of or keep eye on them when practicing them. Otherwise, it will sooner or later become your problem.
1) Time-consuming
Test design is famous for its time-consuming. Your test design will eat up your test resources in designing and maintaining them. The more complex your system is, the more time-consuming to design them. Also, if your tests are designed poorly, it costs a lot of time (and frustration as well) to understand the test cases or maintain them to keep them updated. These days, the software is required to be released faster and more reliable. Anything which is time-consuming needs to be taken care of.
2) False reliability
I see a lot of management when they want to understand the quality of test team, they ask for “test cases”.
Can you show me your test cases?
What is Passed rate for your test cases?
Are your test cases having 100% test coverage?
People rely too much on test cases. Of course, I’m not saying that test cases are bad. However, test cases are one dimension of test design or the quality of the product. With this said, be careful when you, as a tester, claim that your test design covers 100% coverage without extra clarification. Also, be careful when someone relies on just your test cases to talk about the quality of your test output or to assess the quality of the product.
Final thought
There you have it. I’ve just shared with you a complete guide to designing your tests. Here are some key points to take away when you design your test:
- Understand the requirement. Understanding requirement is the first step for your test design. There’s no way to design test case without a requirement or knowing what the requirement is.
- Test ideas are the key. The heart of your test design lies in the test ideas. If you have good ideas for your tests, you should be fine. It’s still good if your test design is just a list of test ideas without having detailed test cases with test steps. Again, focus on your test ideas.
- Focus on the quality. It’s very tempting to design a lot of test ideas/test cases for your test design because it may create a false feeling that you’re covering or exercising a feature enough. Instead of focusing on quantity, put focus on the quality of your tests.
That’s it. Hope you see this guide as helpful.
What’s your experience with test design? Any new way to design better tests? Feel free to put your comment below.
Anyone who’s starting with test case design should look into this blog