Swtbok test practice series (9) -- is the more detailed the design test cases, the better?

When a tester designs a test case, the first problem is whether the detailed steps of the test case are as detailed as possible? Or how do I grasp the detailed steps of the test case? There must be a lot of people who are in favor of detailed test cases on this issue, because detailed test cases can provide the following advantages:

1) testers who lack experience or skills can perform the test smoothly According to the test case steps. This is the thinking in script-based testing practice: experienced and skilled testers design test cases, while inexperienced testers perform test cases.

2) experienced testers who follow the detailed test case steps can not only help them understand the functions and business knowledge of the test objects, it can also help them understand the testing design technology and methods.

3) better consistency. Because the detailed steps are provided for the designed test cases, each tester can follow this step to obtain continuous test results, thus ensuring test consistency.

3) facilitates the automation of test cases. Since detailed test cases provide detailed steps and expected results, it is relatively easy to convert them into automated test use cases.

4) Sometimes a detailed test case is provided to meet the requirements of laws and regulations, especially for key security systems, when audited.

Although detailed test cases can have the above advantages, there are still many people who are opposed to detailed test cases, because detailed test cases will also lead to a series of problems:

1) high design cost: testers need to spend a lot of time writing test cases. At the same time, the more pages the test case document has, the less likely it will be to be fully read.

2) poor performance: it is impossible to exhaust the test. A good test case design selects reasonable test inputs, test combinations, and test data from endless tests, use a relatively limited number of test cases to achieve the ideal coverage rate. The detailed test case design makes it difficult to fully define these combinations and scenarios. In practice, the test design must be continuously iterated and updated.

3) high maintenance cost: Input reference of test cases. For example, the requirement documents are frequently changed, which leads to more detailed test cases and greater maintenance workload.

Therefore, there is no standard answer to the detailed requirements of test cases, although I am a supporter of lightweight test case design. Whether the test case is detailed or not is subject to various factors, such:

1) test objectives. The tester tests the target of the product or system. If the test case document does not support this goal, or does not help achieve this goal, the value of this test case design document will be much lower.

2) whether the test case document is a product or a tool. If the test case document is part of a software system or product, these documents need to be released to the customer. In this case, the test case document must follow a certain table as required by the customer. If they are only internal tools, they do not have to be too complete and neat, so they can help achieve the goal at a minimum.

3) Frequent software design changes. If the software design changes frequently, do not write many details into the test case document, because these details will soon become obsolete. In this case, do not write a large number of test case documents, they are modified or abandoned too quickly, it is not worth investing too much in the test case document.

4) The testing method used. If the current software development model is a linear model such as the V model, the testing method usually relies on pre-defined tests, at this time, detailed test case operations and maintenance documents are required. If exploratory testing is used, policy documents are needed. For example, the idea about a certain testing area is not a specific test case.

5) WHO to view the test case document. If the test case document is intended for new testers or inexperienced testers, they must be detailed enough to work properly.

Swtbok test practice series (9) -- is the more detailed the design test cases, the better?