正在阅读一本很棒的书，《软件测试经验与教训》。几名国外的软件测试大师，以大量的测试工作实战经验为出发点，总结了深刻而精悍的两百多条经验。作者把这些经验比喻成为波尔多红酒，鼓励读者分散阅读，带入自己的工作实际情境，慢慢细品，深入思考。当然还有，不要独摊波尔多，分享给我的朋友、同事们！

《软件测试经验与教训》一书，讨论的第一个话题，就是关于测试人员的角色定位。我对这个话题讨论的个人理解是：清晰认识自己的角色定位，能够帮助测试人员明确对自己工作目标的预期。而清楚的认识测试人员的角色定位，对于公司、项目的其他成员来说，可以使他们对于测试工作的“期待”更加恰当，即使是“指责”，也更恰如其分。关于这个话题，以下是对于书中部分经验的理解或讨论。

“测试员是前灯”

研发经理和开发人员或许正开着一辆吉普，行进在盘山公路上，测试人员的职责就是做好探路的前灯，哪里是悬崖，哪里有险情，前方的路面情况如何……而产品或者项目的关键决策，都是基于这些信息的。测试人员的职责是将关于这一切的尽可能详细的信息告知公司或项目的其他成员。

是这样的角色：全面搜集、整理、报告信息

不是这样的角色：决策者

“迅速找出重要的程序问题”

测试人员很重要的一条使命就是“迅速找出重要的程序问题”。如何做好这点，书中给出了几条建议。他们看上去很简单，很质朴，似乎每个人都知道，但是在实际工作方法中有经常性地提醒自己或者潜意识中就使用这几条建议么？所谓大道至简。

*首先测试经过变更的部分，修改和更新都意味着新的风险

*首先测试核心功能，测试产品所完成的关键和常用功能，测试完成产品基本任务的功能

*首先测试能力，即每个基本功能是否能用，然后测试可靠性，即深入检查每个功能在不同条件下的表现

*首先测试常见情况，使用常用的数据和使用情境。然后测试特殊情况。

*首先测试影响重大的问题

*优先测试最需要的部分--对团队其他成员有重要意义的任何部分的任何问题

*测试人员对产品、相关软硬件、产品的最终用户越了解，就越可能更快地找出重要问题。

“Follow 开发人员”

为开发人员提供支持，这也是测试人员的一项重要使命。尽可能建立最短、最快的反馈环路--开发人员交付产品时，马上进行测试；开发人员修改变更代码后，马上测试变更的内容（trunk版本的测试即是此种情况）。在书中，几位测试大师认为，最理想的情况是，开发人员为了修改测试人员发现的缺陷而忙得团团转，是开发人员，而不是测试人员，成为项目的瓶颈。当然，老板可能不会认为这个情况理想：）

“询问一切，但不一定外露”

多提问。做测试时，遇到的情况千变万化，不可能不遇到问题。如果真的连续地进行测试工作，而没有任何问题可提，那么不妨暂停一下手上的测试工作，留给自己一些思考的空间，还是那个论断，不可能没有问题。

书中提到提问的方法，认为直白的提问就如一剂猛药，会刺激到别人，所以尽量减低剂量，或与米饭同吃（结合其他沟通形式）。这个的确是个不错的经验建议，在面对开发人员、产品需求设计人员、实施人员等同事时，可以尽量采用这样的提问方式。当然，在面对测试部门同事、主管时，个人觉得，直接提问会更有效率。

“测试人员关注缺陷，团队成员才能关注成功”

“确认程序正常”永远不可能是测试人员的使命，测试人员只能说，“就我所执行的测试来说，产品没有不正常”。测试人员是团队中唯一不直接关注成功的角色。测试人员的关注点注定只能在关注产品缺陷上，而不能在关注证明产品正常上。测试人员关注缺陷，用自己的全部的创造力、精力和技能，寻找产品客观存在的缺陷，帮助项目团队更加了解自己的技能和产品风险，将产品不断改进。否则，这块关注点，只能由客户来关注了。那么团队，也就注定失败。

是这样的角色：关注产品缺陷

不是这样的角色：关注产品的成功

“不会发现所有问题”

测试人员的任务是发现并报告重要的产品缺陷，但是不会发现所有的产品缺陷。如果测试人员觉得自己可以发现所有的产品问题，那么要么是产品非常简单，要么是测试人员想象力太差。

知道并承认自己不能做所有的事以后，学会选择如何使用和分配自己的时间。

“不要期待用测试工作来保证产品质量”

产品质量来源于构建产品的人。测试人员的测试和缺陷报告，提供的是促进产品质量保证的信息，但是这种质量保证是来自整个团队的。

是这样的角色：提供关于产品质量的信息

不是这样的角色：保证产品质量

“永远别做看门人”

测试人员不该独立拥有控制产品发布的权利。权利即是责任。独立拥有权利的后果是致使其他团队成员心理上放松，并且有了推卸责任的理由--如果产品发版后出现重要问题，就会归咎于测试人员的把关不严。而如果测试人员为了避免这样的风险，而纠结于反复的完备的测试，那就会延误产品发布的计划时间，引起诸方不满。所以，产品发布的权利，还是需要项目经理把握，或者是某种方式的集体决定。

是这样的角色：产品质量的测试者和相关信息的提供者

不是这样的角色：决定产品发布

“当心扮演过程改进的批评者角色”

测试时发现种种问题，并且频繁反复出现时，也许测试人员会厌烦地觉得，要是开发人员能够认真细致一些，或许就不会出现这么多的产品缺陷了。把产品缺陷预防在未发生的时刻，这确实很有意义。但是不一定每件有意义的事情，都是想当然的可行的。事情除了理性的一面，还有情感的一面。就像告诉你的爱人，怎么样的生活才能更有生命的意义。如果尝试一下就会知道，好的忠告并不是总能被真正接受。问题不在于是否认识到，而在于情感。测试人员可以参与到公司、团队的整体过程改进中去，但是切记，不要扮演一个“批评者的角色”。因为这涉及同事间的情感。

是这样的角色：信息提供者

不是这样的角色：批评者