6.4 “等待”和“浪费”

当我面临手指头数不清的质量缺陷,而计划退出测试的时间所剩无几时,我会毫不犹豫地告诉团队,请利用你们仅剩下的所有时间尽可能地多做测试,这样做有些隐蔽地推卸责任,但我们确实对产品没有信心。我的团队非常配合,然而这种穷尽所有时间来测试的状态一直没有好转,甚至激增了测试团队的焦虑情绪,甚至弥漫开一些抱怨和责难。我开始认真思考这个问题,问题到底出在哪里?我们为什么始终不能从容应对产品的质量评估工作?

首先,一定是“浪费”。我们没有在最好的时机进入测试,因此浪费了最佳排除问题的时机,直到最后留下一大堆复杂问题的时候,才发现问题多得没有时间来排查也更没时间修复。

其次,就是“等待”。工作流程中,不仅仅是测试相关的流程,一定有一些不能弹性变化的刻板固执或者必须上级领导批准的流程让我们“一等再等”。为什么要屈从于实则不合理的流程、浪费大好光阴呢?我们一定要找到问题,将其根除。有了这个想法后,我们开始看到一些并不容易发现的、但存在已久的问题。

1)活动的价值部分从发现问题开始,直至解决问题,而往往我们实际所支配的时间远远超出了这段价值活动合理时间十几倍,包括消息的传递至消息被阅读的时间,问题被认领的时间,以及因为繁琐的流程所耗费的时间。例如,当我们从客户那里获取需求后,需求工程师要将其转化成需求文件并写入需求文档管理工具的数据库,然而需求工程师正在休假;又例如,当需求工程师通知团队,需求已经进入数据库,需要寻找一个大家合适的时间来审阅需求,但因为重要的决策者或者审阅参与者有更重要的会议和工作要处理,这个会议邀请被安排在两天后;再如,因为需求不详细,前期测试工程师和开发工程师对需求的理解有很大出入,因此在开发工程师交付工作和测试工程师开始测试时,测试工程师发现准备好的测试环境已经不适用于新代码、新功能的测试,测试环境必须重新处理,而这个过程需要IT部门花费8小时时间进行软件更新和各种参数的重新配置。

2)活动的价值部分被重写,之前付出再多再有价值的工作,此时都毫无意义,而我们已经追悔莫及。例如,因为测试后期发现了极其严重的问题,产品需要重新做大改动,这个改动不得不推延了整个发布时间;或是需求工程师因为种种原因不得不在开发已经开始了一两个星期后推翻之前的理解和用例设计,且团队此时无论是接受新设计还是拒绝配合,这个活动价值部分已经不复存在,之前做的工作均没了意义。

3)活动开展前忽视了风险的存在,或者盲目应对潜在的风险,因而,风险一旦触发,就像太平洋上空的蝴蝶效应,倾刻引起大西洋海面海啸。当产品的新功能很大程度上基于第三方软件的能力时,而这个第三方软件并不像提供方所承诺的那样稳定和完整,我们的工程师不得不陷入紧张的焦灼期,产品所有的工作不能按时退出,直到这个第三方产品的问题得到解决方有所改善。有时对产品大动干戈地替换整个类,测试工程师不得不因此重新审视测试计划,并做较大范围的回归测试,以确保先前的功能一切正常。

4)除了这些外因,我们也发现由于自身局限性造成了不良后果。对于“测试可进入条件”的过分依赖,对责任的过度负责,使我们成为了流程改进和提升活动价值的阻挠者。例如,我们害怕过早进入测试,在没有完整代码发布时,我们挑剔地选择了忍耐或等候更好、更稳定的版本。

综上所述,测试的投入或者团队任何人的投入都需要考虑如何利用现有可控资源迅速抵达目的地的问题,而不是如何更快地完成计划的问题。所以,为了实现合理的投入,我们(从测试角度出发)需要建立起大局观,了解团队的最终目标、完整的开发流程以及阶段性的成就和目标,了解可能存在的风险,包括来自天灾或者人祸的风险,并且一定要做好计划B,以备不时之需。

最后,我建议测试团队做出如下改进:

1)拒绝“等待”,如果能够提前开始工作,可以模糊测试和开发的工作界限,甚至参与到更早的需求分析中以直接发现和评估产品的质量。

2)“静态测试”与前期需求的分析和拆分细化非常重要,不为不完备的需求和缺失设计部分做出假设,并延期我们的“承诺”。

3)尽管不用读懂开发工程师的每行代码,但需要和开发工程师充分沟通接口技术,理解代码集合、函数具有的意义和业务逻辑中所承载的工作的定义和发生顺序,以知道如何“捷径”测试。

