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

　　Domain experts may be hard to find. Try to find a few. And hire testers who are quick studies and are good at understanding other people's work patterns.

　　领域专家可能不太好找。尝试去找几个。聘用那些能够快速学习并且善于理解他人工作方式的测试员。

　　Two groups of people are readily at hand and often have those skills. But testing teams often do not seek out applicants from the customer service staff or the technical writing staff. The people who field email or phone problem reports develop, if they're good, a sense of what matters to the customer (at least to the vocal customer) and the best are very quick on their mental feet.

　　有两组人员比较容易找并且常常具备这些技能。但是测试小组经常不从客户服务人员或技术文档写作人员中寻求申请人。通过邮件或电话解决问题报告的人，如果是称职的，那么他们知道对于客户(至少是电话中的客户)来说什么是重要、最好的，这种感觉对他们将有所帮助。

　　Like testers, technical writers often also lack detailed domain knowledge. However, they're in the business of translating a product's behavior into terms that make sense to a user. Good technical writers develop a sense of what's important, what's confusing, and so on. Those areas that are hard to explain are often fruitful sources of bugs. (What confuses the user often also confuses the programmer.)

　　像测试员一样，技术写作人员常常也缺乏详细的领域知识。但是，他们的工作是将产品的特性以对用户有意义的方式转换出来。一个好的技术写作人员有培养出一种什么是重要的、什么是令人迷惑的感觉。那些难于解释的领域经常包含了很多的测试错误。(使用户感到迷惑的地方同样也会使程序员感到迷惑。)

　　One reason these two groups are not tapped is an insistence that testers be able to program. Programming skill brings with it certain advantages in bug hunting. A programmer is more likely to find the number 2,147,483,648 interesting than an accountant will. (It overflows a signed integer on most machines.) But such tricks of the trade are easily learned by competent non-programmers, so not having them is a weak reason for turning someone down.

　　没有选择这两组人员的一个原因是坚持认为测试员都应当会编程。编程技巧会给搜寻 bug 带来一定的优势。与财务人员相比，程序员更有可能发现数字2,147,483,648是有趣的(这个数字在大多数机器的有符号整数中溢出。)但是这种技巧很容易被有能力的非程序员掌握，所以这是不录取他们的一个不充分的理由。

　　If you hire according to these guidelines, you will avoid a testing team that lacks diversity. All of the members will lack some skills, but the team as a whole will have them all. Over time, in a team with mutual respect, the non-programmers will pick up essential tidbits of programming knowledge, the programmers will pick up domain knowledge, and the people with a writing background will teach the others how to deconstruct documents.

　　如果你按照这些规则招聘员工，你就会避免一个缺乏多样性的测试小组。所有的成员都会缺乏某些技能，但作为一个整体，小组应当具备这些所有的技能。随着时间的推移，在一个互相尊重的的小组中，非程序员将获取一些最基础的编程知识，程序员将获得专业领域知识，而具有写作背景的人将教会其他人如何解构、拆析文档。

　　All testers - but non-programmers especially - will be hampered by a physical separation between developers and testers. A smooth working relationship between developers and testers is essential to efficient testing. Too much valuable information is unwritten; the tester finds it by talking to developers. Developers and testers must often work together in debugging; that's much harder to do remotely. Developers often dismiss bug reports too readily, but it's harder to do that to a tester you eat lunch with.

　　所有的测试员——尤其是非程序员——会被开发人员和测试员在物理位置上的隔离所困扰。开发人员和测试员之间和谐的工作关系对于有效测试来说至关重要。太多有价值的信息没有记录下来;测试员在与开发人员交谈时发现了它。开发人员与测试员必须在一起工作以排除 bug ，远程实现是非常困难的。开发人员常常随意关闭一个 bug 报告，但是对一个一起吃午餐的测试员的报告却很难这样做。

　　Remote testing can be made to work - I've done it - but you have to be careful. Budget money for frequent working visits, and pay attention to interpersonal issues.

　　远程测试也能达到目的——我就这样做过——但你必须很小心。经常进行工作访问的资金预算，并且要注意人际关系问题。

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