The key to preparing a test plan and test cases !!!

The problem is as follows:

In the test process, the test plan is the arrangement of the entire test activity, while the test case is the guidance of the test execution. However, at present, many testers still do not realize the importance of the test plan and test case. In the case of tight project time, the plan and use case often become something of the form, what do you think of even some testers performing test activities completely based on their own experience when they leave the test cases?

This is a very good question, and it is indeed a question that many people have been excitating. For me, I have been struggling to find the answer to this question. Now I cannot say I have found it completely, I can only share my experiences with you. I hope that your testing plan and test cases will no longer be a decoration.

(1)Let's talk about the test plan first.

As magic_zhu said, many testers are not aware of the importance of the test plan. In many cases, the root cause of the failure is the lack of enforceability of the test plan, as a result, the next write plan is very hasty, or even not written. Even if it is written, it is a waste of money to deal with the leadership. This forms a vicious circle. Over time, the test plan is purely a decoration, many of our practitioners do not write test plans. The reason is that they cannot follow the plan anyway. This is really ridiculous. This is a typical reason for waste of food, because your plan is not written due to poor execution? In this way, you can only make the test even more out of control, so that your test process is completely unscheduled, untargeted, and becomes a laissez-faire status, completely uncontrolled. Such product quality assurance is obviously empty talk.

I think the solution to this problem is not to write, but to write better, more effective, and executable. This is the key to the problem.

A good test plan is used to plan the test and guide the entire test process. Therefore, a good test plan can be used to guide the test. It is a description of manpower, time, resources, policies, and scope throughout the test process.

As a test plan, the three core elements are time, resources, and scope. (This sentence is taken from Microsoft's software testing training materials.) The time is when and how long it will take, and the resource is the human resources, machines, and other resources you want to call, the scope is what you want to test and the focus of the test. In addition to the three items mentioned above, there are also important projects such as strategy (specifically, how to test) and risk control (what emergency measures should be taken once there is a problem.

To make a plan practical, pay attention to the following aspects based on the author's experience:

A. The three elements mentioned above cannot be fewer

B. The test policy must be clearly stated, that is, how to test it.

C. If coordination is required by other personnel (departments), make it clear.

D. when estimating the time, manpower, and other resources required for testing, try to be objective, accurate, and leave room for it. In particular, estimate the development time and debug time, and perform test cases on your own, regression speed

E. each stage in the test plan should be clearly stated, and the input and output documents of the test stage should be clear.

F. The time period in the test plan should not be too long (it is best to use day as the unit). If it is too long, it will be fuzzy, so it is difficult to measure and check.

G. Be sure to have risk control, or else the plan lacks Enforceability

H. Organize PM and Dev for review instead of in the pocket after the plan is completed

I. keep updating the plan constantly. Remember: Every plan is dynamic, not static.

(2)Test Cases

Like the test plan, test cases often fall into the form of software testing. This is a pity. The basis of software testing is the test case. If the use case is abandoned, why do you do a good job of testing? This is ridiculous. However, in the actual test process, examples are not used in many cases. I think it is still a practical problem to use cases. Sometimes, the use cases may spread tens of thousands of words, and cannot be used in regression testing, I have written another article on how to choose a regression test case.

Next I will talk about the key to creating a good test case.

First, you need to do two things before using the case.

First, have a thorough understanding of the Program (requirements and architecture ).

Second, make a formal test design (preferably documented ). Then start writing the case. Generally, the steps for writing a case are the same as those for building a house. You should first build a framework and then fill in the materials. when filling in the materials, you should design the case based on your needs, the specific design method is the several (Zheng Lao's book is clearly written)

Generally, consider the following aspects when designing a practical test case:

A. Use Case management tools (this is very important. Never use word or excel)

B. Use cases must be updated in a timely manner (new ideas should be added and outdated requirements should be deleted)

C. classify Use Cases

D. Do a good job in case review. Consult related personnel before writing the case.

E. It is a good idea to write a pair.

F. Comprehensive, including functions, performance, compatibility, security, ease of use, and fault tolerance

G. Pay attention to appropriate Granularity