如果你要管理一群测试人员或与他们共事，理所当然，你得先要理解他们。与IT部门的其他同事相比，测试人员仿佛总踏在不同的节拍上。你或你的朋友认识在医院急诊室或手术室工作的人吗？那里有类似的现象：为应付难度高、压力大甚至令人沮丧的日常工作，医护人员通常拥有令人不寒而栗的奇特幽默感，而你也欣赏他们的这种行为。因为对你的健康和福祉来说，这绝对比医生痛哭流涕、双手颤抖着触碰你的内脏器官要好得多……
测试人员接受专门培训来发现并报告问题，他们通过发现和报告软件中的异常问题和存在的风险，进而帮助公司、开发团队、客户和最终用户。
那我们可以把测试人员比作是警察吗？那倒不见得，他们不会违法必究地“逮捕”任何人，尽管软件开发世界里完全可以制定出一定的法律。但不管软件质量多好（或者多烂），大多数测试人员都无权阻止它们发布。
他们的角色更像是顾问。实际上，让一个公司把测试人员放在“质量把关人”的位置，操作起来蛮困难的，也不太公平。所谓“质量把关人”，就是在软件发布前已将该软件看做是一件商品的负责人。大多数测试人员不能很好地权衡风险、必要性、市场需求和成本开销。想想看吧，评估和承担风险其实是项目管理者或公司管理层的任务。
测试人员清楚地知道不管发现和解决多少问题，软件代码里总还是潜伏着一些问题，所以他们一般不太情愿盖那个质检合格的红印。这就是说，要等到你的“质量把关人”确定软件代码里的问题已经被尽最大可能地消灭了——你的项目可能要旷日持久，通常从经济上来看肯定不划算了。
此外，到后来你很可能会要求测试人员脱离发现和报告问题的本职工作，而花时间去评估每个问题，考虑在影响决策的各个方面相比而言到底有多重要。他们甚至有可能因此失去其独特的视角和使命感——不再记录下被发现的问题，只依据他们的理解来判断“不够重要”的问题。这样他们的测试视角难免受到限制和约束。测试人员不是最终用户，不是市场专家，不是项目经理，不是厂商，不是会计，也不是行政主管，他们可以在项目风险方面给你非常有价值的信息，应该利用和尊重他们在擅长领域的顾问意见:那就是测试你的产品并找出问题。测试人员可以为定夺产品去留的决策团队贡献很好的意见，但是让他们承担整个决策团队的担子就有问题了。
有些软件问题，让项目经理疲惫不堪、气喘心悸、坐立难安，甚至彻夜难眠，但却让测试人员的生活变得兴趣盎然。显而易见，使命使然。
软件测试人员觉得他们是电影《星球大战》里所谓的“黑暗的力量”，经常搞笑说“来黑暗面吧——我们这儿有饼干吃哦”。他们觉得自己集电影里的叛军、戴黑帽子的坏蛋、印第安纳•琼斯（Indiana Jones）、杰克船长（Jack Sparrow）和福尔摩斯（Sherlock Holmes）诸多角色于一身。你从不知道测试团队自视为坏蛋，对吧？他们是来拆掉你的漂亮纸牌房子的，而且他们还相当享受这一过程。好的测试人员几乎都有点“臭脾气”，经常让人不爽。不过，他们从不会在已经部署的正式产品上做测试，他们应该会在产品发布之前测试过了用户使用场景X，他们告诉你哪里出错了，但你没听进去，对吧？有时候你恨不得想用棍子敲他们一下，特别是他们说对了的时候。
他们就是喜欢找缺陷（bug），很多可恶的缺陷对他们而言实在有趣。聪明的测试人员早就认识到其他非测试人员是无法理解他们和他们的幽默感的。还（遗憾地）发现他们的角色可能并没有被充分承认、理解和奖励，所以他们不太热衷与公司的其他人分享他们的独特视角。
在IT世界里，测试人员的工作是极为特殊的。在商业世界里有多少份工作是付钱让你直言不讳的呢？当唯一的“桃子”显然有些坏掉的时候，测试人员不应该是拿着工资却告诉你一切正常。可以想象，你的项目组或IT部门的其他成员可能会有些不合时宜的乐观情绪或自相矛盾的评论意见。不过，测试人员拿了工资就是要告诉你他们所了解的一切事实，甚至有时候他们会直白地说你的小宝宝很丑，还给出一系列论据。
管理一群测试人员或者与他们共事，理解他们的思维是很有帮助的，这包括你得明白工作上什么事情才能让他们情绪高涨、兴奋异常。
那么测试人员到底是什么样的人呢？如果只列举少量的关键特质，那么首要的一点是测试人员有好奇心。他们想弄清楚事物是怎么运行的；其次，他们喜欢动手实验，他们想知道尝试使用功能演示时不同的用户场景和实验会发生什么；再次，好的测试人员胆子比较大，他们不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功的问题解决掉。测试人员聪明，善于分析，善于学习。事实上，他们总是在学习，他们的工作性质要求如此。技术总是在变化，他们接到的每个项目或多或少跟上一个项目不太一样。有时候他们有很好的文档，有时候没有很好的文档，有时候甚至没有成文的文档。他们必须问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后得出正确的结论。测试人员一般不关心办公室政治，如果你发现一个测试人员特别精通此道，很有可能他的本职工作做得不是非常出色。当你的工作是发现和报告问题，要想玩好政治游戏是很困难的。经常有人责备测试人员过于直接、粗鲁、团队合作精神不佳等。其实不然，很有可能责备他们的人不了解或者没能意识到项目组中测试人员的角色，他们的工作不允许他们隐瞒任何“不方便说”的信息。
上述这些是测试人员好的特质，还有其他一些不那么好的特质，但也是大部分测试人员整体个性中不可分割的一部分，尤其对那些测试经验丰富的人来说。测试人员容易不信任人，这是从实践经历中学来的，别人总是告诉他们模块X不需要测试，或代码Y“没动过”，这种信息错的次数多到数也数不清了。所以就算你告诉测试人员草是绿的他们也要亲自过目才敢相信。测试人员是挑剔的，这个习惯也贯穿在他们生活的其他方面。他们的任务就是要发现和报告问题，这就是说如果你发给他们的电子邮件里有一个拼写错误，他们整个团队都会跳出来好心指出，甚至还有你（或者其他人）的其他错误。测试人员质疑一切，包括权威。一般来说想要用搞定其他部门的办公室政治手腕来欺骗或者算计测试部门可不容易，倒是告诉他们严酷的真相要来得好得多，这是唯一赢得他们尊重和信任的方法。
你可能认识一些并不具备前述特质的测试人员。不是测试团队里的每个人都算得上是测试人员，也不是每个具有测试人员头衔的人都算得上是个测试人员。有的人满足于运行已有的测试，他们没有擅长分析、好奇和喜欢动手实验的天性，他们的胆子不太大，很容易被强势性格的人、位高权重的人或要去做新鲜事情的想法所动摇。他们可能因为害怕人们之后的反应而不报告缺陷；他们主要的顾虑是不要坏了大局，有的人过于“热衷”办公室政治和关注个人的计划和成功，以致失去了让他们在测试团队中与众不同的那些很有价值的特质。总的来说，根据你的部门大小不同，不同性格的人都可以对项目的成功贡献力量，但是花力气去识别和培养你部门里“真正的”测试人才是值得的。
只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员。当一个测试人员需要运行一大堆已有的测试用例时，容易心生厌烦，可能会尽快运行这些测试，只是想让它们从眼前消失。这意味着他们可能不会非常关注这些测试，当然也就不能像认真彻底的执行者一样找出某些问题。从好的另一方面来看，一个“真正的”测试人员一定会把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。如果原来的分析实在很棒，那可能他们也找不出来太多可以更新充实的内容，进而增加了无聊指数。你会发现，如果每天的工作就是按部就班，如运行一大堆已有的手工测试用例，日复一日，那些真正富有创造力、勤勉的、聪明的测试人员的精气神儿、自主性和创造力都会消磨殆尽。为了你的测试人员士气着想，无疑需要让他们把手头工作交给愿意每天按部就班做事的人，或把手工测试自动化，或者不要让他们再做这些事情。他们想做点新的事情，想发现和报告缺陷，想贡献其他人无法贡献的力量。
很多测试人员觉得单调乏味而不屑运行回归测试用例，你会发现他们其实大部分都理解甚至同意回归测试的必要性，但这就像是面对一道人家已经解决的谜题，一点探索和寻宝的乐趣都没有了。大多数测试人员知道回归测试只能找到代码里的一小部分问题，他们更愿意去寻找新代码里潜伏的一大堆问题，这完全就是探索和寻宝的乐趣之旅。
那么在态度方面，难道不应该团队协作吗？千真万确，你的测试人员也愿意扮演好团队成员角色，他们是想帮忙作贡献的，他们很希望自己得到欣赏，但是他们关注的东西让项目组其他成员难以接受和欣赏他们的贡献。他们的幽默甚至增加了让他们融入团队的难度。更糟的是，如果你在一个不关注质量的公司工作，并不认同或不解决测试人员辛辛苦苦发现的问题，测试团队会认为这是对他们以及他们的工作缺乏尊重。如果你不给予测试人员他们应得的尊重，很快就会让他们士气低落，然后你就很难留住具有本土市场上热门技能的人才。
总的来说，现在整个测试业界已经相对成熟、文明有礼了，测试人员变得更能与人“和睦共事”。最有经验的测试人员会同情地拍拍你的肩膀说：地球人都知道事情不仅仅是发现问题那么简单。他们也会充分理解、全力支持你的决定：问题A、B、C可以不解决了，不会有人就此激动万分大发雷霆的。实际上，拥有多年工作经验的测试人员会说出你所喜闻乐见的意见，因为他们从这家公司的项目经验中学乖了，知道这样会给他们（当然也就是给你的部门）带来最好的质量结果。但是需要记住，他们之所以肯牺牲问题A、B、C，很可能是为了说服你解决更严重的问题D和E。大多数测试人员私底下希望你解决他们找到的所有问题，测试人员很明显会偏向于把问题都解决掉，他们看见出错的东西，就想改进它们。想想吧，你真的希望测试人员不这么想吗？
一般来说，经验丰富的测试团队能用漂亮的包装纸（词汇）和丝带（对于问题的理解）来呈现一个缺陷，过了好一阵你才会意识到自己收到的是一大堆恶心的牛粪。他们也不过是转赠而已，是你先给了他们这样的东西，不知何故你给他们的时候没有发现这玩意儿真的是相当臭。他们用礼貌的政客语言跟你讲话，这跟在你耳朵听不到的场合（如在牧场跟其他牛仔侃起大山时）说的话可是完全不同的。他们在痛苦的经历中学到，与其共事的其他领域的“家伙”是不能真正欣赏他们这种幽默和乐趣的：在地里系统全面地搜寻牛粪，然后用系着大红蝴蝶结的漂亮彩盒子装起来送给项目组……搜寻软件毛病（缺陷）很像寻宝之旅。缺陷通常是藏起来的，要找到它们需要同时具有逻辑、技术和直觉（或者说运气）。很多测试人员都很喜欢谜题，这并非偶然。他们就喜欢搜寻和发现东西。寻宝令人兴奋，发现一个错误（或者说答案）是终极动力。当测试人员发现缺陷之日，就是他们赚取酬劳之时。在他们看来，那意味着最终用户不会发现的问题多了一个，开发团队改进产品的机会多了一个，公司的风险因素少了一个。找到一个缺陷就是一个值得欢呼雀跃的意外收获。开发团队或管理层认为是令人不爽、厌恶、沮丧的没解决的问题，对测试人员来说却是美妙的事物，是埋藏的宝藏，是达布隆金币。
不同的测试人员为搜寻缺陷做着不同方面的准备。他们的准备工作取决于你的环境和研发方法，一些准备工作源自个人偏好，他们可能提前开始写测试用例，也可能从一个笔记列表入手。但是不管技术方面怎么样，有些事情是各种技术都共通的。
他们要阅读一切帮助了解测试目标的资料，要问问题——很多很多的问题，一直问到他们满意觉得足够了解该应用程序为止，然后他们要决定如何最好地进行测试并制定一个计划。这个计划也许很正规，也许只在他们的脑子里，但大多数测试人员在开始测试之前就知道他们想要检查什么，在开始实验的时候也大致知道系统应该是什么样以及如何工作。
这就是技术、培训、经验发挥作用的时候了。一个受过培训、经验丰富的测试人员总是比缺乏培训、经验不足的人找到更多的错误。这与智力无关，只是缺乏指导和学习。这也不是说新人就会一无所获，他们也能发现一些东西，但是经验丰富的测试人员知道哪里容易发现缺陷，什么容易出问题，他们还从经验中学到在类似的情况下哪种技术曾成功地帮他们发现缺陷。一个测试人员是否受过“正规的”培训（边界分析等），或敏捷技术培训（启发式、游历式等），或者两者都学过，并不那么要紧。一旦测试人员学会阅读字里行间暗藏的玄机，观察显而易见之外的事物，询问一针见血的问题，以及眼界的扩展，你就成为了一名真正的测试强人，通过继续学习和掌握新的工具，你的力量将随着职业生涯不断增强。
聪明的项目组懂得利用上述所有的知识和直觉。有经验的项目经理通常在项目早期就让测试人员参与进来，这可不是空虚寂寞，想找人来陪着开会。他们希望这些测试专家在流程早期向他们发问，这样可以更快更容易更廉价地消除差异。他们希望开发人员注意测试人员要测试的方面以便开发出更好的代码。测试人员的这种能力经常帮助项目组在设计瑕疵变成缺陷以前就发现出来。
不夸张地说，数十年前就有关于测试人员角色的争论。一些人认为测试人员的角色是“保证质量”，如果有人能决定到底“质量”指什么，那么这也不错；另一些人认为他们的角色是通过训练开发人员寻找缺陷帮助他们编写出更好的代码——开始编写的时候就不存在错误的编码；还有一些测试专家集中精力研究为何以及如何找到缺陷：在不同环境下寻找缺陷所涉及的策略、技术和术语。所有这些说法都很有趣的，在某种意义上也都是对业界有益的。
但是，从本质上来说，测试的意义就是发现缺陷。测试人员通过向项目组和管理层展示缺陷、问题或瑕疵来“保证质量”，进而帮助他们做出更好的决策；他们通过向开发人员展示其代码中的错误，使其知错就改引以为戒，进而帮助他们改进工作；他们学习新的策略和技术以便发现更多（或者更重要的）缺陷，他们把工作归类到新的策略里，如游历式，进而帮助其他人发现缺陷。如果在测试过程中没有发现（或者只发现了很少的）错误，那么这也是重要的信息。
不过所有的测试人员都会告诉你，缺陷是存在的，然后缺陷就真的存在了。一般来说，让事情变得好玩的并不是缺陷的数目。比如一个测试人员可以在大的网站应用程序中发现上千个表面错误，什么是表面错误呢？它就是拼写错误，给用户看的文本有语法错误，图标上颜色不对，或者屏幕上有东西位置放得不对。
测试人员比其他任何人都讨厌这类错误，特别是当他们发现千万亿个（在测试领域这就是“许多”的意思）这种错误的时候。记录下这类错误比发现它们的时间还要长，而且它们难免是低优先级的错误。从积极的一面来看，它们一般易于解决，很快就被修正好了。
你可能不清楚究竟有谁在乎这些表面错误，但是在IT领域工作过一段时间的人可以告诉你，某个应用程序的最终用户可能会对你觉得微不足道的问题深切关注，也许这跟称为“烦恼因素”的东西有点关系。当然，字段的标题或仅供参阅的文本里的拼写错误可能当时并不会让人太不爽，项目组的所有人也都同意其严重级别大致跟一点小污垢相当。但是对于每天要看两千遍的用户来说，“烦恼因素”是非常高的。项目组经常不能理解一个从功能上来看很小的问题为什么会是最终用户的大难题。让我们来看一个导航的例子——在屏幕上做简单的切换标签页的动作，如果现在完成一个功能要比以前多花25%的时间，或要多敲三下键盘，你可能就会触及最终用户的利益。他们的工作、奖金或工作组的成果有可能是他们评估流程中参考的一种标准。如果你的改动让他们的成果减少了，他们当然有理由认为这个问题是紧急的。
所以测试人员报告他们发现的一切东西，其中经验丰富的人员会根据其理解来报告严重程度，但一般来说不要试图预测业务优先级。他们理解中的业务优先级通常就像开发团队理解的一样，是不太完整的，并不是基于用户的个人体验做出的。有时候，约束自己不要“为用户说话”可能会淹没个人的意见。经常有用户愿意“将就”使用有严重错误的代码，却在最后一刻强迫要求修改或者添加看起来并不重要的东西。你能怎么说呢？这是他们的决定。在这种情况下你能给测试人员的唯一建议就是随它去吧。
如果最终用户愿意采用折中的办法来应付严重的问题，那是他们的决定。想要预测他们想要什么和不想要什么一般是不太现实的。测试人员的工作是寻找、发现、报告，而不是用像神一样的能力去评判，测试人员应该随心所欲地提供他们的专业意见；事实上，项目组的所有人都应该随心所欲地提供专业意见。不过，最终需要权衡对用户影响的人，还是用户自己。对于产品是否达到发布标准的争执意见，需要上升到公司管理层，管理层的一部分工作就是为公司评估风险、做出重大决策。如此说来，测试人员就应该是（通常实际也是如此）偏向于改掉缺陷的。
业界有一个令人遗憾的现实，那就是测试人员不将他们发现的所有错误报告出来。原因可能有很多，但最常见的是他们觉得报告某一种或某一类错误没有意义，因为反正都不会被解决的。这是从实践中“学”来的，你通常会发现有这类态度的测试人员不抱幻想、厌倦、愤世嫉俗、对工作不感兴趣。他们报告缺陷的兴趣和热情已经被工作环境慢慢消磨掉了。另一个原因也许是他们相信从政治上和实际上来说，报告他们发现的一切东西是不“聪明”的，他们应该只报告那些公司在乎的东西。那么，如果公司看不到整个大局，怎么知道在不在乎呢？每个人都明白很多错误是不能（或者从财务的角度来说不应该）在产品发布前解决的。成功项目管理的“艺术和工艺”的一个要素是对推迟和解决哪些缺陷做出正确的决策。比如，项目组决定解决14个缺陷，推迟另外32个。但是测试人员选择不报告324个缺陷，因为开发团队“从不解决”字段错误，这意味着项目经理和上层的管理者正在根据错误、不全面的信息作决策。在这个例子里，用户界面就不能在万众瞩目的黄金时段隆重登场。
另外，就算是在一个并不解决某类错误的公司，报告每个错误也可能会最终改变公司的政策（或称之为“一直实行的陈规”）。如果一个测试人员报告了40个错误，一个都没解决，应用程序就发布了，然后用户以紧急的优先级报告同样的错误并要求尽快地解决它们，那么开发团队和项目经理以后就会开始注意这类缺陷。不过总的来说，报告表面错误很耗时间，大多数测试人员对此提不起兴趣，他们这么做只是因为这么做才能提供一个完整和准确的应用程序情况的大局，也因为这些错误可能对最终用户来说尤为重要。
那么什么样的缺陷是让测试人员不枉此生呢？那就是难以处理的缺陷：会严重影响最终用户进行工作的复杂错误；会严重影响某些后续操作的微妙错误；让应用程序瘫痪的错误。（“瘫痪”是测试领域的又一个“科学”术语，表示就要像死鱼一样肚皮朝上了。）为了理解“恶心”错误的实质，我们需要了解一些开发流程。
一个典型的图形化用户界面、用户界面或屏幕上的错误一般是某种失败的结果，要不就是有人漏掉了什么东西，或误解了用户的需求，或错误地解释了用户需求，或只是拼错了单词，这种错误通常很容易发现，很容易再出现，也很容易解决。
不过除此以外，事情变得复杂而有趣。开发人员经常在他自己的一块代码自留地里干活，那部分代码可能会被其他很多代码调用，提供数据给其他的模块、应用程序或某数据库。考虑到在开发人员写代码的时候，即将与之交互的其他代码也在开发中，这就意味着为了测试代码，开发人员可能得“伪装”（模拟）那些他们该接收的输入，并提供这些数据给一些假的实体，尽量检查最终结果。
这样做的问题是实际接收到的数据可能和期望有所不同，考虑到项目生命周期里的许多变化，某部分代码的数据输出也许最后就不是另一个后续实体能使用的格式了。所以即使是一个出色的开发人员，单元测试做得很好，在跟其他人的代码交互时也有可能遇到这种错误。
通常测试人员正是在这种场合（代码和应用程序之间交互的场合）发现大部分最重要的错误。从这当中我们可以学到几件事情：
第一，测试人员一定会从理解一个系统的虚拟设计中受益，他们可从中得知着力何处，指出错误最可能的“藏”身之处。
第二，测试人员明白在他们根据谜题的给定部分走遍整个迷宫之前测试不会“完成”。这是什么意思呢？假设我开发了一段代码，作用是从用户那儿搜集信息，处理之后存入数据库，那么作为一个开发人员，我就测试我开发的内容，检查我的数据在数据库里每个字段都存得好好的。让我想不到的是，测试人员在我的代码里发现了37个缺陷。这究竟是怎么回事儿？很有可能在我的测试里我只试过了“好”数据，既没有时间也没有热情去破坏我自己的东西。我可能没有充分理解最终用户会怎么对待这些数据，也可能没有正确地处理这些数据，可能存在数据库里的数据不能被其他程序以正确的格式读取。
那些跟我的程序交互的程序可能没有想到我提供的数据格式是这样的（或预期某个字段是空的），这样错误就在后续程序中出现了。当用户拿到我“处理过”的数据时，也许没有按照他们要求的格式显示，这就需要改我的代码、数据库和读取数据的代码。
测试人员不像开发人员，他们彻底充分地测试，从头至尾。这并不是说有限的测试或单元式的测试毫无用处，而是指他们认为在将某条信息从头到尾走过一遍流程之前是无法确认测试“完成”的。
好的测试人员同时是富有创造力和想象力的。测试通常是一个破坏的过程，正因为如此，在正式产品环境下运行测试需要非常谨慎的决策。好的测试人员不必试图证明软件运行正常，他们是来证明软件不能正常运行的。这一态度差异是测试人员能发现如此多缺陷的主要原因，他们就是想发现缺陷。他们分析手上所有的信息，坐下来思考怎么才能破坏应用程序。项目组里没有其他人有这样的使命。开发人员一般甚至没有足够的时间持续写代码，更不要说试图挤出足够的时间来想怎么破坏代码了。最终用户通常只是执行日常工作的操作，如果有东西“坏掉了”，他们可能陷入恐慌和沮丧之中。另一方面，只有测试人员勇敢地参与进来，使出吃奶的劲儿踢轮胎，如果有轮胎爆掉他们就开心死了。要是一个车门掉下来，或他们的无影脚把引擎踢坏掉，他们就更开心了。
这正好应验了妈妈一直告诉我们的话，要是你只盯人身上坏的一面，那你就只能发现坏的东西。测试人员全面地盯着系统中出错的一面找问题，顺便也就检验了运行正常的部分。但他们关注的焦点总是向着错的东西，而不是对的东西。如果你对测试的唯一目标就是证明系统在完美条件下能按期望正常运行，你的开发人员会告诉你事实已经如此，这样你就可以省一大笔钱了。啊，你不相信他们？你的测试团队也不相信他们。那么你怎么跟这些古怪的家伙共事呢？你怎么激励和团结他们融入项目组之中呢？你怎么鼓励他们发挥所长：发现和报告缺陷呢？
首先，承认和欣赏他们对公司和项目组的贡献，像对待团队的其他核心成员那样在项目早期就让他们参与其中。倾听他们说的话，注意他们在测试过程中发现的东西，当他们因为代码很烂或者代码推迟交付而工作得很晚的时候，帮助他们解决一些缺陷并拍拍他们的后背以示鼓励，在他们发现一个错得离谱的错误时试着叫出“哇——喔！”，这会向他们表示你“完全了解这个问题”，理解他们的工作和思路。当项目结束向项目组表示祝贺的时候，把他们的名字列出来，感谢他们的付出。如果他们的工作做得相当出色，给他们发一封电子邮件，同时抄送给他们的老板和你的老板。测试人员就像其他职员一样，他们愿意为懂得认可和感谢他们作出额外付出的人不辞辛劳、竭尽全力。你要承认他们选择测试作为职业是需要一定的勇气和承诺的。为了得到认可、尊重和成功，很多测试人员在职业生涯中花费了大量的力气。你无法通过上学去学习如何成为一个成功的测试人员，而只能在现实的磨炼学校中学习。更有甚者，很多IT专业人士认为：“是个人就能测试。”他们不认可最终用户、开发人员、文科学士和路人甲进行测试的区别，就算他们自己的统计数字清楚地表明测试人员能比其他那些人发现1000%还多的错误，这绝非巧合。你会拉路人甲来编程序吗？一样的道理，测试需要远不止是健康的身体和一点智力，它也是有技术含量的。你会发现如果对测试人员报以对开发人员、数据库管理员等人同样的尊重，就会促进建立一个能吸引和留住顶尖人才的测试团队。
如果你的职位允许，公平地奖励你的测试团队，待遇和奖励明显差于开发团队的测试人员一有机会就会跳槽到更绿的牧场，留下来的也愤世嫉俗、失去激情。也许很难让人相信，招到好的测试人员要比招到好的开发人员难得多，大多数能干的IT专业人士想做卢克天行者（Luke Skywalker），而不是达斯维达（Darth Vader）。在“黑暗的力量”你也需要些得力干将，因此你得尽力留住较强的测试力量。
如果你理解了测试人员专业化学习成长要遇到的问题，和他们对认可、尊重、成功的渴求，你就会投资于（或鼓励你的公司投资于）培训你的测试人员。软件测试是一个专业化的领域，在本文撰写之时，至少可以说标准学习机构出品的好课件很少。找一些能干的老师和专家说说他们的想法，扩展你团队的能力，把测试人员派去参加会议，促进一种学习的氛围，允许他们在小项目上尝试新的技术。
通过培训、认可和平等的奖励制度对测试团队表现出重视，你就会得到一个肯为你上刀山下火海的测试团队，他们还会把你的公司推荐给业界中和他们一样优秀的人才军团，并不需要有业界最高的薪酬待遇，你就可以吸引并留住精英中的精英。
那么，下次你的测试人员会因为代码推迟交付和代码很烂加班500个小时，找出1200个错误，其中40%都严重到搅黄产品的发布，告诉我……
这对你有好处吗？
呃，这对他们有好处，然而归根到底，对你的用户、你的公司和你的根本利益是有好处的。