[100] Be a professional Tester

Similarly, testers may do the same job and make similar results. So what makes your work more professional? Test Work case writing, test execution, bug reporting, and function point test completion control. These aspects can reflect our labor value.

Test Case writing-when others do not want to write test cases, or even think it is a waste of time, if you realize that the functional points covered by the test case writing process are comprehensive. Then you are standing at a higher level than others. Down to each of the test cases, when someone else simply divides this into a test point, and you have a clear idea of the method used to divide the test point-such as the boundary value, equivalence Class. Then you are indeed more skilled than those who simply list test points. When someone else is busy with the test feature because the test feature is not comprehensive, if you can easily determine the quality of the tested Feature Based on the pass rate of your test case, you will know that you are standing on a higher level. These are all theories. To write test cases well and cover all of them, you need to think about them and think about them with an absolute dedication. It is a kind of creation. It is not clear if you copy the entries in the planning case. Instead, the functional points in the planning case are constantly divided until they are accurate to an input and output result. This is a process in urgent need of mental work. On the one hand, we must affirm the correct content in the planning case, and on the other hand, we must consider whether there are any abnormal operations on these normal content, the output of any exception is not allowed.

Test execution-not all use cases are accurate to the left and right mouse keys. Therefore, the test execution speed reflects the solid degree of basic skills of a tester. We also find that testers who are familiar with the system often perform tests faster than those who are not familiar with the system. But not familiar with the system itself is the quality of testers. There is no excuse. Since you are doing this, you are allowed to start to be ignorant, but you are not allowed to be stupid. If you want to stand out better than others, you should be familiar with your system. It is better to be clear to others and to know what others do not know.

Reporting of bugs-in fact, it is the process of clarifying the method of occurrence of the bug and the problems caused by the specific occurrence. The language must be concise, but not concise to others. The steps should be clearly defined, and the test should be performed continuously until the reproduction process of the bug is shortened to the shortest. It may waste a lot of time, but you need to see another benefit of this. When other testers followProgramWhen people repeat bugs and fail to find the key steps, you have a deep understanding that you need to get the attention of programmers. The shorter the bug steps, the more you can get the approval of programmers. This credit has been saved up to a certain amount of time, and it will become your own capital. The report on the test results is also very important. Clearly and clearly tell the program or Test director about the execution of the test cases and the problems to be solved-it is best to point out the source of your problem in the case. This makes it easy for programmers to view your use cases. Generally, Use Case Generation and program implementation are synchronized. In this process, if the program personnel finds that some test points in your use case are not implemented by themselves, it can save a lot of time. When the content of your use case appears many times, this deep memory will drive him to check your use case.

Control of the test time point-the test completion time of the function point can be preliminarily determined based on the difficult procedure for executing the test point in the test case and the number of test points in the test case. At first, this is accumulation. When the number of use cases reaches a certain level, it is easy to control the time point when the difficulty of use cases is compared with that of other use cases. The best time to control is not the expected three days, but the actual test is only one day and a half, not the expected three days, the actual test is five days. The best time should be within half a working day. It is also important for testers to control the test time. Sometimes, if you want to finish the test with just a few more people, you cannot delay the version release because of time points.

In addition, the above is a summary of personal leisure time and does not have reference value. If you are interested, you can read the information and feel free to speak. However, personal attacks are rejected. After all, this is also a newbie. The Section is a two-year old test. It is not a good way to make yourself look conceited to combat the enthusiasm of new people.

Copyright statement: original works can be reproduced. During reprinting, be sure to mark them as hyperlinks.ArticleThe original source, author information, and this statement. Otherwise, legal liability will be held.

This article is from adinqueen's 51testing software testing blog: http://www.51testing.com /?

89706