On the 9CBS Forum, someone asked how to assess the test personnel, I have returned a few posts. Here is the content I reply, you can represent some of my thinking.
One: The work evaluation of the test staff is difficult because the testers do not have specific work products.
Test staff generally do is the submission of test cases and test defects. And these can be said that it is not a technique, but also looks at professional ethics. So I think more about that the most important thing for testers is the responsibility, I want to do test rather than what to develop. A tester proposes 1 question or puts up 10, which may not be as serious as everyone thinks. If you really want to assess, you can only use the work product assessment, the defects submitted are impossible for the goal of the assessment, because allocated modules, tester's perspective, developers' technical differences may cause considerable oscillation. Therefore, it is usually evaluated from the perspective of test cases. This can be changed to the test case.
Test cases can be said to be the most varied thing, because there is no strict standards and theory to explain the preparation of test cases (remember, it is test case, not something else). Moreover, testing is the work of software engineering, it is difficult to have a big time and energy to write detailed test cases, but the simply use case is not used, and only a probably thinking. Not suitable for the conditions and standards for assessment. So really want to assess, you can, put all the relationships of your unit, completely according to the software engineering way (RUP, CMM, etc., because the work is easy to measure), if not According to this, the test tester is not as good as the manager, it is better to shoot the head.
2: The above says, but the center is only one: I want to assess, I have to have a standard, so I should first think about whether my company has such a thing. If not, don't take it. Use the bug number to assess the test personnel, just like the number of lines of code to assess the programmer.
Three: Don't say testers now, the programmer has several companies that can make everyone satisfied with the assessment?
Testing should be said to be touched by the river, there is theory, but it is actually difficult. So I have repeatedly emphasized the responsibility of the tester, because the test work is almost impossible to measure, just like you wrote, do an hour and do 8 hours from work results, it is not very good to reflect. Why not do a few willing to do test, because the test is fortunate and bored, the salary is relatively small, and the results are always ignored. In fact, who is doing, so bad, everyone has a scales, as long as the manager can do a bowl of water, even if there is no practical comparison standard, everyone will not say much. Management is human, not machine, don't try to develop a perfect standard, even if there is, some people will not be convinced. As long as the heart is deserving, let others say it.
Four: I saw someone in the first two days, I feel very reasonable.
If the tester can participate in the needs, design phase, the test case is certainly easy to write, according to the standard software process. But now more, it is the development of the procedural development, which is handed over to the test personnel, so if the writing case is the problem, the other is not familiar with the program. So, true, write test use cases are somewhat unsuitable. The most common thing is that the test is completed, and the test use case (um, how to be the same as the programmer, despise yourself, haha), so generally to cope with the above and customer, can only be said to be a summary, because of the problem I have found it, naturally easily write cases according to the question, it can be more perfect. So I recommend writing test ideas, especially when there are multi-business processes, it is not easy to miss. As for the kind of idiot, you can find the test case of the problem. Anyway, we don't have this time and energy, and it is very much, I feel that the test is an art (and then despise myself), I found more intuition ( Perhaps it is a wrong operation), these are unable to express. If you want to write, you can write a simple, as the test is unfolded, and the familiarity of the program has gradually complemented. This test is almost the same, and the use case is basically written. The test case is actually the most difficult to master, and it is written to more details, and this is generally related to the test time.
