管理测试项目在某些方面与管理任何其他类型的项目一样。测试员的
工作是对程序员工作的反映。
经验157-建设一种服务文化
测试员是为整个项目团队提供服务，典型的服务是发现并报告程序错误。
经验158-不要尝试建立一种控制文化
经验159-要发挥耳目作用
测试员在公司中的权力建立在自己的调查技能和自如沟通的基础上，而不是建立在命令链上，因为测试员在项目团队的命令链中的位置并不很高。测试员必须评估自己公司的文化，要在不被解雇或排斥的限度内发挥作用，在这个限度内，我们建议测试员要称为能够为别人带来价值的守信用、高度正直的信息提供者，以此来施展和扩大自己的影响力。
经验160-测试经理管理的是提供测试服务的子项目，不是开发项目
测试工作是整个项目的一个子项目，要申请资源并提供服务。项目经理在如何运作测试项目上有很大的控制权，应该仔细选择自己的管理风格，从而与项目经理的管理风格协调。
经验161-所有项目都会演变，管理良好的项目能够很好地演变
每个项目的整个过程中，测试经理都应该准备对整个计划的大小细化或更正。
项目就是一组任务，随着时间的推移，项目团队会发现有些任务比预期的要困难，或要花费更长的时间，有些任务还不能完成，有些任务与前一周相比，对市场开发经理或者客户来说很紧迫，此外，每次测试员提出一份错误报告时，都会在大堆的任务中再增加一项。
经验162-总会有很晚的变更
所有项目管理方法都必须处理变更
需求实在我们想要和我们能够得到的功能之间进行不断斗争的结果。随着项目的展开，需求会有变化。
经验163-项目涉及功能、可靠性、时间和资金之间的折中
项目经理的任务就是按时并在预算限度内支付一组合适的功能，达到合适水平的可靠性。这是一种具有挑战性的折中。
经验164-让项目经理选择项目生命周期
生命周期模型是从最初考虑构建这种产品，到向公众发放并投入使用为止，产品设计和开发过程的描述。有些公司遵循标准生命周期模型，但是根据我们的经验，项目经理总是有一定的定制余地。明智的项目经理会挑选能够流畅地控制自认为很难管理的方面的方法，而预留出自己特别有能力解决的方面。
经验165-瀑布生命周期把可靠性与时间对立起来
瀑布模型是一种描述按阶段推进项目管理的具体生命周期方法。这些阶段包括：问题定义；需求定义；内部和外部设计；编码；测试；安装；安装后支持；失望客户的法律诉讼；问题定义（针对产品的下一个版本）；软件项目有大量的风险。总会有很晚的变更。
在瀑布模型下，到测试员得到代码时，所有功能都已经设计，且大部分或所有功能都已经编码，大部分
软件开发经费已经支出。关键的折衷要素是时间和可靠性。
要么修改错误而晚一些交付产品，要么较快交付产品，但是有较多错误。这是项目经理和测试员之间的经典争持：要交付错误很多的产品，还是延迟交付。
经验166-进化生命周期把功能与时间对立起来
在软件开发进化方法中，项目团队每次增加一个功能，他们设计该功能、编码、测试，并更正其错误。如果集成了这个功能的产品满足了项目团队的质量标准，他们就会增加下一个功能。今天的版本和下个月的版本之间的差别是下个月的版本有更多的功能。这两个版本都能使用，不存在项目结束时的时间和可靠性之间的折中考虑。
经验167-愿意在开发初期将资源分配给项目团队
可以评审需求文档的可理解性、可测试性和模糊性；随着项目工作制品的开发，再对他们进行测试，不要等到真个产品完成才测试；推动代码评审；代码评审是收效很大的一种质量改进工作。
拟定硬件配置和准备购置或借用设备的初步清单；要求提供可测试性的功能。准备测试自动化；
研究测试工具；如果可能，订购用于被测软件的外部开发的测试包；了解产品的市场和竞争情况；
经验168-合同驱动的开发不同于寻求市场的开发
在合同驱动的项目中，测试员的主要活动是对一组规格说明测试软件；
在寻求市场的项目中，测试员更可能根据不同客户的预期，来研究和测试产品；
经验169-要求可测试性功能
越早提出可测试性功能要求，程序员和项目经理越有可能把它列入预算和进度计划。
经验170-协商版本开发进度计划
制定版本进度计划，内容包括测试小组接受软件的频度，对提交的被测试软件的要求，以及在最近版本中发现的程序错误如何在新版本中重现。
经验171-了解程序员在交付版本之前会做什么（以及不会做什么）
有些编程小组会做大量的
单元测试，有些没有；有些会把冒烟测试作为其开发的一部分，有些没有；不要指望他们完成或不完成某种类型的测试，也不要指望对交付给测试员的版本做各种准备。
经验172-为被测版本做好准备
当被测版本就绪时测试环境也应该就绪，这一点很重要。
经验173-有时测试员应该拒绝测试某个版本
偶尔测试员也会回绝某个版本，拒绝测试。理由
1、由于这个版本中应该加入某个关键功能，但是测试员发现没有加，或马上失效；
2、以前正常的关键功能现在不能正常使用了，测试小组的冒烟测试应该发现这种失效，当冒烟测试失败后，一般都要拒绝该版本。
3、如果收到一个版本，并且已经另一个版本在几个小时之后就会完成；
一般来说，如果会使测试工作不能得到明显收益的情况下效率受到很大影响，或对某个版本的测试结果会被忽略，则应该拒绝该版本的测试。
经验174-使用冒烟测试检验版本
冒烟测试或接受测试是一种测试包，目标是检查版本的基本功能。如果该版本没有通过，则可宣布该版本不太稳定，不值得测试。
经验175-有时正确的决策是停止测试，暂停改错，并重新设计软件
如果不管进行了多少次程序错误的修改，在同一位置总发现问题，或不管对用户界面做了多少小修改，仍然存在使用户困惑的问题，也许应该停止测试并对有关代码进行调试。这部分内容可能需要重新设计或重写；
经验176-根据实际使用的开发实践调整自己的测试过程
除非程序员向测试员提供完整的规格说明，建议测试员拒绝测试产品。这是很糟糕的建议。
我们建议不要改变程序员的工作方式。
经验177-项目文档是一种有趣的幻想：有用，但永远不足
即使对于试图充分描述产品的项目团队，开发文档也和想象有很大差别。不要对抗这个事实，
这是一个基本问题。
经验178-测试员除非要用，否则不要索要
如果要求提供规格说明就要使用它，否则以后他们不会向测试员提供任何材料；
经验179-充分利用其它信息源
如果没有人向测试员提供规格说明，测试员还有很多其它的信息源可以帮助。
以下是补充规格说明所没有提供的信息：
用户手册草稿；产品市场开发文献；市场开发人员向管理层推销产品概念的演讲；
程序软件变更的备忘录；内部备忘录；已出版的风格指南和用户界面标准；
已出版的标准；第三方兼容的测试包；已出版的规定；错误报告；程序逆向工程；与人员面谈；
头文件、源代码、
数据库的表定义；第三方的规格说明和问题清单；原型以及针对原型的所有试验
记录；
前一个版本的客户
电话记录；可使用性测试结果；B测试结果；常见错误；兼容产品；
与仿制的产品进行比较；内容参考材料；
经验180-向项目经理提出配置管理问题
程序错误修复损坏产品中的其它功能，或使得以前解决了的问题再次出现的可能性有多大？
对于不同的公司和项目团队，出现副作用的可能性有很大不同。不管是那种情况，都要与
项目经理讨论这个问题，并要求提出解决意见。如果这个问题还得不到解决，在状态报告
中说明需要高级别的回归测试。
经验181-程序员就像龙卷风
程序员就像龙卷风，把他们看做是一种自然力量。程序员会按照自己的方式做，而且在不同的公司中程序员的工作方式也有很大不同，测试经理应该相应地设计自己的实践。
经验182-好的测试计划便于后期变更
如果后期变更是不可避免的，那么测试经理的责任是设计能够适应后期变更的测试过程。
不要在测试之前开发大的测试包，而是在需要测试包时再开发；
不要编写维护成本很高的大量测试文档；
通过最大化可维护性和跨平台可移植性来设计自动化测试；
构建一组能够在不同程序中重复使用的通用测试；
构建一组很强的冒烟测试，以快速检测被测软件中的基本失效；
慎重考虑使用极限编程法开发自动化的测试；
开发一种产品用户和用户要通过产品获得效益的模型；
帮助程序员开发大的单元测试包；
经验183-只要交付工作制品，就会出现测试机会
任何时候产品的任何部分可以提交评审，测试机会都会出现，通过这种方式可以把测试融入到产品的整个开发过程中。只要工作制品已经能够完成，都要尽快测试。
经验184-要多少测试才算够？这方面还没有通用的计算公式
不要费心寻找计算公式，还是英爱多开动脑筋。
经验185-足够测试意味着有足够的信息可供客户做出好决策
当有理由相信产品任由有重要的未发现的问题可能性很低，就可以停止测试。
判断测试是够足够好有多种因素：知道发现的重要问题的种类；知道产品的不同部件如何表现出严重问题；对产品做了与这些风险相应的检查；测试策略具有合理的多样化；使用了所有可用的资源进行测试；满足客户期望满足的所有测试过程标准；尽自己的可能，清晰地表示测试策略、测试结果和质量评估。
交付之后可能会有大的问题有以下原因：
测试员不想按照自己想象的那样了解风险的动态；测试员在测试中出现错误；风险评估是正确的，管理层决定冒风险；
在测试中遗漏问题不算问题，粗心、不认真思索或不通过实践吸取教训才是问题。
经验186-不要只为两轮测试做出预算
第一轮会暴露问题，第二轮检查所有错误修改，但是产品测试不得不进行的次数也许比两次多得多。
经验187-为一组任务确定进度计划，估计每个任务所需的时间
列出任务清单，估计所需的总时间，但是做起来难。列出任务并不是简单的事，因为很容易遗漏任务或低估任务范围；
尝试其他估计问题的方法：测试员完成过类似的项目，可以类推；了解程序的长度和复杂度，了解当前公司将程序长度和复杂度与测试时间关联起来的数据为基础的模型，则使用这种模型导出估计值；了解有关的风险，针对风险测试需要什么，最终估计时间；一些其它因素会影响测试员的估计。
经验188-承担工作的人应该告诉测试经理完成该任务需要多长时间
如果要使估计更有意义，可收集承担该任务的员工所做的估计并进行统计。
经验189-在测试员和开发人员之间没有正确的比例
经验190-调整任务和不能胜任的人员
不同的测试员都有不同的强项，要鼓励测试员承担风险并扩展自己的能力，测试经理要尽可能提供指导，但是要关注测试员的进步。不要让测试员承担不适合的工作。
经验191-轮换测试员的测试对象
不要让测试员自始至终对某个项目的同一组功能进行测试。首先，大多数测试员赶到厌烦；其次，测试员太专；第三，如果专家离开，会留下很大知识漏洞；第四、最重要的，两个测试员会以不同方式分析同样的功能，他们会使用不同的查错理论，创建不同的测试，并发现不同的缺陷。
经验192-尽量成对测试
测试员结成对子，一起工作，常常等于熟练的差错高手；测试时一种思想生产活动，而不是计划实现活动，测试是一种在开放的多维空间中启发式探索过程，成对测试有利于每个测试员解放思想，并对其做出反应。成对测试有助于两个测试员始终关注任务，更容易重现和分析程序错误。
经验193-为项目指派一位问题查找高手
问题查找高手是经验丰富、热心探索的测试员。问题查找的一些方式：对有怀疑的部分进行初步探索式测试，形成更细致地跟踪的想法，这个可以让经验不足的测试员执行；探索被认为是风险很低的部分；定位看起来很容易引起不可重现问题的关键部分；找出关键程序错误，以说服项目经理推迟发布日期；
经验194-确定测试的阶段计划，特别是探索式测试的阶段计划
确定60-90分钟内要做什么，我们把这叫做阶段计划；这种方法的好处是有助于测试员集中注意力。阶段目标可以包括要测试什么，要使用什么工具，使用什么
测试技术，有什么风险，要寻找什么程序错误，要研究什么文档，需要什么结果等。
经验195-分阶段测试
保护阶段的完整性，在一个阶段中，测试员要进行专题测试。
经验196-通过活动日志来反映对测试员工作的干扰
如果认为不需要保护自己的测试免受频繁中断，可以记录一两周的活动。为了解决看起来生产率有问题的测试员，了解需要大量加班才能完成任务的测试员的实际问题，活动日志是有助于将注意力集中到任务并对任务划分优先级的有效办法。
经验197-定期状态报告是一种强有力的工具
测试小组的真正力量来自沟通，不是监管。注意永远使用中性、客观的语气；不要针对具体的某人；采用所有项目都一致的格式；按照标准进度计划提交报告；仔细地选定状态报告的内容；要把状态报告提交给项目团队之外的人看。
经验198-再也没有比副总裁掌握统计数据更危险的了
在报告状态时，应该知道自己在统计什么数据，谁将看到这些数据；根据定义，度量就是整个图片的一小片，将整个图片压缩为少量数据的度量是一种很大的简化。我们利用度量帮助了解项目的进展情况，以及产品各个方面的质量情况。
经验199-要小心通过程序错误数度量项目进展
程序错误数是一种度量项目进展的很好参数。但是程序错误数是不充分的，并且常常产生误导。程序错误数不能用来说明产品已经接近发布时所要求的质量，不赞同把程序错误到达率作为项目管理依据的统计模型，因为没有理由相信这种方法核心的概率模型假设符合项目的实际情况。
经验200-使用的覆盖率度量越独立，了解的信息越多
可以在多个元素上度量产品已经完成的测试量：程序错误、需求、代码、配置、变更历史、开发人员、测试员、数据等，单独测试任何一个元素都是不够的；
经验201-利用综合记分牌产生考虑多个因素的状态报告
最好的状态报告反映多个因素的参数，不是单一、平凡的数字向管理层提供信息，但是信息模式的表示要足够简单，以便指导决策；
经验202-以下是周状态报告的推荐机构
可以把状态报告看做四页长的文档；第一页列出关键问题，如所需的决策、所需的程序错误修改、预期的交付的工作制品、意外问题；第二页描述测试小组完成计划任务进展的情况；第三页提供错误报告统计数字；最后一页列出本周被推延的程序错误，清单可以只包括程序错误数、总数、严重程度；
经验203-项目进展表是另一种展示状态的有用方法
向项目团队所有成员和与该项目有关的任何人公开，直观地展示项目的进展情况。
经验204-如果里程碑定义的很好，里程碑报告很有用
如果公司要在每个里程碑处评估产品，那么测试经理需要知道应对照什么进行评估。
经验205-不要签署批准产品的发布
要让项目经理或者项目团队确定什么时候发布产品；
经验206-不要签字承认产品经过测试达到测试经理的满意程度
产品经过了充分测试，完成了约定程度的测试，或在可用的时间内尽力做了最好的测试。
经验207-如果测试经理要编写产品发布报告，应描述测试工作和结果，而不是自己对该产品的看法只描述自己知道的东西；
经验208-在产品最终发布报告中列出没有排除的程序错误
应附上产品中未排除的程序错误的清单。
经验209-有用的发布报告应列出批评者可能指出的10个最糟糕的问题
