Are you reading this because you have decided you need a better way to manage test cases? Maybe you currently use spreadsheets, and they have become too cumbersome to update, execute and report results while using row after row of mind-numbing text in little boxes. I feel your pain!
Well, you have come to the right place. I’ve been a Software Test Engineer for the past 14 years, and have spent way too much time using poor tools (including just spreadsheets), so I’m here to help you avoid the mistakes I’ve made in choosing a test case management tool.
This is for you if you’re currently using a tool that just isn’t cutting it because it’s overly complex, takes too long to set up test runs, is difficult to maintain or doesn’t integrate well with other tools used by your team. Or maybe you are just getting started. You know you need a tool to write test cases and manage them (if you don’t know, you will soon find out), but you aren’t sure what to look for or where to start.
I’m going to start by outlining what you need in a tool so you can quickly find one that checks all the boxes. Here are the top test management tool features to look for but depending on your organization and needs, some may be more important than others. These are listed in no particular order.
10 Important Features to Consider when Choosing a Test Case Management Tool
1. Import / Export Capabilities
If you are just getting started, the import function is unlikely to be first on your list. However, if you have spent the past year documenting test cases in spreadsheets, basic docs or another test case management tool, then being able to import your existing cases will be essential.
Full disclaimer – I actually like writing test cases in google sheets for new features and then importing them into a test case management tool. Here’s why. If I know I am going to be writing hundreds of cases, the simplicity of writing those cases works well for me in spreadsheets. Once I am done writing and ready to import into the test case management tool, the columns in the sheet map to fields within the tool. For me, this process should be quick and easy, and after being imported, it should look like what I expect in the tool.
After the initial import, the sheet can be tossed aside, and I typically maintain, update and add additional cases within the tool. It’s just the initial drafting of the test cases where I prefer to use a blank canvas such as a spreadsheet.
The ability to export cases is a required feature for a couple of important reasons. If you ever need to change tools, you will want to be able to export into a format that can then be imported to the new tool. Also, you may run into a scenario where you need to provide the test plan including test cases to a client or a teammate who can’t access the tool for some reason. You don’t want your work to be locked into a tool without having an easy way to export and share.
In addition to exporting cases from the tools interface, an API which allows you to access them programmatically can also be a benefit for various tasks.
2. Customizable Test Runs
In software testing, a “test run” is comprised of a set of test cases designed to test a particular piece of software, a specific feature or a pending software release that usually includes regression testing.
Each test run will usually be different. If multiple changes were made to an existing feature or a new feature was added, the test run might consist of mostly test cases for those features, plus other legacy test cases to ensure no functionality is broken.
The test run isn’t going to serve its purpose if it doesn’t include the right cases. The tool must provide the ability to easily pick and choose test cases from the “test repository” to create the test run that is best customized for the software being tested. Plus, time is always of the essence – nobody wants to run a bunch of cases that aren’t necessary just because it was too much work to customize the test run. This customization is paramount for efficiency.
You’ll probably also want to test on different browsers/devices, so being able to set these within a test run will be a very helpful feature.
3. Integration with Issue Tracking Tools
It can be really helpful to be able to integrate with issue tracking tools such as JIRA and Trello. Project management and development teams track releases, development tasks and of course BUGS in these tracking tools. So does the test case management tool you are considering integrate with the issue tracking tool your team uses? If not, you might want to move on, unless, of course, you just need to manage a test case repository and test runs.
Some test case management tools provide a slick automated defect creation option for when a test case fails. As soon as the tester marks the case as failed in the test case management tool, the information is sent off, and a defect is logged. This is a huge benefit for a couple of reasons; quick communication is always important, so when there a defect has been identified, the team needs to know as soon as possible. The developers and the rest of the team are then notified immediately without requiring the tester to stop execution to manually enter the defect, and become derailed from executing the test set.
The integration should, however, not stop there. When bugs are resolved, it should be possible for testers to view the updated status in the test management tool, along with easily selecting the failed tests with resolved tickets to verify any fixes.
4. Simple and Quick Test Execution
One of the headaches I’ve encountered with some tools is the overhead required to execute a test run within a tool. One of my pet peeves is unnecessary and excessive clicking. I suppose this applies to any piece of software. When executing a test run, I want to be able to quickly pass a test case and move on.
Software testing can be very repetitive, and the tool you use should help alleviate this. When a tester has run a test numerous times, it’s unlikely they’ll need to read each step and expected result time and again. Often, you just need to read the title, test it, and move on. Passing each step along the way should be an option the user may invoke.
Your test case management tool should give you the flexibility to move quickly through a test set, but also provide the ability to easily view all details of the test case when necessary.
The layout of the test description, test steps and expected results should be customizable to accommodate each tester’s needs. You should be able to add custom fields to enable you to store additional data in an organized way easily.
Other items such as the ability to choose which fields are displayed and what results are available for a test case result (Passed, Failed, Skipped, Re-Test, N/A, etc.) are important to align to your team’s current usage of result verbiage.
Reporting test results is necessary in any QA organization. A major difference between development and testing is that testers don’t have a product to show as a result of their work. The “product” for QA is usually documentation such as bug reports and test results.
Test reports should be simple and easy to read because there is no need for a complicated process to create a report after a test run. You just need pertinent information such defects identified, pass/fail results and a list of the tests executed. A field for tester comments or a summary of the test run including version, browser and device info is also nice to have.
Being able to spot trends such as the most commonly failed tests and easily being able to see a user’s workload can be useful for planning future work and identifying recurring issues which may need further discussion.
It’s amazing how a seemingly simple application (from an end-user’s perspective) can require so much testing. Anyone who has written test cases understands how quickly the scenarios pile up. This is why having the ability to search the test cases repository is an absolute must for this list. When building a test set, the code that has been changed may affect many different areas. The tester doesn’t want or need, to test all cases in all areas, and most likely there isn’t that kind of time available, so the tester should be able to search for cases and add them to a test run without sifting through hundreds of lines of text to find the appropriate cases to add.
Maybe the most neglected aspect of test case management is test case maintenance. The speed at which software is developed, fixed and iterated creates a constant need to maintain test cases. They need to be added to, removed and updated often, if you take into account the fact that requirements can change on an almost a daily basis.
How your test case management tool accommodates maintenance determines the amount of time and energy you will have to spend here. When a workflow is changed that affects multiple features, how do you update those cases? Do you remember where they are? The search feature previously mentioned should aid in finding the cases to maintain.
9. Onboarding / Demo Videos
Let’s say you are researching the best test case management tool for you and your organization. (This is probably a fair assumption since you are here.) How much time can you spare for learning how to use the tool? How much time do you want to spend figuring out the features available and if they work for you? If you are like me, you have testing to do. As important as it is, you’re unlikely to be excited about spending hours figuring out how to use a tool, only to move on to another one when you find it’s not exactly what you need
Look for a tool that provides a smooth onboarding experience with demo videos that leave you understanding the tool’s capabilities. There is a good chance that if you feel well-informed and positive about the tool after viewing demo videos, you will have a good experience getting started.
Is there a tool or software application where the end-user is NOT looking for simplicity? With any tool, you are looking for the features you need plus a straightforward interface. Sure, it takes time to learn how to use a new tool, but, it shouldn’t be overly complicated and time-consuming.
In just about every feature I’ve talked about, I’ve also mentioned a desire for simplicity. Building and testing software is complicated, but your testing tool shouldn’t be. I want an intuitive interface without it being cluttered with buttons for features I have no use for. I want to import test cases, create test runs, log defects and report results. At the very least, setting this up and getting started shouldn’t take hours away from the endless testing to get done.
Assessing a test case management tool can be a little overwhelming if you don’t know where to start or what to look for. I hope this list of the most desirable features will lead you in the right direction. Every organization has different needs, so keep in mind the needs of your team. Whether you are a solo tester or part of a large QA team, these are the features for you to consider when evaluating a test case management tool.