【虽然今天敏捷开发大行其道，微软测试组织已不复存在，微软不再是测试的标杆，但测试之道的某些内容始终是有生命力的，如质量文化、每个人对质量负责。重温过去，不仅可以加深对测试的理解，而且可以有新的思考。看一遍这篇读后感，相信你会有新的收获。】

终于读完了这本书，有300页。读完此书之后，对于微软公司的测试组织架构和测试管理的文化还是有不少了解的，有些地方也可以借鉴。虽然全书不是深入讲解测试技术的，但是基本上微软的测试实践中的一些基本方法都有对应的实例进行讲解，所以可以很直观地学习。下面是自己摘录的部分笔记以及感想。

“测试工程师不但要对自己负责的功能了如指掌，还必须挑战自己去通晓其他相关的功能，比如，了解客户端和服务器软件的相互运作及最终用户的体验。测试人员还必须对客户充分了解，在可用性、辅助功能、安全性等各个方面完全站在客户的立场看待问题。无论是为了自身提高还是满足工作需要，测试学问是永无止境的。”

完全赞同。测试工程师除了要保证最基本的软件功能的很好实现之外，还要检查软件对于用户来说是否好用。因为不论软件功能多么丰富和炫酷，最终用户能方便地利用这些功能解决问题才是最重要的，否则毫无价值。毕竟，软件是为了帮助我们更好更方便地解决问题而诞生的。所以，测试工程师一方面要从软件整体和细节的角度去检查软件的功能实现，也要从软件使用场景的角度去设想可能遇到的问题，这才是完整的软件测试工作。

“微软最可贵之处就是任何人都可以对设计提出自己的见解，只要言之有理，尤其是测试人员，他们既了解客户的需求又熟悉产品的运用。在微软，产品是集体智慧的结晶，绝非个人所为。测试人员有权利和义务探讨产品的功能特性，以及如何实现这些功能，甚至于推荐产品所需的功能。”

正是因为测试工程师比开发人员理解产品的运用场景，所以对于不合理的软件实现和设计思想，可以提出自己的见解，使软件实现更为合理，符合实际的场景需求。这也是测试工作适当前移的表现，发现设计上的缺陷。

“集中在事实而不是猜想上。“我认为”，“它可能”，“它或许”这些词语都是有问题应该警觉的。要么有，要么没有，没有中间状态。”

不确定的答案在任何工作中都是应该避免的，不仅仅是测试工作中。不确定的回答和主观猜想是逃避问题的表现。应该以事实为依据，找到问题的关键所在，得到确切答案。这样可以避免后期遇到类似问题时，还是不清楚问题的原因。应该共勉。

杰出的测试工程师不仅依靠其好奇心去探究产品，还会对其作深入挖掘、在更加精细得多的粒度上，对正在测试的软件的能力及属性实施深度分析。

测试工程师固然应该有对于产品的探究好奇心，但前提应该是怀着对用户负责的态度，对产品质量负责的态度。从多维度多角度更深入地去衡量和观察软件的行为表现。

Boris Beizer指出，使用黑盒方法进行软件行为测试，仅能企及所有测试能够覆盖范围的35%到65%之间。从用户界面出发进行软件行为测试的确很重要，但如果它被用作唯一或主要的测试途径，我们就很有可能浪费时间在效果不彰的测试上，并且会漏过产品的某些重要的领域，如图1所示。

所以，对于一般软件来说，如果只是测试其基本功能是远远不够的。还需要根据运用场景的不同，进行其他必要的测试工作，如安全性测试、性能测试、兼容性测试、易用性测试等等。即使在测试过程中没有明确的测试类型划分，测试工程师也要始终明确额外的测试工作的必要性，这是软件质量不可或缺的。

测试的新角色

“有些人也许会问：假如质量在设计阶段被充分考虑并集成进去，并且开发人员生成了少得多的缺陷，那么测试团队还能干什么呢？事实的真相是，现在寻找缺陷 可能太容易了。在一个每个人都把质量当成习惯的组织中，测试角色的着重点就从找到一大堆缺陷转移到了集中模拟用户场景、同事评审和校验方面。还是会有缺陷去找，但是要找到它们要比今天难得多。测试人员将会有时间去调查复杂的集成场景，并且，由于不用操心基本的功能性问题，可以找到很多原本会被用户在产品发布后发现的缺陷，从而免除大部分的由补丁、更新和维护包带来的巨大开销。测试角色（以及其他领域）的其他人可能开始担任质量保证角色并发挥作用。这些个人将会分析和实施过程改进、缺陷预防技术及基础设施，以及在他们的机构中担任质量思考和质量文化的大使。这个角色的成长和发展会成为在全公司建立和宣扬质量文化的关键。” 

