大多数测试工作需要多重角色：主题专家、工具师傅、分析师等等。James Bach或许是北美最为知名的测试人员了，他曾经识别出七类软件测试人员，而且这些还仅仅是围绕活动的，未考虑类型或项目或技术！我刚刚开始工作的时候，我们有一支面向所有职能的“测试团队”。如今此类团队可能已经不存在了，公司更喜欢让单个测试人员融入到一支团队中，他需要所有的技能，而不仅仅是专业技能。尝试雇用无所不能的人，就等于与去找个“玉麒麟”，他同时能做五件事，也能够匹配人力资源针对薪水开出的需求。这种搜寻降低了团队的速度，直到找到候选人（只是个概率问题）之前质量一直都在下降，并可能在浪费执行团队的时间和精力。
例如，试想一下，与大家开会来实施高层测试策略，然后回到六个月前发现没多少进度，因为总监级的高管们已经试图安排项目人员了。我希望我能告诉你这极为罕见，但却很抱歉，这种情况极为常见。
上一次我们讨论了如何组织一个大型的测试组织，特别是集中控制和自组织团队的紧张关系。如今我们将从策略上讨论当测试人员数量较低且专业化是事实时，该交付团队如何获取所有交付软件所需的技能。
让我们一起来看一下。
最大化你当前的努力
最好的起点通常是看看你正在做的事哪些是正确的，以及什么在一点一点地前进。协作和团队培训是两个常规起点。
培训
把大家聚集为一个小型团队的结果之一是，你会认识到团队队友的优势和劣势。一个程序员可能不太擅长编写SQL查询语句，孤独的测试人员可能缺乏技术能力。
“午餐时了解”会是一种开始去解决这种劣势的流行方法。选定一个人在午餐时讲一个超过1个小时的主题，该团队的其他每个成员都去听，问一些问题，并自由地进餐。最低限度，团队里的人都接触到了一些新的观点，比进餐之前有了更多的了解。程序员可以深入了解测试方面的知识，比如理解为什么这是个bug，以及好的汇报习惯是什么，而同时测试人员能了解到新的技能。精益咖啡就是你利用吃饭时间去了解东西，不过是换了一种说法而已。它们能够促进问题的解决，由参与者想要了解什么进行驱动，而不是由演讲者想要说什么进行驱动。在精益咖啡结束时，你可能就会有办法来解决前一天还在困扰你的问题了。
创建跨职能团队
设想一下，一个开发组由三或四名程序员以及一名独立的非技术性测试人员构成。如果程序员到迭代结束时才把工作成果展示给那个测试人员，流程在最后一分钟才能跑通，问题的发现时间总是滞后于你的预期。开发人员和测试人员结对可能会更顺利地尽早找到问题。在开发人员编码的同时，他的测试小伙伴可以问以下任何问题：如果用户忘记填写这个字段会发生什么；如果这个字段里放个小数会发生什么；当一次保存成功时用户是如何知道的；这能在IE9下正常运转吗；或者针对这段新代码整理一份大纲，将来用于自动化检查。
最终结果是开发人员更了解怎样会导致事情出错了，测试人员理解特性是怎么写的了，就能更好地武装起来去怎么会导致它出错以及什么可能会出错了。随着时间的推移，你的程序员将更好地掌握那些测试人员习惯找出的常见错误模式，比如缓存溢出或特定字符的处理等，而测试人员会更了解一门编程语言，可以和产品代码一起开发自动化检查。
咨询的、指导的测试人员
在一些公司里，多个团队奢侈地共享着一个测试人员。程序员们编写产品代码，然后增加一些自动化检查去验证他们所写的是他们设想要做的，然后会用一个综合性工具处理合并的代码、构建系统并进行自动化检查。雅虎就是这样的例子，“主要是开发人员”的模式。你可能看到此会说他们的测试一直在负责自动化的运行，而且他们基本上摆脱了没技术含量的测试。那么你说的是对的。
这仍然对于许多团队非常重要，在这种情况下程序员会对测试有不同的理解。咨询的、指导的测试人员不仅能够在许多不同的组织中完成测试，还能够提升程序员的平均测试技能水平。
此类测试人员像在一个旅游团里，根据需要从开发团队之间游走。在此有几种让这种教练能力带来价值的方式。有些需要与做新特性的开发人员结对，以编程方式给出指导意见，说什么应该完成，角色应该在哪里与产品进行交互。其他需求可能与实际的测试工作没太大关系，更多的是指导大家提升平均技能水平。另外可能需要通过研讨会或游戏的方式来传授测试人员技能，你可能在各种大会上见过此类研讨会，或通过游戏（比如声名狼藉的骰子游戏）来映射软件测试活动，比如实验、设计、做笔记、质询和你的预期理解。
程序员和测试教练之间的每次交互应该都能使测试技能有些许提升。
提升可测试性
软件测试是项有挑战性的工作。大家期望测试人员跟踪许多不同的信息来源并找出哪些是值得依赖的；以适当的方式蹂躏产品，以便在客户之前发现缺陷并予以修复；在许多团队中（但不是全部），还要去游说开发人员和相关负责人修复这些问题。所有这些都需要付出时间和精力，尤其是在很难了解到产品信息的时候。
特性的可测试性能让测试人员更容易快速获取到相关的信息。
有种情况很常见。你正在测试一个输入病人人员统计信息的新功能。在输入一些简单信息后点击提交按钮返回病人列表界面的时候你会觉得这个功能对有些东西的处理应更省时。返回病人列表时，有些东西看起来就不对，明显不对。在之前你增加了至少20行的数据，结果什么都没显示。你必须花时间去查，试着找出是什么原因导致了这种令人不满的结果。
有几件事能使这个过程更加快速。首先，就是把日志记好，它要包括事件的时间戳、起点URL、发送的数据、用户信息，有时甚至还要记录IP地址。有了它，你就能跟踪到你点击保存的时间了，还能分析一下发送的精确数据，看看谁是罪魁祸首。
当然，并不是所有的测试都要有个人通过用户界面来做。通过自动化用户界面，有时工具可以用XPath或属性标签找到页面中的元素，实在不行还可以用像素坐标。这些都很费时间，当这个页面上的元素发生变化时需要一个人保持脚本的更新。你可以为每个可能会接触到的对象创建一个ID，甚至即使你还没打算立即为这个页面编写检查脚本也要这么做，因为这能帮你自己在未来节约很多时间。
如果你的组件架构具有易访问的API，那你就很有优势了。在用户界面出来之前你就可以使用这些API测试很多程序了，也可以用来创建为产品添加数据的工具，这能节省很多手工劳动的时间。
节省时间是可测试性的根本所在。你的开发人员将更快地得到问题相关的信息，测试人员可以把时间放在对于软件测试更重要的事情上。
把测试当作整个团队的活动理想的敏捷项目团队是跨职能的。小型组织内的人需要一个功能从规划到生产的所有能力。这些团队共同为这个功能的质量负责，这是一种很理想的情况。测试是一项整个团队共同来执行的活动。
编写产品代码的过程中，程序员在编写单元测试的同时将结合使用像TDD（测试驱动开发）和BDD（行为驱动开发）之类的工具，看他们是否保持在正确的方向上。现在，有着这样一个论调，认为这些事就是此检查（回答简单的“是”或“否”的问题）以及那些应该正确的东西。但是，做这些事是在它们运行之前，以及它们变红之后，这看起来非常像测试。
到测试人员拿到完全成熟的软件块的时候，代码质量应该已经相当高了，随着这些检查的创建将有希望已经找出大多数的基础问题。这是交给测试人员的一个更具挑战性和更具意义的任务。
整个团队的测试也会牵扯到技术人员之外的人。产品经理评定客户是否能发现新功能的价值，销售人员关心产品演示是否充分，支持人员需要了解产品能否快速掌握和充分支持。
你专用的测试人员将成为专家，能找到其他人可能找不到的问题，质量和测试作为每人职责的一部分将最终为你带来更好的产品。
充分利用SME
主题专家（SME）测试人员通常是非技术教育背景出身，比如英语、历史或艺术，以支持的身份或产品经理的身份介入测试。这些人有着特殊的作用 ，他们对软件产品、业务领域以及用户和他们想要的价值有深入的理解。
在迭代开始之初猜想会发生什么。理想情况下，程序员会看到按优先级排序的新工作列表，然后从上往下开始干。第一次读时，程序员和经常超负荷工作的产品经理会花些时间探讨这些新特性要做成什么样，也许有时间也许没有时间。这正是需要主题专家发挥作用的地方。把业务领域专家放到合适的位置不仅能阐明价值，还能说明客户想要如何开展工作，他们先做一些工作，然后回头再完成，他们处在高压环境中需要一个非常简单的用户界面，或者他们处于数据敏感领域需要简单化。了解大家如何使用你的产品以及他们的工作是什么样的，开发出的特性与最初空想的完全不同。
同样的，在实际软件开发测试的时候，SME专注于价值。甚至与讨论和用户故事或接收测试一样，有些事也会在传递的过程中丢失。例如，思考一个带数据列表的产品，它由一些人间歇往里填充数据，产品的其他部分会时常引用这些数据。你的SME将考虑这一情况，意识到没有自动化地保存每个输入的值，这将意味着如果用户忘了保存而导航到其他页面就会丢失数据。
主题专家可能无法参与代码评审、编写脚本去自动化一些测试工作，或者帮助开发人员找出漏掉的错误处理，但他们必定能为团队带来价值。
总结因为引入了敏捷，测试角色越来越少，更多预期的人填补到团队中。结合这种情况和对技术能力需求的提升，你很难看清谁适合你的团队以及他们能够带来什么价值。仔细想想一个人的技能如何融入一个团队、如何和团队一起工作，你可以得到一群强大的开发团队。
