这个故事说明了流程以及测试的重要性。
银行在香港的某系统目前每天在下午三点后就会停止交易。
IT接到用户最新的需求是要将每天的截止时间延迟到下午六点钟。我们暂且不讨论用户为什么会有这样的需求，总之IT接下了这个需求变更。
那么接下来就是做impact analysis。大家发现仅仅需要修改一个参数，把cutoff time设成下午六点就可以了，非常简单，开发人员自己测试一下也行。于是很快通过了审批，修改，测试，上线。
上线的第一天，出事情了。本以为下午三点钟之后的交易依然可以进行，结果所有三点之后进入的交易全部被hold在了pending queue里面。银行只能紧急手动处理所有交易。
在事故评审的时候，有人质疑impact analysis做的不全面。也有人质疑：“你们到底测试了没有？”。回答说：“试过了啊！测试环境里三点钟之后是可以交易的啊。”再深入一查，原来还有另一个参数起作用，在测试环境里面的为了测试方便，是设成所有交易都通过的。
好了，这下，到底是哪个环节付主要责任呢？impact analysis, 测试，还是环境呢？各个环节都出现了问题。但还有一个隐蔽的问题大家没有发现。这时候有个与会的测试专家说话了：“为什么不试一下7点钟是不能交易的呢？”大家都静了下来，好像都悟到了什么。
专门的测试组的价值在这里体现出来了，一个全面的测试计划包括normal cases和exception cases是完全有必要的，当然不一定要很复杂。流程上面千万不要忽视了专业测试人员的建议和参与。