前两天，Cory Foy在tweeter上发布一条消息“有一个QA部门，标志着你们开发部门的无能，讨论。”
我是这么想的：我是一名测试人员，现在该是我们增长技能的时候了。不论开发人员的组织结构如何，该是测试人员走出QA部门的时候了。
2008年秋，我在AYE会议现场，辅助Fiona Charles和Jerry Weinberg主持一个session”测试的谎言“。Jerry坐在会议室前排，当人们不停的进入会场就座时，我听见Jerry在和几个人讨论问题。他问：” 你们是质量保证部门的？“ 回答是是的。”那么，你们有权修改被测试的源代码吗？” ”这绝对不行。“ ”这很有趣。那么你如何来保证质量呢？“
真是个好问题，它让我立即想起十多年前的一次对话。1996 年 秋，Cem Kaner在Quarterdeck做了一个黑盒软件测试的讲座。那时我还是一名开发经理，但是QA（也就是测试）的头邀请我参加这次讲座。作为课程的一 部分，Cem引导我们讨论”测试团队是否真的应该被叫做质量保证？“ 他的立场是，每个人– 开发人员或测试人员 — 当然能够确保他自己工作的质量，但是测试人员，不能确保别人工作的质量，也不应该试图去确保别人工作的质量。Cem说，企业中质量保证这个职责（role）应该归于管理者和CEO（企业中主要的质量官），因为是他们–而不是测试人员–有权利做关于质量的决策。多年来，Cem持续的构筑这个思想，在他的胶片中和提交给The Ongoing Revolution in Software Testing的论文中表达这个观点，这个观点盖过了他所有其他的工作。测 试人员的职责不是质量保证，我们没有权利控制项目计划、预算、开发人力、产品范围、开发模型、客户关系等等。但是当我们尽最大努力做我们的工作的时候，我 们会提供很有价值的、实时的有关产品和项目真实状态的信息。我们不对质量负责，我们帮助那些对质量负责的人、提供质量相关的信息、以影响他们的决策。”质 量辅助，这就是测试做的事情。“
最近，在接受Roy Osherove的一次采访中，James Bach也明确表达，测试人员不是质量的看门人。测试人员并不比其他任何角色有更多的责任对质量负责；开发团队中每个人都有对质量负责的责任。 当James在苹果公司第一次当测试经理时，质量把门人这样的想法让他充满活力。”但是后来我认识到这个想法对其他的角色是莫大的侮辱，因为这样的说法传 递给其他人的信息就是‘你们这些家伙并不真的关心质量，是吧？你们不像我这样的关心质量。我是测试人员，因此我才更关心质量。’ 开发人员除了创造质量，他们还使质量真实的存在。没有开发人员，什么都不存在；你拥有的质量是0。所以，说‘测试人员是质量的把门人’，是对开发人员的侮 辱，当你想用这样的说法侮辱开发人员的时候，开发人员就不愿意和你一起工作。“
上周，我去参加Orlando举行的StarEast测试会议。经常有测试人员和测试经理来请求我的帮助。他们希望我给出建议：测试人员如何才能使开发人员采纳那些‘最佳实践’？测试人员如何去影响一个产品经理去做更好的工作？测试人员如何使得开发人员按照某种过程模型开发产品？在一个议题中，测试人员哀叹来自业务人员的需求的质量（再重复解释一下这个普遍的用词，当测试人员说需求的时候，实际指的是需求文档）。其中有个人响应这个问题说，等他回去的时候，将让测试人员承担起需求撰写的工作。
在答复上述寻求建议的问题上，迄今为止我能给出的最有用的解答是：这些都不是有技能的测试人员应该做的事。
测试人员不是项目的大脑。这就是说，测试人员不能控制项目。我们的角色是提供ESP–不是指”超感官的洞察“，而是指”额外的敏瑞的洞察“。对开发人员和管理者而言，测试人员是项目额外的眼睛、耳朵、手指、鼻子、味蕾。我们是他们器官的延伸。如果我们竭尽所能，我们可能像极度敏感和超精校准的仪器-显微镜、望远镜、超灵敏麦克风，游标卡尺，质谱仪，嗅弹探测器。（测试人员像仪器的想法是Cem Kaner启发了我。）测试人员帮助开发人员和管理者们听到和看到那些在有限的时间内、由于他们得用自己的思维方式去工作，而不大可能意识到的东西。
听好：如果你真的想提升代码质量，并且认为你可以做到，那去做一名开发人员。我就这么做过。我能保证如果你真的这么做了，很快就会发现成为一名真正的优秀的开发人员是一件多么具有挑战和震撼人心的工作–因为就像所有的工具一样，计算机可以迅速和有力地延伸你的无能，就如它可以扩展你 的能力一样。如果你想管理一个项目，就去当项目管理者。我也这么做过，还做得不错。但当你试过后，你很快将发现质量就是对某个或某些人的价值，并且这些人 很在乎这些价值。而你自己定义的质量标准远不如那些真正使用产品并为此买单的人所定义的质量标准。成为项目管理者，你几乎马上就会意识到是否发布一个产 品，确实会受到技术问题的多少的影响，但最终它是一个商业的决定，需要平衡产品的价值以及缺陷–即对产品价值的削弱–和不发布产品而带来的成本。
在上述任何一种情况下，如果一个没有做过开发或者版本管理的人来向我发牢骚，说我不尊重质量，这并没有什么帮助；如果他还试图指导我如何做好我的工作，而他却从来没有做过这项工作，那就更糟糕了。无论我是开发人员还是项目经理，我希望从测试人员那里得到的是信息。作 为开发人员，我希望了解测试人员在我写的代码里发现了什么问题，他们是怎么发现的，产品可能无法正常工作的情形，以及任何我需要的有助于找到和修复这个问 题的步骤和线索。作为项目经理，我希望了解测试人员都获取了哪些关于产品的信息，他们在获取这些信息时是如何配置、操作、观察和评估的。我想知道我们的产品是如何与以往一直工作的方式所不同的。我想了解内部的不一致。我想了解我们的产品与市场上同类产品对比有哪些不同；怎么更好了，或者怎么更差了。我想知道我们的产品因何堆放在那里，面临索赔。
那么：你想影响质量、影响团队。想知道如何正向地影响开发人员？
■ 就像James在访谈中建议的那样，告诉开发人员，你的主要目标是帮助他们看起来更好–然后开始相信这个说法。你的工作不是要羞辱、指责、作恶别人。我甚至认为我们不应该拿别人开玩笑，因为这一点也不好笑。
■ 你经常是坏消息的承载者。认识到这一点，带有同情心和谦卑地发布这些消息。
■ 你也可能犯错，对于你所下结论要三思。
■ 聚焦于探索、发现、调查、学习产品，而不是聚焦于证实那些我们本已经知道的东西。
■ 对你所了解的产品做报告：说明该产品的价值以及对这些价值产生的威胁。
■ 试图从你所能想到的各个层面上全方位理解产品是如何工作的。欣赏产品的复杂，当你有这样轻率的想法，比如修复一个问题是如此的简单、或者试图发现代码中的所有缺陷，这时你该停下来反思。
■ 对开发人员所做的工作表示真挚的兴趣，如果适合你的话你也可以学习编码。至少了解一些代码是如何工作的以及代码是做什么的。
■ 永远不要告诉开发人员他们应该如何做好他们的工作。如果你真的认为这是你应该做的，试着问问这个现实的问题：如果他们也同样的对你（告诉你应该如何做好测试），你是什么感觉？
