测试计划安排与进度监控
如果要测试一个大型系统，将面对在一年甚至更长的时间内编写、执行、验证成千上万的测试用例，处理上千的模块，修订成千上万的错误，雇用上千的员工，显然，这将在计划、监视、控制测试过程中面对无穷的项目管理方面的挑战。
在计划一个测试过程时，主要的错误是默许对不发现任何错误的假设，这种错误明显的后果是大大低估了计划资源（人、时间、计算机），这是计算机工业声名狼籍的一个问题。
良好测试计划的组成：
（1）目标：必须定义每个测试阶段的目标。
（2）完成准则：设计准则来指定判断每个测试阶段何时完成。
（3）进度：每个阶段都需要日程安排，指出何时设计、编写、执行测试用例。
（4）职责：每个阶段必须识别设计、编写、执行和验证测试用例的人员，修订被发现的错误的人员。在大型项目中，会引起有些测试结果是否是错误的争论，所以需要识别仲裁人。
（5）测试用例库和标准：在一个大型项目中，必须要有系统的关于识别、编写、存储测试用例的方法。
（6）工具：识别所需的测试工具，包括谁将开发或去获取工具，工具将如何被使用，何时是必需的。
（7）计算机时间：这是关于每个测试阶段所需的计算机时间的总量的计划，包括编译应用程序的服务器、安装测试的桌面机、WEB应用的WEB服务器、网络设备等。
（8）硬件配置：如果需要特殊的硬件配置或设备，需要一个计划来描述这种需求，它们如何满足、何时需要。
（9）集成：测试计划的一部分是定义程序如何结合在一起（如增量从上到下的测试），一个包含大量子系统或程序的系统可以增量地结合起来。使用从上到下或从下到上的方法，但是构造块是程序或子系统，不是模块。如果情况是这样的，那么需要一个系统基础计划。系统集成计划定义了集成的次序，系统每个版本的功能，有责任去创建“脚手架”代码来仿真不存在的部件的功能。
（10）跟踪过程：定义了机制来跟踪测试过程的方方面面，包括倾向于错误的模块的定位、计划、资源、完成准则等各方面进展的估计。
（11）调试过程：定义了机制来报告检测到的错误，跟踪纠正的进展，将纠正好的添加到系统中。计划、职责、工具、计算机时间/资源都是调试计划的组成部分。
（12）回归测试：作了功能改进或对程序修订后，需要执行回归测试。目的是确定改变是否已经回归了程序的其他方面，一般是通过重新允许程序的测试用例的子集来执行。回归测试的重要性在于变更和纠错倾向于产生更多的错误，所以一份回归测试的计划（谁、如何、何时）是有必要的。
如何制定软件项目测试计划
摘要 随着测试走向规范化管理，测试计划成为测试经理必须完成的重要任务之一，本文根据实践经验结合理论，探讨如何制定软件项目测试计划。
关键字 测试计划 变更
正文
软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。
一个好的测试计划可以起到如下作用
1． 避免测试的“事件驱动”
2． 使测试工作和整个开发工作融合起来
3． 资源和变更事先作为一个可控制的风险
测试计划的模板在各个公司中都大同小异，在个人实践中发现，测试计划制定中存在的问题具有相似性，下面重点就这些相似的问题谈谈如何制定软件项目测试计划。
问题一：测试阶段划分
就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。
合理的测试阶段应遵循下面划分方法：
照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。
问题二：系统测试阶段日程安排
划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可操作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1。1~1。5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编码阶段（包含单元测试和集成测试）1到1。5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下：
1． 计算需求文档的页数，得出系统测试用例的页数
需求页数：系统测试用例页数 ≈ 1：1
2． 由系统测试用例页数计算编写系统测试用例时间
编写系统测试用例时间 ≈ 系统测试用例页数×1小时
3． 计算执行系统测试用例时间
编写系统用例用时：执行系统测试用时 ≈ 1：2
4． 计算回归测试包含的时间
系统测试用时：回归测试用时≈ 2：1
注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据。
基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。
（测试经理在编写测试计划时候，测试进度中的计划开始/结束时间往往用如2005010-20051201的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式，采用30工作日/2人或者2人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可，不必反复修改测试计划。）
值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束！
在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。
问题三：变更的控制
测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。
变更来源于以下几个方面
1． 项目计划的变更
2． 需求的变更
3． 测试产品版本的变更
4． 测试资源的变更
测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。
对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。在这种情况下，测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降，这种做法和想法不一定是正确的。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围，实践中测试经理常常忽略测试计划的这个章节。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；和公司QA商量进行简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。
第二：项目进行过程中最不可避免的就是需求的变更。那么，测试计划中就不能进行控制和约束的吗？答案是未必。当制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。
许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定——尤其在执行测试阶段发现需求的变更——定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。
对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。
最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。规避风险的办法可能有：
一，项目组的需求和实施人员参与系统测试；
二，抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员；
三，组织客户方进行确认测试或发布β版本。
尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”！不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标——保证项目最终产品的质量！
软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。
来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。
——引自《管理智典》
管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：
第一、风险识别：
从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。
第二、风险分析：
对风险出现的可能性和潜在的危害性进行量化分析。
第三、应急计划：
如果识别出的风险真的出现，你将采取的应急措施。
第四、风险缓解：
为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。
第五、持续的监控：
跟踪需要管理的风险，寻找风险出现的迹象。
项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：
第一、缺乏合理的进度安排
这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。其次、它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。
第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。
最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。
第二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。
第三、人员的变更
在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。
另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。
同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。
第四、规约崩溃
这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。
第五、低效率
对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。
正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。
精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。
——引自《最后期限》
企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益。
组件级测试
很显然，首先必须开发单个组件，然后才能将它们"装配"成功能系统。因为组件可以进行早期测试，所以在 TAP 中端到端测试是从组件测试开始的。在组件测试中，随着环境的建立，适当的测试也分别实施于各个不同的单个组件上。功能测试和性能测试在组件测试阶段都相当有价值，它们帮助诊断了在整个环境构建前和构建中的各种缺陷。
组件测试中的功能测试
组件级功能测试验证了每个组件所执行的事务。这包括了组件或系统所要求的任何数据转换和组件所处理的事务的业务逻辑的验证。在应用程序功能的开发中，基础设施测试（infrastructure testing）验证并量化整个环境中的数据流量，并以这种方式来同时进行功能和性能测试。数据完整性必须当数据在组件间传递时进行验证。例如，XML 测试在逐个事务地验证 XML 数据内容，并在需要时验证正式 XML 结构（元数据结构）。对组件测试来说，诸如 IBM Rational Robot 这样的自动可扩展的测试工具可以大大的减少用在 GUI 测试和非GUI组件的功能测试上的时间和精力。Rational Robot 的脚本语言支持对外部 COM DDLs 的调用，是非 GUI 对象测试的理想工具。此外，Rational Suite TestStudio 和 Rational Team Test 所附带的新的 Web 和 Java 测试功能，提供了测试 J2EE 架构和使用 java 语言来编写测试脚本的附加功能。
组件级可伸缩性测试和性能测试
与这些功能测试并行的是组件级可伸缩性测试，在环境中检验每个组件来确定其事务（或者说容量）的限度。一旦有足够的应用功能来创建业务相关的事务，事务特征测试（transcation characterization testing）就被用来确定业务事务中的各个定量描述，包括消耗的带宽和后台 CPU 以及内存的占用率。资源测试（Resource testing）将这个概念扩展到多用户测试，从而确定应用程序和子系统或模块中全部的资源消耗。最后，配置测试（configuration testing）可以用来确定哪些硬件、操作系统、软件、网络、数据库或者其他配置上的变更可以优化性能。与功能测试一样，有效的自动工具如 Rational Suite TestStudio 和 Rational Team Test 所提供的那些工具可以极大地简化可伸缩性测试和性能测试。在这种情况下，创建、计划和驱动多用户测试以及监控资源利用率的能力是有效且成功完成资源测试、事务特征测试和配置测试的基础。
系统级测试
系统 "装配"完成后，对环境的整体测试就可以开始了。同样，端到端架构测试需要对整个环境的功能以及性能/可伸缩性进行验证。
系统级功能测试
集成是首要考虑的问题之一。集成测试 ( Integration Testing ) 从数据的角度检查了整体系统是否完成了集成。也就是说，需要互相交互的硬件或软件组件是否通讯正常？如果是，那么，在它们间传递的数据是否正确呢？如果可以，数据应当在系统组件传送的中间阶段被访问和验证。例如，当数据被写到临时数据库中时，或者数据在被目标组件处理之前已经存在于消息队列中时，就应该对数据进行验证。在这些组件边界对数据进行访问能够为数据完整性验证和数据问题的描述提供一个重要的附加尺度。如果在两个数据传输点之间检测出数据错误，那么有缺陷的组件必定是位于这两个传输点之间。 系统级可伸缩性测试和性能测试
可以通过创建一个测试来回答以下关于环境的可伸缩性或者完成情况的问题：
·在系统仍能维持可以接受的响应时间下，最多可以有多少用户同时访问它？
·我的高可用性架构是否可以按照设计的那样工作？
·在加入新的应用程序或者对正在使用的应用进行更新后会发生什么情况？
·最初使用时，系统应该如何配置以支持我们所期望的用户数？6个月之后该如何配置呢？一年之后呢？
·我们只能得到部分功能－－设计是否合理？
这些问题的答案可以通过一定的测试技术来获得, 包括可伸缩性/负载测试、性能测试、配置测试、并发测试、压力和容量测试、可靠性测试，以及失败转移（failover）测试。
在系统容量方面，总体环境测试通常是从可伸缩性/负载测试开始的。这种测试方法逐渐增大目标环境上的负载，直到某些性能要求如最大响应时间达到极限或者特定的资源被耗尽。这些测试的目的在于确定事务处理和用户容量的上限，它们经常会和其他测试手段结合起来以优化系统性能。 性能测试与可伸缩性/负载测试相关，它通过测试特定的业务场景来确定环境是否满足所设定的负载和事务组合的要求。（图 4）
与组件级配置测试并行的是系统级配置测试，它提供了特定的硬件和软件设置下的权衡信息，同时也提供了有效的资源分配所需的度量标准和其他信息。