17 Lessons I Learned for Writing Effective Test Cases
17 Lessons I Learned for Writing Effective Test Cases
Looking for ways to optimize your testing efforts?
Join the DZone community and get the full member experience.Join For Free
Sensu is an open source monitoring event pipeline. Try it today.
So, you have been writing test cases for quite some time but are still looking for ways to optimize your testing effort. Test cases are the base of your research on any software product. I have been a software tester myself for more than a couple years now, and looking back, I realize how much I have learned in the domain of software testing. Today, I am going to share with you the 17 lessons I learned in regards to writing effective test cases.
However, before we deep dive into the lessons for writing top-notch test cases, let us have a basic idea on the terminologies associated with them.
|Test Case ID||Case_01, TC_|
|Test Case Description||Description of the test case|
|Test Case Type (Positive / Negative)||Positive test case / negative test case|
|Test Case Scenario||for which scenario this case is being tested|
|Test Data||what input data has been taken for this test case|
|Pre – Condition||Condition before running this test case,|
|Action / Steps for execution for this test case||Steps for executing this test case|
|Expected Result||Based on the aforementioned points expected result can be mentioned here|
|Actual Result||This will be filled during actual execution for the test case|
|Comments||Any kind observation will be mentioned here.|
1. Stay in Your Lane
Earlier, I used to assume how the intended functionality of a test case should be, but through a hard-learned lesson, I realized that it is always better to develop a thorough understanding of the SRS (Software Requirement Specification) document. I have witnessed people become more intuitive rather than following a logical approach, and sometimes, this intuition leads to assumptions. While framing down test cases, an assumption of features and functionalities can often deviate you from actual requirements that were originally required by the client. This will not only affect the product under testing but also client-organization relationship.
2. Be Mindful of the Product Updates
It is critical to stick to SRS but not if it is based on an outdated version of the software. Nobody would want to test a deprecated feature! We live in the world dominated by Agile methodologies where product development drives through the fast lane. Sometimes, to cope up with short time windows or after deploying an immediate bug fix, the SRS document is left unattended. It is a best practice to update the SRS with respect to any major as well as minor change.
3. Write to-the-Point Descriptions
Test case description is vital for relaying the root cause of the bug and it must always contain the steps to reproduce. When I kick-started my testing career, I failed to realize the thin margin between writing specific details and writing ornately. I used to write stories in the field for test case description. I thought it would be impressive to fill the description as much as possible. However, I was wrong! Not only did it waste my time but the developer’s too! I realized how important it is to keep the description crisp, simple, and informative. Nobody likes to read long stories — just be on point.
4. Put Yourself in the Shoes of the Customer
It is often a common scenario that an angry customer would knock up at customer support explaining that the software is not delivering an intended feature up to his expectation. You, as a software tester, should be able to relate yourself to the customer in order to explain the problem from a customer’s point of view to your development team. My manager used to quote all the time that the “customer is always correct.” While writing test scenarios, keep customer/end-users’ requirements in the back of your mind, because ultimately, the software/product designed is for the customer. Keep a note of usability testing and accessibility testing.
5. User Personas
A user persona is a fictional representation of an end user that helps to describe how people from different job roles would operate on your software. If you are not familiar with User Personas, then you must be wondering why you need a fictional character to help you write effective test cases. I used to think like that as well unless I learned how crucial they can be to identify the user’s scope. To understand this more specifically, let’s take an example of Jack. Jack is a web developer who logs into LambdaTest (a cross browser testing tool), so he could test how the web elements of his website or web application are rendering across multiple browsers. In this scenario, Jack will not be bothered about the back end functionalities like API communication; penetration testing will be out of his scope. So, for writing effective test cases, create different User Personas, each representing a community of your targeted audience, their profession, and focus on cases that will cover respective aspects.
6. Be Granular While Writing Down the Steps for Execution
When mentioning steps for execution of test cases, it is always a best practice to avoid composite sentences. Instead, write a small and specific step-by-step guide as a walkthrough of the test case.
For Example, let’s write a test case for Jack who wants to perform cross browser testing of his website using LambdaTest, so he could ensure that his web app or website runs seamlessly across different browsers.
Let’s take a look at the following steps (this job may call for assertive writing):
- Step 1 → Log in to www.lambdatest.com
- Step 2 → Go to Real-Time Test section.
- Step 3 → Select the configurations for testing. (Browser, Browser Version, OS & Screen resolution)
- Step 4 → Hit Start button to run the test and perform testing of your website on respective configuration.
- Step 5 → Terminate the test session.
Did you observe the composite step? It was step 4. “Hit Start button to run the test and perform testing of your website on respective configuration.”
Remember, test cases should always be self-explanatory. It is important to write the steps as granular as possible.
Therefore, the above case is more effective when written below:
- Step 1 → Log in to www.lambdatest.com
- Step 2 → Go to the Real-Time Test section.
- Step 3 → Select the configurations for testing. (Browser, Browser Version, OS, and Screen resolution)
- Step 4 → Hit Start button to run the test.
- Step 5 → Scroll from top to bottom of the webpage.
- Step 6 → Check all the icons and paddings are supported.
- Step 7 → Change resolution display (to check for a device of different screen size).
- Step 8 → Terminate the session.
This is just a brief example to help you understand how to break down steps to the most granular level.
7. Take Ownership of Your Test Cases
I have observed how test cases are juggled without proper ownership, among a pool of software tester, working on a large project. Test cases should be properly distributed in such scenarios. Every software tester should be responsible for only the test cases assigned to him.
8. Actively Use a Test Case Management Tool
Test case management tools are deemed necessary for managing a stable release cycle. They help to develop a level of transparency where everyone knows about who is working on what. They can also be used for tracking deadlines related to a bug fix and a lot more. However, many times, the employees fail to utilize these tool actively and efficiently. In order to write effective test cases, it is vital that you learn the practical use of your respective test case management tool. This not only helped me to write effective test cases but also helped me in tracking the progress about them.
9. Monitor All the Test Cases
When working as a remote software tester or when too many software testers are working on a similar project, then it is common for two software tester to bump on to the similar test case. Therefore, monitoring all the test cases is important to write unique test cases. Also, remember to remove the irrelevant and duplicate test cases.
10. Aim for 100 Percent Test Coverage
Test coverage is an important aspect for enduring the robustness of any software. It is vital to aim for a 100 percent test coverage before you deep dive in your test cases. Take a moment and plan your test cases to cover each component and functionality specified in the SRS document.
11. Beware of Dependent Test Cases
There have been times when I found a bug in a random scenario, and when I tried replicating it, then things didn’t happen as I planned. That is when I realized that even test cases can be dependent on other test cases. For instance, you may have a test case X, which will only be executed after performing test case Y and test case Z, sequentially. This scenario is usually observed when two modules are non-mutually exclusive. So, a bug may not reproduce unless you draft a scenario after figuring out the dependent test cases.
12. Be the Critic
Sometimes, you need to take a different approach than others in order to find the unknowns of a software. Unknowns are scenarios that are blind to the product team until they are reported by the end user. For writing effective test cases, it is necessary that you do things differently. Think exceptionally — especially if you are aiming for exploratory testing.
13. Be Intent Specific
Realizing the acceptance criteria is imperative to write effective test cases. Acceptance criteria is a condition that validates whether the software is working as intended with respect to the end user. Remember, acceptance criteria is there to help you judge the intent of the end user rather than the steps. For example, “an administrator should be able to invite or kick people out of the team working on a same project under an organization” instead of “an administrator should visit the team page under organization settings, and click on invite to add people to the team or click on remove to kick people out of it.”
14. Lean on Automation
My experience as a software tester has taught me that software testing is a rigorous and never-ending process. The rise of progressive enhancement and adoption of Agile methodologies has made regression testing an emergency but also as a headache to many of us. However, the introduction of automation testing has been a game changer for regression testing. Automation results in increased productivity and bandwidth for the software tester, allowing them to think of better ways of writing effective test cases instead of being stuck with the same test cases every day.
15. Test Case Document Is Not Enough
This is very commonly observed and I am sure you would have come across a scenario, too, where once a test case document receives the sign-off from the client, then all of the team gets fixated to that document. Nobody would attempt to think out of the box for writing effective test cases as we feel the document is all we need!
16. Prioritize Your Test Cases
When I started off my career as a software tester, I was clumsy, stressed, and the concept of business priorities was a bit alien to me. I used to jump into the test scenarios with an unorganized approach without realizing the role of priority in test cases. One release cycle, I was short of bandwidth, and as the release date came knocking at my door, I ended up rushing up on a lot of high priority test cases. Post-release, we committed a rollback when a failure was reported by the customers. That was a lesson hard-learned! I realized how critical it is to prioritize the test cases simultaneously as you go about writing an effective test case.
17. Cross Browser Testing Can Help Minimize Outages
In order to write effective test cases, it's important to keep a note of browser differences. One time, an outage popped up in our office where our payment pages were appearing in a very flustered manner to the end user. Our developers did each and everything from clearing cache to rebooting the servers. However, the issue still persisted resulting in a panicky situation. Then, we realized that the users facing inconvenience had one thing in common — they were either using outdated IE browsers or they were using Android from a specific mobile vendor. It was then that we realized the incompatibility of our website with different browsers and devices. There onwards, we implied the practice of performing cross browser testing in our every release cycle to never face an embarrassing situation like that again!
That was all from my point of view. I hope that my lessons for writing effective test cases would be either relatable or knowledgeable to many of you. Leave a comment and share the lessons that made you a wiser software tester below!
Published at DZone with permission of Priyal Mangla , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.