典型的测试错误有哪些？(8)

　　向每一个能够找到的人征询意见。从开发人员、市场人员、技术写作人员、客户支持人员和你能找到的每一个客户代表那里收集意见。查看[Kaner96a]以获得关于这种协同测试计划的描述。

　　2. Use historical data. Analyzing bug reports from past products (especially those from customers, but also internal bug reports) helps tell you what areas to explore in this project.

　　使用历史数据。分析以前产品的 bug 报告(特别是来自客户的，但也要包含内部 bug 报告)可以帮助你辨别在这个项目中还需要探索哪些领域。

　　"So, winter's early this year. We're still going to invade Russia."

　　“今年冬天来得很早。但我们还是要入侵俄国。”

　　Good testers are systematic and organized, yet they are exposed to all the chaos and twists and turns and changes of plan typical of a software development project. In fact, the chaos is magnified by the time it gets to testers, because of their position at the end of the food chain and typically low status. One unfortunate reaction is sticking stubbornly to the test plan. Emotionally, this can be very satisfying: "They can flail around however they like, but I'm going to hunker down and do my job." The problem is that your job is not to write tests. It's to find the bugs that matter in the areas of greatest uncertainty and risk, and ignoring changes in the reality of the product and project can mean that your testing becomes irrelevant.

　　好的测试员是有计划、有组织的，但他们受到计划，特别是软件开发项目计划的各种混乱、各种意外转折的影响，因为他们处于食物链的最后一环，而且通常地位比较低。一个不幸的反应是固执地坚持测试计划。从感情上讲，这会令人很满意：“他们可以随意胡乱摆弄，但我要坐下来做我的工作。”但问题是你的工作不是编写测试。而是在最不确定和危险的领域发现 bug 。忽略产品和项目的实际变化可能意味着你的测试变得无关紧要。

　　That's not to say that testers should jump to readjust all their plans whenever there's a shift in the wind, but my experience is that more testers let their plans fossilize than overreact to project change.

　　这不是说测试员在有任何变化时都应该匆忙地重新调节他们的计划，但我的经验是很多的测试员都让计划僵化而不是对项目变化起过度的反应。

　　主题三：人员问题

　　Fresh out of college, I got my first job as a tester. I had been hired as a developer, and knew nothing about testing, but, as they said, "we don't know enough about you yet, so we'll put you somewhere where you can't do too much damage". In due course, I "graduated" to development.

　　刚走出大学校门的时候，我得到了第一份工作：测试员。我是做为开发人员被录用的，对测试一无所知，但是他们说：“我们对你还不太了解，所以要把你放到一个你不能做太多破坏的地方。”在这个课程结束后，我“毕业”并加入到开发部门。

　　Using testing as a transitional job for new programmers is one of the two classic mistaken ways to staff a testing organization. It has some virtues. One is that you really can keep bad hires away from the code. A bozo in testing is often less dangerous than a bozo in development. Another is that the developer may learn something about testing that will be useful later. (In my case, it founded a career.) And it's a way for the new hire to learn the product while still doing some useful work.

　　将测试作为新程序员的过渡工作是组织测试人员架构的两个典型错误中的一个。这样做有一些可取之处。一是你的确可以使一些不合格的雇员远离代码。一个测试行业的笨蛋常常比一个开发行业的笨蛋的危险性要小。再有就是开发人员可能学习到一些以后有用的测试知识(就我而言，测试开创了我的职业生涯)。还有就是一个新手在了解产品的同时还能做一些有用的工作。

　　The advantages are outweighed by the disadvantage: the new hire can't wait to get out of testing. That's hardly conducive to good work. You could argue that the testers have to do good work to get "paroled". Unfortunately, because people tend to be as impressed by effort as by results, vigorous activity - especially activity that establishes credentials as a programmer - becomes the way out. As a result, the fledgling tester does things like become the expert in the local programmable editor or complicated freeware tool. That, at least, is a potentially useful role, though it has nothing to do with testing. More dangerous is vigorous but misdirected testing activity; namely, test automation. (See the last theme.)

原文转自：http://www.uml.org.cn/Test/200709289.asp