前两天，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在访谈中建议的那样，告诉开发人员，你的主要目标是帮助他们看起来更好–然后开始相信这个说法。你的工作不是要羞辱、指责、作恶别人。我甚至认为我们不应该拿别人开玩笑，因为这一点也不好笑。
■ 你经常是坏消息的承载者。认识到这一点，带有同情心和谦卑地发布这些消息。
■ 你也可能犯错，对于你所下结论要三思。
■ 聚焦于探索、发现、调查、学习产品，而不是聚焦于证实那些我们本已经知道的东西。
■ 对你所了解的产品做报告：说明该产品的价值以及对这些价值产生的威胁。
■ 试图从你所能想到的各个层面上全方位理解产品是如何工作的。欣赏产品的复杂，当你有这样轻率的想法，比如修复一个问题是如此的简单、或者试图发现代码中的所有缺陷，这时你该停下来反思。
■ 对开发人员所做的工作表示真挚的兴趣，如果适合你的话你也可以学习编码。至少了解一些代码是如何工作的以及代码是做什么的。
■ 永远不要告诉开发人员他们应该如何做好他们的工作。如果你真的认为这是你应该做的，试着问问这个现实的问题：如果他们也同样的对你（告诉你应该如何做好测试），你是什么感觉？
想知道如何影响管理者吗？
■ 提供给他们需要的信息，以便做出更明智的决定。
■ 始终保持清醒，管理者们做的是商业的决定，不仅仅是技术的决定。
■ 知道产品不一定非要切合你的质量标准。
■ 让你高兴不是开发经理的工作，也不是任何其他人的工作。帮助你工作更高效，可能是他们工作的一部分。你要让他们了解如何做到这一点。
尤其要注意的是：
■ 使测试变缓慢的问题是可怕而重要的，因为它们使得缺陷可以隐藏得更久更深。所以在报告中不仅要描述产品的缺陷，还要描述阻碍测试的问题。
■ 如果你想提供些信息用于改进开发的过程，那么报告一下你的测试时间是如何分配的。
■ 注意到，通常都是这样，为什么测试需要这么长时间呢—你只花了极少的时间用于实际测试产品，而花了大量的时间用在缺陷调查和报告、测试准备、会议、文案、和其他为了获得更高测试覆盖率而进行的中断事务上。
■ 专注于测试报告的准确性（5%或10%）而不是精确性上。因为软件开发中的大部分问题都可以基于这些一手的度量数据而发现和解决，无需那些基于反正是无效的模型而进行的六十进制分析的数据。
■ 向管理者展示你所发现的大部分问题都不是简简单单地通过重复执行用例就可以发现的，而是通过测试用例所没有覆盖到的步骤和观察发现的–也就是说，是通过你对产品进行的一次次睿智的调查而发现的。
■ 帮助开发人员和管理者之类的人认识到，测试自动化，远远不只是编个程序让机器自动去代你敲键盘。
■ 让每个人了解自动化对某些种类的测试是有益的，但同时也极大地限制了测试的其他方面。
■ 帮助人们认识到测试和检查的区别，认清二者各自的价值，认识到优秀的检查需要具备大量的测试技能。
■ 用你的实际工作去证明测试是对产品的一次技巧性探索，让管理者认识到恰恰是这点使得你发现了很多缺陷。
■ 帮助团队认识到软件开发并不是一个线性的过程，而是一个有机的过程。
■ 帮助管理者和程序员逐渐认清，通常所说的”测试阶段“实际上应该叫做”缺陷修复阶段“。
■ 当被要求签署产品时，礼貌地提供你的测试报告，把签署的权利留给那些意见真正起作用的人：产品负责人。
想赢得你所在团队的尊重？
■ 为项目提供测试服务，而不是成为一个障碍。你是信息的提供者，而不是过程的强加者。
■ 停止去尝试那种”质量是测试人员的“，”测试人员对质量负责“的思想。并默认项目中的其他人至少是和你一样关心质量。
■ 认识到你的角色是挑剔的思考，帮助开人员和管理者不被错误的假想所欺骗–这首先要起于你自己不被错误的理念所欺骗。
■ 让你的技能、团队和战术尽量多样化。就像Karl Weick所说：”如果你想理解一个复杂的事务，你首先得让自己变得复杂起来。“
■ 如James Bach所说，去发明适合你的测试。不要满足于其他人所说的（包括我说的），基于你的知识、经验和技能去实地考证。经常在你所处的圈子里看看别人都是怎么测试的。
■ 如果你发现有什么东西可以帮助你提升你的知识或感官，有助于提升你的测试能力，就去学习它。
■ 学习测试技能，尤其是挑剔地思考的技能，同时也包括系统思维，科学思维，社会生活的信息，人机交互，数据表示，编程，数学，测量… …
■ 实践你需要的和读过的技能。通过参加周末测试活动提升你的技能。
■ 找一个当地的导师帮助你。如果你找不到，可以到互联网上找。请求帮助！
■ 不要屈服于外界压力而成为别人交易中的商品。参加认证意味着你花了钱却成为和其他成千上万人无异的人。要有你自己的标志。
■ 要知道，过程模型只是模型和过程模型–特别是那些涉及人类活动如软件开发的过程–很多真正的实际项目中发生的细节并未包含其中。
■ 聚焦于提升你的个人技能和思维，这样你就可以适应任何过程模型。
■ 分享你自己的软件测试中的经验教训和完美软件以及与有关测试的幻想。
最后，如果你是一名测试人员，远离质量保证部门。成为你能成为的最好的测试人员：一个熟练的调查者，而不是一个程序员或者项目经理的崇拜者（作
者注：和Michael交流后，最后一句表达的是，”。。。成为一名熟练的
调查者，而不是缺乏技能或相应权力的情况下却想成为一个程序员或者项目经理。”）。
