8 Reasons Why Excel or Google Sheets Should Not Be Used as a Test Case Management System

by | Jan 8, 2024 | English, Software Testing

If we were to talk about the most popular Test Case Management Systems, Excel and Google Sheets might come second and third. Ironically, the first place is held by ‘not having any testing at all,’ which means no need for test management. This isn’t a joke. We surveyed around seventy companies across various sectors like finance, gaming, software development, department stores, and retail. We found that over 70% of these companies don’t have dedicated testing personnel. Testing is either done by the developers themselves or not at all, leaving it to the end-users for acceptance. Even when testing is conducted, it’s often unmanaged.

The issue of ‘not having any testing at all’ is a topic for another day. Today, we’re focusing on why we shouldn’t continue using Excel and Google Sheets for test management.

Have you noticed that the top three methods we’re discussing are not recommended(No testing, Excel, Google Sheet), yet they’re the most commonly practiced? Unfortunately, the main reason for this is cost. Office software, be it Microsoft or Google’s offerings, including free alternatives like OpenOffice and LibreOffice, are standard in most companies. Maximizing utility for the cost is a corporate pursuit. The higher the usage value per cost, the better.

On the flip side, when test engineers need tools for test management but the company doesn’t allocate extra budget, they have to make do with what’s available, often resorting to Excel or Word (yes, some companies use Word for test management).

Let’s dive into why Excel or Google Sheets shouldn’t be used as Test Case Management Systems. Ironically, we’re discussing why not to use these tools, yet they are the most common methods for test management. We can design various templates for management, and each company’s template can be different. This situation stems from a lack of awareness.

Excel and Google Sheets are essentially databases.

The first reason we highlight is that, in today’s tech world, databases are central to applications. Databases store and analyze data to provide meaningful information. Using spreadsheets for test management is like directly managing tests through a database, without an efficient application in between. This is why Excel and Google Sheets can be used for test management but are not ideal, leading to the second point:

These tools are designed for financial, statistical, and scientific purposes.

Using a product designed for specific domains for something else, while not wrong, feels awkward. For example, various types of scissors exist for specific purposes. Using the wrong type of scissors for a task can be troublesome. Similarly, Excel was created for numeric computations, and most of its functions are redundant for test management, as we primarily use it for its tabular format.

The ease of modifying data in tables seems advantageous but can be a significant drawback. Accidental key presses can overwrite data, sometimes irrecoverably. This leads to data loss and additional time spent in rectification.

Incorrect version control is another issue. Although Excel and Google Sheets now have version history, their approach isn’t suited for test management. Imagine a software engineer using Word for coding because of its version history – it’s just as inappropriate for test case management. And even if cell-level version history exists, it’s not the same as managing test case versions.

These tools also hinder team collaboration. Despite the collaborative features of Google Sheets, simultaneous editing and the lack of proper version control can lead to data loss and confusion. A competent test management system records all changes, even simultaneous ones, for traceability and restoration.

File-level management is not suitable for complex projects. Managing thousands of test cases in a spreadsheet is a logistical nightmare, especially when the person responsible leaves or changes. Consistent restructuring of test cases due to varying management styles is a waste of time and resources.

Lack of audit mechanisms and activity logs is another drawback. While these tools can track view and edit histories, they lack the granularity needed for practical use. Tracking individual member contributions and test progress is challenging, especially in remote work environments.

Finally, integration with automated testing is difficult. Imagine trying to backfill automated test results into a spreadsheet – the complexity indicates a problem. This is why most automated tests maintain separate reporting systems, adding another layer of maintenance.

Don’t let tools limit your methods. Focusing solely on Excel and Google Sheets means missing out on more efficient systems. In conclusion, while Excel and Google Sheets are powerful spreadsheet tools, they are not suitable for test case management. Using the wrong tool can hinder staff capabilities and efficiency.

If you’re using Excel and are satisfied with the efficiency, you might be in a stagnant state, unable to see the current problems. This complacency can prevent exploring more efficient alternatives.

Switching to a system designed specifically for testers can ensure an optimized process, saving time for more tests and yielding more product-related data.

文章作者介紹

Fabian Lin

從研發領域叛逃的QA,從小咖變工程總監,我想把業界很多錯誤的認知導正,帶領新鮮人或基層人員往上走,開發平價的測試管理系統Armoury+,在測試的道路上獲得更多成就感(面試不用再只能說找到Bug很有成就感了),歡迎隨時聯繫我。

你也想要分享知識和觀點嗎?KEENLITY目前推出INSIGHT觀點報,誠徵「專欄作家」與「單篇投稿」,點擊連結投稿並了解好處和責任。

精選軟體測試線上課程

邀請您訂閱INSIGHT觀點電子報

6 + 10 =

Similar Posts

談Offer的藝術:在求職博弈中尋找平衡與價值

談Offer的藝術:在求職博弈中尋找平衡與價值

每個人在求職的過程當中,一定會遇到一個最重要的事情-談Offer。 在經過多方廝殺,面試多場之後,終於拿到了Offer,往往就像通宵打遊戲終於來到最終Boss關一樣興奮,總是想取得最後漂亮的勝利,拿到最豐盛的寶物。然而,許多人對這個過程存在誤解,認為這是一場爭取最高薪資的競賽。事實上,成功的Offer談判遠比這種簡單化的理解要複雜得多。今天我們將探討如何用正確穩定的觀念和心態來談Offer,既維護自身利益,又能建立良好的職場關係,同時找到最適合自己的職業機會,不讓自己後悔。 重新定義談Offer的本質...

除了「CrowdStrike到底有沒有做測試?」之外,你更應該思考的是這6個軟體測試思維問題

除了「CrowdStrike到底有沒有做測試?」之外,你更應該思考的是這6個軟體測試思維問題

2024年7月19日, CrowdStrike公司的更新引發的全球微軟Windows大規模當機事件,網路上在討論什麼?發現討論的焦點主要集中在以下幾個方面:開發者的軟體測試思維、分階段上線策略的缺失、軟體測試的必要性與局限性、敏捷開發與軟體測試的關係、自動化測試的爭議,但其實根本原因在流程!而不是測試!

「一日測試,終身測試」的正確解讀

「一日測試,終身測試」的正確解讀

註冊會員,取得Armoury測試管理系統的免費培訓課程 我們的Ticket Based Program跑了一段時間了,我們收到了很多人在軟體測試的相關問題,因此誕生了這個企劃,QA Q&A,當我們收到一些有趣的問題,不涉及企業機密的,我們就會考慮做成影片,放在官網上跟大家分享。 這次第一集就是要來討論一句老話: 一日測試終身測試是不是真的?這廢話啊,當然是真的啊,只是看你怎麼解讀而已。...

分享好文章給朋友吧!

根據統計,測試能力越高的越願意分享。你的分享是給作者最大的鼓勵!