主题三：人员问题
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.)
但是不利之处超过了有利之处：新雇员迫不及待地要离开测试行业。这很难产生高质量的工作。你可能会争辩说测试员为了“被释放”，必定会好好工作。不幸的是，过程给人留下的印象常常像结果一样深刻，严厉的活动——特别是为了证实具备程序员资格的活动——变得过时了。结果，缺乏经验的测试员所做的事情就像一个局部可编程编辑器专家或是一个复杂的自由软件工具专家所做的事情一样。这些虽然与测试无关，但至少还有潜在的作用。更危险的是误导了测试活动，即测试自动化。（参见最后一个主题）
Even if novice testers were well guided, having so much of the testing staff be transients could only work if testing is a shallow algorithmic discipline. In fact, good testers require deep knowledge and experience.
即使新测试员很好地获得指导，除非测试是一个浅显的算法学科，否则将这么多测试人员转换工作也是不可行的。事实上，好的测试员需要深入的知识与经验。
The second classic mistake is recruiting testers from the ranks of failed programmers. There are plenty of good testers who are not good programmers, but a bad programmer likely has some work habits that will make him a bad tester, too. For example, someone who makes lots of bugs because he's inattentive to detail will miss lots of bugs for the same reason.
第二个典型错误是从不合格的程序员中招募测试员。有很多好的测试员都不是好的程序员，但一个不好的程序员的一些工作习惯可能使他也会成为一个不好的测试员。例如，一个因为不注重细节的而产生很多 bug 的人也会因为同样的原因而漏掉很多 bug 。
So how should the testing team be staffed? If you're willing to be part of the training department, go ahead and accept new programmer hires. Accept as applicants programmers who you suspect are rejects (some fraction of them really have gotten tired of programming and want a change) but interview them as you would an outside hire. When interviewing, concentrate less on formal qualifications than on intelligence and the character of the candidate's thought. A good tester has these qualities:
那么应该如何招募测试团队呢？如果你愿意成为一个培训部门，可以继续接受一些新程序员。接受一些你怀疑是被其他人舍弃的程序员申请人（他们之中确实有一些人是厌倦了编程而想有一些变化），但是像从公司外面招人一样面试他们。在面试的时候，重点集中于应聘者的智力和思想特征而不是表面的资历。一个好测试员应该具备：
· methodical and systematic.
· 有条理、有计划。
· tactful and diplomatic (but firm when necessary).
· 有策略、说话办事得体（但在需要的时候要坚定）
· skeptical, especially about assumptions, and wants to see concrete evidence.
· 怀疑能力，特别是关于假设的，并要看到具体证明。
· able to notice and pursue odd details.
· 能够注意并跟踪奇怪的细节之处。
· good written and verbal skills (for explaining bugs clearly and concisely).
· 良好的书面和口头表达技巧（可以清楚、简洁地解释 bug ）。
· a knack for anticipating what others are likely to misunderstand. (This is useful both in finding bugs and writing bug reports.)
· 能够预料到其他人可能会误解什么的能力（这在发现 bug 和编写 bug 报告时非常有用）
· a willingness to get one's hands dirty, to experiment, to try something to see what happens.
· 愿意不辞辛苦地进行实验，尝试一些事情来看看会发生什么。
Be especially careful to avoid the trap of testers who are not domain experts. Too often, the tester of an accounting package knows little about accounting. Consequently, she finds bugs that are unimportant to accountants and misses ones that are. Further, she writes bug reports that make serious bugs seem irrelevant. A programmer may not see past the unrepresentative test to the underlying important problem. (See the discussion of reporting bugs in the next theme.)
特别是要小心避免测试员不是领域专家的陷阱。经常地，会计软件包的测试员对会计了解很少。结果是，她发现的 bug 对于会计师来说不重要，但又漏掉了很多对于会计师来说很重要的 bug 。而且，她编写的 bug 报告将使严重的 bug 看起来无关紧要。程序员可能无法透过不具备代表性的测试来看到底层的重要问题（查看下一主题中的关于报告 bug 的讨论。）
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.
远程测试也能达到目的——我就这样做过——但你必须很小心。经常进行工作访问的资金预算，并且要注意人际关系问题。
Some believe that programmers can't test their own code. On the face of it, this is false: programmers test their code all the time, and they do find bugs. Just not enough of them, which is why we need independent testers.
有些人相信程序员不能测试他们自己的代码。这显然不对：程序员一直都在测试他们的代码，而且他们也的确能够发现 bug 。只是发现的 bug 还不够多，这也是为什么我们需要独立的测试员。
But if independent testers are testing, and programmers are testing (and inspecting), isn't there a potential duplication of effort? And isn't that wasteful? I think the answer is yes. Ideally, programmers would concentrate on the types of bugs they can find adequately well, and independent testers would concentrate on the rest.
但是如果独立测试员也在测试，程序员也在测试（并且也在走查代码），其中不存在潜在的重复工作吗？这不是一种浪费吗？我想答案是肯定的。理想情况中，程序员应当集中于他们能够充分发现的 bug 类型，而独立测试员应集中于其他部分。
The bugs programmers can find well are those where their code does not do what they intended. For example, a reasonably trained, reasonably motivated programmer can do a perfectly fine job finding boundary conditions and checking whether each known equivalence class is handled. What programmers do poorly is discovering overlooked special cases (especially error cases), bugs due to the interaction of their code with other people's code (including system-wide properties like deadlocks and performance problems), and usability problems.
程序员能够较好地发现的 bug 是那些与他们预期不符的代码。例如，一个接受过一定培训、有一定积极性的程序员可以很好地找到边界条件，并且检查每一个等价类是否都处理了。程序员做的不好的地方是不能发现被忽略的某些情况（尤其是错误情况），不能发现由于他们的代码与其他人的代码交互作用而产生的 bug ，以及易用性问题。
Crudely put, good programmers do functional testing, and testers should do everything else. Recall that I earlier claimed an over-concentration on functional testing is a classic mistake. Decent programmer testing magnifies the damage it does.
大致来说，好的程序员进行功能测试，测试员应该完成其他所有工作。回忆一下我前面曾说过，过分集中于功能测试是一个典型错误。合格的程序员测试夸大了它产生的破坏。
Of course, decent programmer testing is relatively rare, because programmers are neither trained nor motivated to test. This is changing, gradually, as companies realize it's cheaper to have bugs found and fixed quickly by one person, instead of more slowly by two. Until then, testers must do both the testing that programmers can do and the testing only testers can do, but must take care not to let functional testing squeeze out the rest.
当然，合格的程序员测试相对较少，因为程序员既没有接受过培训，对测试也没有热情。但是随着各个公司意识到由一个人发现并修复 bug 成本较低，这种情况也在逐步改变。在此之前，测试员不但必须完成程序员可以完成的测试，还要完成只有测试员才能完成的工作，还必须小心不要让功能测试挤占了其他测试。
