There's no need to elaborate: offline test management (Excel, Word...) is inferior to online test management (test management systems) in both efficiency and quality. If you're still doing offline test case management, team leads should ask themselves:

When different test engineers execute the same test cases, is the result consistent enough?

Are test case reviews easy to conduct?

How do you ensure comprehensive scenario coverage? Are some scenarios missed?

After test cases are modified, does everyone else know?

When a test engineer leaves, can the new engineer quickly pick things up?

After each test cycle, are you still spending a lot of time organizing bugs?

Where are test results recorded?

As releases increase, can current headcount still keep up?

If you can still keep up, is it because business scenarios are too simple (naturally limited test cases), or because you haven't maintained test cases (artificially limited)?

The former is dictated by business nature. Product quality problems caused by the latter are self-inflicted.

Today's article mainly explains how to do online test case management, with some tool introductions.

First, let's clarify the scope of test management. What does test management include?

In my view, test management at minimum includes: test case management, test case review, test plan management, bug creation and tracking, and linking test cases to requirements.

Creating Test Cases

This is the foundation of all testing activities. Without test cases, it's hard to ensure test consistency. If there are no test cases at all, it can be considered perceptual testing. Conclusions vary based on each person's perception. So for a rigorous engineering project, test case management is essential.

How should test cases be created? Some teams create test cases offline in Excel or Word. Many teams create test cases using mind maps. Mind maps are a great tool—their biggest advantage is continuous thinking. Test engineers can start from a test point and keep extending. This thinking style is similar to how product managers think about products and how developers solve problems. For product engineers, they start with an idea and derive various usage scenarios.

For a developer, they start with implementing a function—for that function, they might write several functions, each with multiple branches. This is naturally a tree-like thinking pattern. So mind maps are perfect for writing test cases. Many teams use mind maps to "draft" test cases, but after drafting, they still export them into individual cases in Excel or other tools. This approach discards mind maps' biggest advantage: continuous thinking. Why do these teams convert mind maps back into itemized lists? Because mind maps are good for writing test cases, but can't execute them.

Based on this scenario, we developed a new R&D management tool called MappingSpace. In this tool, mind maps are test cases—they carry all the information test cases need: preconditions, test steps, expected results, and customizable fields.

Test Case Review

In many teams, this step isn't valued, or it can't be implemented effectively and just becomes a meeting formality where few errors are found. Actually, investing review time in test cases is a low-cost, high-return activity. If we can find incomplete test scenarios or incorrect test cases—even discover incomplete code branch scenarios—during test case review, we avoid a lot of mistakes and save time.

For example, an incorrect test case leads testers to think they found a bug, but it's actually due to inaccurate requirement understanding—wasting both tester time and developer time analyzing the issue.

Another example: incomplete test cases mean some scenarios or branches aren't tested. Once such issues reach the market or customers, rework costs are enormous, and the impact on brand reputation is huge.

For example, in our team's test case reviews, we often find extreme scenarios that developers or product engineers didn't consider, allowing them to supplement in time (this is also an advantage of TDD, test-driven development).

If we can effectively review test cases before execution, we greatly save team time, improve software quality, and reduce costs.

How should test cases be reviewed? One way is itemized review like Excel. Many online test tools simply move offline Excel online, and review happens case by case. This approach isn't great—it also abandons continuous thinking. Test cases are written in mind maps, and mind maps have continuous logic, so reviewing based on mind maps makes it easier to find defects or omissions in each branch. So we still recommend reviewing test cases directly on mind maps.

After test cases are reviewed, we create a test plan. A test plan might target one iteration or a major version. In the test plan, we add many test cases. Since test cases are managed in the system, you only need to select test cases matching the requirements being tested. If requirements and test cases are already linked, the system automatically adds test cases, avoiding human omissions.

Test Plan Execution

First, we need to assign a test plan owner. A test plan might have hundreds or thousands of test cases. Execution can be done case by case like Excel or most online test management tools. This approach has two drawbacks: first, execution efficiency is too low—clicking one by one, no batch operations. Second, it also abandons the test case author's thinking. If test executors follow the test author's approach, efficiency is very high (it's the normal way people think: click A, see result A1, then click B, see result B1), and all test cases are quickly memorized (practice makes perfect). It's like peeling an onion: from outside in, layer by layer—not peeling here and there randomly. During testing, this jumping-around approach easily causes scenarios to be missed.

During test execution, defects are inevitably found—this is when we create bugs.

Creating Bugs

Test management tools also need bug management (another drawback of offline tools: creating and tracking bugs is too complex). In MappingSpace, during test case execution, you can directly create bugs, easily linked to the test case. If test cases are already linked to requirements, you can see coverage reports in test reports. Coverage reports show: what requirements were tested, what test cases looked like, which bugs were found against those test cases, and whether those bugs are resolved.

V-Model

At this point, testing is done (of course, with version regression, there are various regression tests). In the automotive industry, we sometimes need to look at the V-model. In the V-model, test cases are divided into: software unit testing, software integration testing, software functional testing, system integration testing, and system functional testing.

We need to clearly indicate to users which type a test case belongs to, and whether it tests requirements or architecture. In MappingSpace, this V-model perspective is naturally supported.