If I had to point out one core task of a test engineer, I would say it’s “Test Cases”. Because ultimately, we need to decide what we should test.
If we were to name the most popular Test Case Management Systems, with Excel and Google Sheets taking second and third place, then the first place would go to not testing at all, thus not needing test case management. This is not a joke. We surveyed about 70 companies across finance, gaming, software development, department stores, retail, and more. Over 50% of these companies don’t have dedicated testers; either developers test their own work or there’s no testing at all, with the end-user doing the acceptance. Even when testing does occur, there’s often no management of test cases.
We’ll discuss the issues with “no testing” in the future. Today, we’ll focus on why we shouldn’t continue using Excel and Google Sheets for test case management.
Have you noticed that the top three methods are all things we don’t recommend, yet they’re what most people do? Unfortunately, the main reason is still cost. Office software, whether from Microsoft or Google, or even free alternatives like OpenOffice and LibreOffice, is standard equipment in every company. Businesses seek to maximize efficiency, and if the monthly costs can yield more uses, the cost-performance ratio is considered high.
Alternatively, test engineers might need tools for test case management, but the company has no extra budget. This forces them to work with what they have, leading them to look at Excel or Word (yes, some companies use Word for test case management).
The following will explain why Excel or Google Sheets should not be used as a Test Case Management System
Ironically, while we’re discussing why Excel and Google Sheets shouldn’t be used for test case management, they’re the most common methods. We can design many templates for management, and each company’s template is different. The root cause of this situation is something we’re often unaware of:
1. The tabular nature of Excel and Google Sheets is essentially a database
This brings us to our first reason. In today’s tech world, databases are at the core of all applications. However, the function of a database is to allow applications to access, integrate, and analyze data, producing meaningful information for users. When we use spreadsheets for test case management, we’re essentially using a database directly for management, lacking an efficient application to help us manage test cases. This is the fundamental reason why Excel and Google Sheets can be used for test case management but aren’t user-friendly, which leads to the second point:
2. Excel and Google Sheets are designed for financial, statistical, and scientific purposes
When a product is designed for a specific field or purpose, and we force it to do something else, it feels awkward, even if it’s not necessarily wrong. For example, scissors have many specialized functions, like general scissors, hair scissors, fabric scissors, meat scissors, bone scissors, pruning shears, and even small nose hair scissors. They’re all scissors meant to cut things, but using them on the wrong target can be troublesome. If you use a tailor’s scissors to cut paper, you’ll definitely get scolded because fabric cutting requires high sharpness, and cutting paper dulls the blade. Even very sharp fabric scissors can’t cut bones because bone scissors need stronger support and leverage.
Excel was originally created to solve numerical calculation problems. When we use it to manage test cases, we basically don’t use those functions except when making reports. We mainly use it for its tabular form to place our test case data.
3. Data in spreadsheets can be easily modified
The third point is that easy modification might seem like an advantage, but you’ve probably experienced accidentally overwriting cell data while navigating the spreadsheet. If you notice immediately, you can use Ctrl + Z to recover, but if you don’t notice for a while, you might forget what was originally written. This not only wastes your initial effort but also requires more time to rectify the mistake.
4. Incorrect version control
With advancing technology, even Excel and Google Sheets now have version history. So the issue of easy data modification seems less significant, right? Wrong, because the version control method in spreadsheets isn’t designed for managing test cases. Imagine a software engineer using Word to write code for document version control… If you think that’s inappropriate, then you shouldn’t think it’s appropriate for managing test cases. What about cell version history? Do you really think cell version history is the same as test case version history? It records changes to that specific cell, but when you move cells for test case management, there’s no correlation.
5. Not conducive to team collaboration
Seeing this point as a reason might upset some people who believe that Google Sheets’ strongest feature is its collaboration function, allowing multiple people to edit the same file simultaneously. How could it not be conducive to collaboration?
The reason it’s not good for collaboration combines “easily modifiable spreadsheet data” and “incorrect version control”.
Since we can’t control spreadsheet version history, when two people edit the same cell in a short time, the intermediate changes might not be recorded. However, a good test case management system would record all modifications, even simultaneous ones, for tracking and restoration if issues arise.
6. File-level management makes it difficult to manage complex projects, with time spent on file management
If you’re risk-aware, you probably wouldn’t put all your eggs in one basket, or you’d choose to backup files to avoid damaging your career if a file is corrupted. But when a project is large or complex, how long would you need to scroll to find one specific test case among a thousand? Even Ctrl+F search requires remembering keywords. If you use files for Test Case classification, it’s not easy to collaborate between two files. Even if you use sheets for classification, it becomes difficult to search when there are too many. In short, you’ll spend a lot of time on management logic, and if the person in charge leaves, the entire management logic needs to be re-familiarized or redesigned. We’ve encountered too many situations where the Test Case structure changes multiple times due to different ideas from those in charge, wasting time and resources.
7. Lack of audit mechanisms and activity logs
While Excel and Google Sheets can record viewing activities and edit history, the granularity is insufficient for practical use. For example, we can’t calculate what changes a member made today or which Test Cases they tested. The records are intended for access control, not activity logging. For test managers, understanding each member’s testing progress and obstacles is a difficult task, especially in the era of remote work. The vast majority of managers adopt a mutually trusting attitude in team management, lacking data support.
8. Difficult to integrate with automated testing
Try to think of a solution: how would you fill in the results of an automated test into a spreadsheet? Okay, stop thinking. When your solution starts to get complicated, it indicates that something is wrong. This is why most automated testing integrations maintain separate test data reports, such as Allure or pytest-compatible reporting modules. This also creates another maintenance cost, as automation test engineers need to allocate time to maintain the reporting mechanism.
Don’t let tools limit your approach. When you focus solely on Excel and Google Sheets, you lose the opportunity to use better systems to improve efficiency.
In conclusion, Excel and Google Sheets are undoubtedly powerful spreadsheet tools, but they are definitely not powerful Test Case Management Systems. Equipping yourself with the wrong weapons prevents you from maximizing your team’s capabilities and efficiency.
If you’re using Excel and satisfied with your current efficiency, you might be in a stagnant state, unable to perceive current problems. You’ve become accustomed to your surroundings, believing the current situation is the best, and lacking the motivation to explore possibilities for higher efficiency.
If you want to simply improve your testing team’s efficiency, changing your test case management system is the quickest way. Choosing a system designed specifically for testers ensures that the entire process is optimized, and the time saved can be used for more testing, obtaining more product-related test data.
“Testers should do what testers are supposed to do, and they should choose the right tools or systems to use”
When testers use incorrect tools, they waste most of their time planning methods and processes to try to adapt to the tools, compensating for the difficulties brought by incorrect tools. This leads to ineffective use of testers’ time.
If you want to improve your testing team’s efficiency, besides hiring more test engineers, you can consider conducting a software testing health check to identify key issues hindering efficiency and further resolve them.