About planning test
Author: Jackeichan@gmail.com)
The goal of testers is to find defects as soon as possible and ensure the true solvement of defects. A good test plan can better help testers grasp their work.
First make a concept - test plan.
The test plan here, the plan is to use as a verb instead of noun, or it should be called "Plan Test" is more appropriate, with the focus of the plan for the entire test project, and the "test plan" that usually understands is only used to record the final The document of the result. It is said that it is a "plan test work" instead of "preparation test plan".
Plan testing is usually the first task that starts testing work. Generally, it should be done by engineers or test managers with rich test experience in the team, and do not recommend testing newcomers. However, novices can help organize some of the information needed for some plan tests, or you can know which information for planning test work, to look at the test problem in the future. In addition, the test novice can also work out to develop their own test tasks and plan their own work by helping to organize materials. It is also a good exercise.
I don't know if someone will look at the above content will say: I said so much nonsense, what is the test plan? I think that the ultimate goal of plan test is to communicate!
Some people think that the plan test is to facilitate the arrangement of your own work, but it can also have this role. However, in the actual development process, it is generally carried out by multiple teams to complete the work, and the test work will not exceed the one ring in this process. In the process of planning testing, testers should clarify the scope, methods, resources and progress of the test, and clarify the features that are being tested, and the person in charge of each task, and the risk of testing. The definition of these content is to illustrate the intention, expectations, expectations, and understanding of the tasks to be executed, finally associated with the development department (or department of customer support, etc.) and identify.
Below is some of my questions and experiences I think when I have developed test programs. Of course, because the plan itself should be a dynamic process, it is found that the following problems do not apply, reduce, or adjust it when it is not suitable for specific operations. However, it is important to note that the list of questions under the final determination should be discussed in the project group, and communicate between different departments, eventually agree. In addition, it is limited to my own experience, and these issues cannot be guaranteed to be suitable for all items, but only some common needs, many specific work issues, everyone still wants "everything from actual start", Think more.
1. What is the purpose of the plan test process?
I have always advised the way to make what I want to see, and then clear what I want to do for this goal, and then make what to do, these for the plan test. If you can't find the reason for the plan test, then don't be too strong in this.
With regard to the purpose of the plan test process, my point of view has been described above - for communication. In order to better work, the test department needs to be recognized and supported by various departments.
2. What is the product and version you want to test?
Many friends will say: Now our project management is very confusing, and there will be new versions throughout the test, and the test work is too passive.
If this is true, then consider introducing a perfect version management method. Because I have been engaged in some major projects, I have already eaten the hardship for the version iteration, and it is disorderly iteration. If you are unable to concentrate the testers and developers' attention to a version, then the mood and confidence will gradually fall.
3. What is the quality goal of the product?
It may be in a project, the boss, the market department, and the customer support department with developers, testers are different for quality, so it may argue. But no matter how it said that all departments must have a clear quality request, and propose an accurate definition for their requirements: request the response speed, it is necessary to clarify how many services per second; if it is stable, how many hours should be clearly needed? Do not have problems; require the defect level, it is necessary to clarify a level of bugs when using the system when using ... In the end, the test target must be explicitly adopted, so as not to determine the time of the test end and the program release.
4. What resources needed?
First of all, it is a problem. How many people do you need to test? What role is there? What is the responsibility of these roles? Who is responsible for the assignment? What kind of question should I look for ...
Here, it is recommended to consider the exchange of communication between each other: only a few people, can communicate effectively through oral ways in a big house; when the tester is too many, consider using some tools to facilitate contact.
In addition, the problem of testing the configuration environment. Where can I download it? Where is the test tool? How to solve the hardware needed? Where is the document? And the above question should be contacted ... These must be considered. If some resources are depends on other teams, they should also be clearly explicit.
5. What are the terms or nouns need to be defined?
It is also a key place here. When some concepts in the project are blurred, everyone has their own understanding, but it may bring a series of impact on the development of work.
6. What need to be tested, what don't need to be tested?
Here, if possible, try to explain the reasons for testing and no testing. Usually my approach is to test the part as a test demand, and no test is required as a test risk.
7. How to define a test phase?
During the plan test, the specific meaning, work content, and final delivery of the workpiece should be clarified. For the definition test phase, I think more is to form the coherence of testing, help you better accurately measure the test workload.
The concept associated with this is to enter and exit the rules. Each defined phase should have a clear entry rule and exit rules. There are two rules, you will be possible to find that the original definition is lost, and the test work is no longer coherent, but it has become a lot of uncomfortable single work; the test work has become far, no one I don't understand when I can end.
8. How do I define test strategies?
This is the most important part of the plan test process, it is recommended not to be completed by a newcomer.
Define the test strategy for the system test phase, and the questions consider have the following:
a. What test types are prepared?
Different software involved test types may differ. For these specific selections, it is recommended to refer to the contents in the RUP.
b. Different test types are ready to use different test methods and technologies? How to adopt these methods and techniques?
For example, are you ready to use a black box test? Do you need to consider a white box test? Do you need a test tool? Which is a manual test? Which automation tests are used? .......
c. Which factors may affect your test strategy? Will it lead to changes in strategies or impact policies?
9. How is the test progress?
Testing work is closely related to the work of other teams (such as development departments), interdependent. It is recommended that you must clear what factors must make a negative role in your progress, which factors should be active, which factors should be used as a necessary condition, and these factors have changed what effect. When determining the progress start time and end time, the relative date is used instead of the absolute date. 10. Do you need to specify the risk?
In actual work, the test work will be affected and restricted by many factors, and sometimes even restrict the completion of the test work. The tester must clearly point out the test risks in the plan, and discuss with other teams, gain consistent opinions, testers should make test risks as soon as possible to avoid panic in the later period of the project.
Finally, I have to say that in the actual test work, a test plan can be developed across the project; different test plans can be developed in different test phases; different test plans can be developed; they can also formulate different function modules. A test plan.
The choice of working methods is to be effective, and the actual work can have a beneficial impact.
Remind everyone to two:
1. Important is the planning process, not a document generated.
2. During the work, if you can't be done in your own scheduled progress, don't be afraid or frustrated. The role of progress is like a ruler, you keep using this ruler to measure yourself - which places need to be adjusted, which tasks need to be taken. Slowly, in the process of developing progress and implementation, you will be more and more easily grasping your work, even if there is an emergency, you can have enough ability to handle it.
Follow-up
This article was written in 2003. It has been more than a year. It has learned a lot of new things in his work. The level of writing has also improved, and I am honored to open in 2004 "Programmer" magazine. " Software Test Column ", in the past few years, the work experience into a" Software Test Practice "series of three articles published.
Thoughts, only in sharing and communication can really gain growth, welcome everyone to email, exchange software test related topics, joint progress, together.
Author brief introduction: (black body No. 3. Generally single, all kinds of information is optional, full respect for personal opinion)
Name: Chen Lei, Net Name: Jackei (Song Body No. 5 and Times New Roman No. 5, the following) The active promoters of software test engineers, software testing and software process improvement practices. I firmly believe that "practice is the only standard for inspection truth", and "'Innovation' is always more important than 'memory'", and is willing to do software test practices. Here is the details. Personal education and growth experience: graduated from a medical school in 2001, embarked on "IT is not returned", during the period of development work and more than two years of testing, now dedicated to software testing and software process improvement Innovation and practice of work. Expertise: Software Testing / Process Improvement / Software Engineering Methodology Research Current Work Dynamics: At present, a communication company in Guangzhou, Guangzhou, a person: http://blog.9cbs.net/jackei/ Personal blog : Http://www.cnblogs.com/jackei/msn: jackei_chan@hotmail.com-mail: jackeichan@gmail.com Personal Work Show, including Book Review: "Recommended Software Test Classic Books" Original Document: Please See my blog