应该说，这不仅是未来软件质量提高缺陷减少之后测试工程师可以成为的新角色，也是当前测试工程师职业发展的一条很好的路径和方向。测试工程师可以不必在一线进行测试工作，而是根据自己的测试经验和知识积累从更高层面进行质量保证和质量文化创建的工作。

质量该谁管？ 

“很多年前我会问这个问题：“质量该谁管？”而回答几乎总是“测试团队管质量。”今天，当我问这个问题时，回答则通常是“每个人都有份。”虽然这在有些人看来是更好的回答，SEI的W. Mark Manduke则写道：“当质量被宣称为每个人的责任时，没人会真正被指派为之负责，质量问题就会蜕变成一团混乱，每天面临危机。”他还下结论说，当管理层真正在质量文化上下了决心，每个人才会切实为质量负责。” 一个每个人都要管质量的系统需要质量文化。没有这样的文化，每个团队在质量上都会打折扣。开发队伍可能会为了节省时间而不做代码评审，项目管理可能会在规格说明上走捷径，或是在“完成”的定义上打马虎眼，测试队伍会在产品周期进展很深的情况下改变测试执行的目标或覆盖率。尽管我们多方努力让质量保证的过程到位，在实践中工程团队常常会为了赶完工期限或别的目标而在质量实践上破例。虽然为了赶上发布日期或其他截止期限而灵活处事很重要，但质量经常因为缺乏真正的质量专管而受到损害。整个测试团队可能会拥有质量保证的某些方面，但他们很少会是提倡或影响采纳质量文化的最佳人选。高级主管可以当质量倡导者，但他们的工作重点在于也应当在于管理团队、发布产品、和成功运行企业。虽然他们可能也会考虑质量目标，但他们也很少会是质量文化的倡导者。在大多数组里，管理领导团队（通常有开发、测试和项目管理等的机构领导人）会负责承担质量管理。这些领导人负责和驱动团队的工程过程，也处于能评价、估计、和实现基于质量的工程实践的最佳机构位置。不幸的是，在整个产品工程周期的过程中，他们主要关心的并不是质量软件和质量软件工程实践。“

”有高级管理层对质量文化的支持，这还不完全够。在质量文化中，每个员工都会对质量起作用。在制造业很多的重要质量改进都是从工人的建议中来的。在汽车产业，每个日本汽车员工平均每年会提供28个建议，而这些建议的80%都被实现了。“

”理想情况下在微软各个领域的工程师都提出建议来提高质量。当一个团队没有质量文化时，建议会很少，其中极为稀少的会被实现。对质量文化的淡漠会造成团队成员在激情和承诺方面的其他挑战。”

软件质量的保证首先要从高层领导的重视开始，逐步建立质量文化，而不是喊喊口号说要重视质量。口号必须具体落实到软件开发过程的各个细节才能起作用，如：鼓励团队内外的人员对产品提意见，并定期收集、整理和讨论这些反馈的意见，进行合理的改进和优化；建立完善的质量评价体系；建立适当的质量反馈系统管理和激励机制，鼓励大家提有效的意见，而不是抱怨和吐槽。因为对产品的认识更为深入，测试工程师在这个过程中也可以起到更多的作用。测试工程师可以成为开发设计人员和反馈人员之间沟通的桥梁，测试人员收集反馈意见并进行有效筛选，然后组织会议进行讨论和确定改进措施。总之，在一个有质量文化的团队里，软件测试应该是一个系统性的质量保证工作，而不仅仅是测试工程师的测试工作。  

努力培养质量文化 

“文化是社区或组织的成员表现出来的共同的信念、价值观、态度、制度和行为模式。质量文化就是社区成员在质量方面享有共同的价值观、态度和信念，并且每天都以这些为驱动力来对待日常工作。如果质量没有像这样被刻画进文化中，质量实践就会被看作工程拼图中可以“稍后”再拼的一块。不幸的是，世上没有“即时”质量这种事，把质量放在产品周期的最后，或期待质量发生在产品周期的最后是愚蠢的。如果没有把质量放在工程过程的最前线，最后质量就不可能达到能接受的程度。”

质量文化是软件质量的最高层次的保证。相信对每一位测试工程师来说，这都是大家希望未来各个软件企业能够努力去建立的吧。