4)尽早尝试未执行过的测试用例,一经发现测试过程受阻,及时报告问题,自动化“关键路径”测试的做法一直以来都值得称赞。

6.4.1 仅仅足够好

合理的投入,需要有严谨和科学的测试方法,以及“仅仅足够好”的态度。好的测试路径设计更重要,最佳路径好比在扫雷游戏中用最少的点击数找到真的地雷一样,测试需要仔细选择尽可能不重复路径的测试方式。例如,一般的测试环节,我们将“登录组件”和“业务组件”分开设计测试用例;根据每个组件的可输入数据特点,用“边界值数据、非法数据、常用数据、最大数据和最小数据”等方法设计测试方法;而测试“业务组件”又必须经历“登录组件”,因此如果将两个组件有机组合起来就会发现,一半的测试用例就可以完备地覆盖两个组件的测试了。

又如,测试平台操作系统、语言版本、后台数据库平台的组合选择本身就是一个特别浪费和重复的过程,不可能在穷尽一种组合环境的测试后,将n倍放大的测试工作量分配给团队来满足对多个平台、语言、后台数据库兼容性的验证,而采用一般性平台的验证方法可较为灵活。

1)交给平台测试团队,或者自动化测试团队,将关键测试用例自动化运行起来,使得发布多版本后基本可以保障产品的环境兼容性和稳定性测试需求。

2)如果有条件可以将功能测试点随机或者按照环境权重比例分布到所有测试平台和环境上,像“梯田”一样,对一般性的测试用例不需要重复地分割到各个平台和环境中,对于重点和关键路径,测试用例可以重复分配。

在此基础之上,可以优选一两个重要的组合方式,例如,尽量选择与客户环境接近的环境组合方式,在IBM的行业术语中,我们把这种系统的拓扑结构叫做“Golden Topology”,以实现较为完备的测试,测试工程师不用频繁切换工作环境因而测试效率提高。同时,在一些并不重要的平台上可以做“技术忽略”,也就是放弃测试。再有,就是针对特殊需求,例如用户流量逐步增加但目前仍然小众的平台和系统,我们可以只做关键路径测试,或者更小的冒烟测试。

6.4.2 理性规划

合理的投入,需要谨遵可持续性发展的战略来竭尽资源达到工作目的。在过往的多个项目中,我们因为不能合理计划工作量,错误估计或者少估计工作量,太过乐观地评估产品的质量,致使测试工程师不得不避重就轻,选择更多的容易执行而不易发现错误的用例。在根本完成不了数量指标的前提下,测试工程师会尽可能少地尝试那些容易发现错误的测试方法、路径。通常容易过于乐观估计的工作量的环节如下。

1)测试准备工作,环境的搭建。原以为搭建好一个环境就可以了,但是往往会出现一些非常奇怪的问题,只有这个环境可以再现,而仅仅是重装或者换一个环境就可以解决。我们很少能够从这种错误中找到有价值的答案,因此最好在计划测试准备工作时,增加一些重建测试环境和修复测试环境错误的时间。

2)测试用例的执行时间。一般我们会使用平均时间乘以测试用例的数量来规划我们的测试执行时间,而需要指出的是,发现一个问题时,不是执行一遍而是执行至少三遍,因为第一遍发现错误后需要跟踪和研究,势必再至少执行一遍,当问题得到解决以后,又得执行一遍来验证这个错误。所以,往往因为发现缺陷数量超出预期使得测试用例的执行时间远远超出预期。

3)被阻断的测试时间。我们虽然建立了良好的沟通渠道、及时的反馈机制,每当发现问题,一定第一时间报告,但是一旦“满身虱子就不再怕咬了”,许多问题长期得不到解决或者不能完整地解决,因此在这些问题发生后,而又没有解决的前提下,我们继续测试相关功能点就失去了意义,因此,我们选择停止这个角度的深入测试工作,测试因此被阻断。如果出现了最关键和最低层的错误,那么整个测试团队都可能被阻断工作,其后果将给后期的测试带来非常大的压力。

4)报告、开会、被打扰的时间。很少有人去计算我们每天花在报告、计划、其他文书上的时间以及开会的时间,我们总喜欢乐观地估算自己每天的工作量是饱满的,没有打扰(也经常不愿意被打扰)。很久以来,我们一直在处理又紧急又重要的事情,偶尔不得不被迫参加一些领导安排的会议,接着继续追赶进度,永远有一大堆事情拖着、等着,如果是这样,那么一定是我们过多地承诺了工作和背离了“可持续化发展”原则。我发现合作意识越好、越在乎别人的情感和想法,以至于总是给予别人额外的关心和帮助的人,越容易过高承诺工作量。