只有验证 才可交付
                --由一个典型的错误所想到的

“只有验证，才可交付”，在软件工程领域，这似乎是一个非常简单的、连一般的软件工程师都懂得的道理，然而在实际工作中，这一基本的原则往往得不到贯彻执行，常看到以下这种情况。
五月份，WB4.2作为标准版，正在不断出货。“不断出货”意味着客户在不断发现问题（bug），同时也有很多客户提出新的要求、合作厂商过去OEM了我们的一款产品叫做WB CETC专用版本，现在要将WB4.2作为被OEM的对象。所有这些，都要求WB4.2需要不停地升级和改动。
这时候，为了应对市场需要、击败竞争对手，我们要在WB4.2中增加一个新的很复杂的功能：文件加解密系统。
在一个动态的不断变化的WB4.2中增加一个大功能，我们面临着两个选择：
第一，将WB4.2的代码库（code base）复制一份，变成两个代码库：code base  A和code base  B。在code base  A上继续修复bug, 增加用户提出的一些新（但都不是很复杂）的功能，以满足出货要求；在code base  B上，开发文件加解密功能（很大、很复杂的功能），因为文件加解密功能的开发可能对WB4.2带来很大影响，可能引入很多新的bug，在code base B上开发文件加解密系统不会造成影响什么影响。见图一所示。时刻保持两个代码库同步，一旦code base B加“文件加解密系统”变得成熟、并可以发布的时候，抛弃code base A（因为code base B=code base A）。
这种方案的好处是，在开发文件解解密功能时，其可能带来的很大风险不影响当前客户的出货要求；这种方案的坏处在于，保持两个代码库同步（即：使code base A中改正的bug或增加的小功能体现在code base B上）是一件很难的事情，需要手工将修改好的代码同时往两个代码库中存放（check in）。手工存放操作是很费事的，且为了保证code base A和code base B的一致性，除了测试没有别的办法，而测试两个功能一样的系统是巨大的浪费。
 

第二，用一套代码，直接在代码库中增加文件加解密系统，同时修复一些原来系统中的bug、增加一些新功能以满足特殊客户的需要。这样做的好处是，只维护了一套代码，省却了同步的烦恼；其坏处是，文件加解密功能可能对系统造成较大影响，当前正在等待出货的客户要求可能不能及时满足不。
尽管第一种方案存在很严重的缺陷，但经过仔细研究，我们还是决定采用它。但同时要求，在code base B上进行的文件加解密系统一旦稳定之后，抛弃code base A。做出这个决定是2007年5月份的事。
5月份到8月份之间发生的事情是这样的:
在code base A上，测试组测试该代码生成的系统WB4.2，不断发现的bug一个一个地得到修复；客户不断提出的增加新功能的请求（都是一些非常小的功能，有些类似于bug修复、而不是新功能，且都得到批准）也得到实现；将OEM的WB CETC版本中功能替换掉，代之以code base A生成的系统。这样，code base A所生成的产品越来越成熟，其产品在很多客户处使用着。
在code base B上，开发着文件加解密系统，另一部分测试人员对这个功能进行着仔细的、较为全面的测试，但这个测试与code base A上的测试不同，在code base A上的测试是只测试code base A所对应的产品功能，而在code base B上的测试只测试文件加解密功能，code base B上的功能不被测试。
经过三个月的开发和“文件加解密系统”功能的测试，8月14日，召开了发布会议讨论文件加解密功能的发布。在产品发布会议上，有人建议将code base B代码加上“文件加解密系统”的代码，这两部分代码合成在一起生成新的build，因为code base B是code base A的映射，“应该没有问题”，因此这个build可以作为发布的候选（Release Candidate）。
这是一个严重错误的建议！
为什么呢？答案是显而易见的：因为code base B对应的功能没有得到验证。那些提出上述建议的人，主观地认为code base B是和code base A经过了手工处理（所谓的代码同步check in），所以code base B是无须验证的。
code base B对应的部分要进行验证是毫无疑问的，任何软件不经过验证是不能发布的。况且，在code base B和“文件加解密系统”代码之间，不可避免地、必然存在一个“藕合区”（见图二）。所谓藕合区，是指这部分代码是由于两个部分集成到一起所增加的必要的代码。显然，这个区域的代码被那些人忽略了，尽管这个藕合区很小。
 

这个藕合区的代码既没有得到验证，也没有在上面的“同步”的范围之内。
所以正确的做法应该是，使得code base B、藕合区和文件加解密系统代码一起，生成的build得到充分测试，才能作为发布的候选者。只有当这个发布候选者满足发布条件、并确认该发布涵盖所有code base A的所有功能（包括性能要求）时，才可以抛弃code base A。

软件是一个非常复杂的系统，是看不见也摸不着的逻辑产品，没有严谨的态度和充分的验证，是无论如何也开发不出一个可用的产品。以下倾向在工程师中间常常出现，上面的例子只不过是这些观点和倾向比较集中的体现：
一、“以为没问题”就交差。这种现象不仅出现在产品发布阶段，也体现在每一个软件过程中，体现在每个工作产品（work product）的提交上。他们往往主观地判断“可能没错误”、“应该没错误”，这些都是非常错误的观点。在保证软件产品质量的措施中，验证（Verification and Validation）是必不可少的。“以为”是正确的地方偏偏发现有问题，这样的例子太多，其教训也是非常惨痛的。“没有验证，决不能交付”是软件工作者必须遵守的铁定的规律。
二、把“增量测试”作为发布前的验证。由于时间紧任务重，测试工作做不完，于是只对那些改动了的部分做一些测试，还美其名曰“增量测试”。这是一个非常危险的举动，因为任何改动所波及的范围是事先很难估计出来的，其潜在的、隐形的影响更是无法估计。很多莫名其妙的问题（Wicked problem）就是由于考虑不周引起的。发现并排除这些问题，只有靠软件验证，别无他路可走。
三、自动化测试是好的，但不是必须的。持这种错误观点的人，没有认识到软件测试的难度和软件自身的复杂性。竞争加剧，软件需求变化快，用户要求千奇百怪、甚至相互矛盾，研发部门虽然对各项工作作出了优先级识别和排列，但是，计划没有变化快。在软件开发的实践中，测试速度成为软件开发的瓶颈。一个修改后的软件，到底对其它地方有没有构成影响，局部修改后整个系统还能不能工作？不准确清楚地回答这些问题，产品质量就无从考察。要回答这类问题，没有自动化的测试手段和工具是不可能实现的。所以说，自动化测试不仅降低了测试者的劳动强度，更主要的是自动化测试成为软件质量控制过程中必不可少的手段。有了自动化测试，一个build很快就可以得到验证，不会出现“没有时间”就只能做“增量测试”的情况。
错误做法和倾向还有很多，在此不能一一列举。很多人喜欢把这些归于客观因素，道理都明白了，就是没有精力做。其实，这些人并没有正确认识到验证在软件开发环节中的重要作用。树立正确的服务意识，把客户牢记在心中，坚持“只有验证 才可交付”的原则，是每个职业化的软件工程师应具有的起码的素质。