6.2 决策影响力

如果我们仔细思考决策影响力,会发现通过合理地测试投入,科学地选择测试方法,快速地反馈和准确地评估产品和项目质量,所提供的信息越准确、越及时,对于管理者决策时的帮助也越大,他们就越有信心做出正确的判断。那么,如何提供准确的质量评估,如何使测试的结果和过程对决策产生深刻影响呢?

测试团队的质量评估报告是最有影响力的。因此,大多数团队都是由资深的工程师或者部门领导来完成测试的质量评估报告。我翻出了多年前还在测试团队工作时所做过的一些测试质量评估报告样本,其中很具代表性的一个报告模板是这样写的。

00060.jpeg

以一个版本为v96Fp7的项目作为参考,翻译后如下。

鉴于目前V96Fp7功能测试Qcert的测试状态,我们可以声明正式退出测试,原因如下:

·在产品V96Fp7版本的核心组件Engine中发现多少质量缺陷?[xmz]:0

·你认为目前存在多少可以停止发布的质量缺陷?[xmz]:0

·测试完成的状态?已完成了测试的百分之多少?[xmz]:100%.100%

·是否有把握正式声明测试已可安全退出?[xmz]:Yes

印象里,我按照这种报告方式工作过不短的时间,或许当前IBM团队仍然在使用这个模板。IBM的项目实际上希望通过“项目核心组件的零问题+整个项目零严重缺陷”指标来标定质量达标。而在理想情况下,这两个问题的正面答案隐含着一个推断:客户不可能发现产品的核心组件问题或是严重缺陷。但你现在是不是和我一样,开始有些怀疑这个推断的充分性。所以,如果报告的模型稍稍更改成下面的样子,可能会使得我们的测试报告更有说服力。

鉴于目前V96Fp7功能测试Qcert的测试状态,我们可以声明正式退出测试,原因如下:

·在产品V96Fp7版本的核心组件Engine中发现多少质量缺陷?[xmz]:0

·你认为目前存在多少可以停止发布的质量缺陷?[xmz]:0

·预计多少个遗漏的严重问题将在产品交付后被客户发现?[xmz]:1

·测试完成的状态?已完成了测试的百分之多少?[xmz]:100%.100%

·是否有把握声明测试已可安全退出?[xmz]:Yes

理想情况下,客户会遵循使用说明来使用产品,在产品发布前,使用说明书所涉及的所有用例都已经被反复验证过,绝对没有问题。而我们计划的测试范围绝对要大于这个范畴。由此可以推断出,一旦客户发现了我们测试中未发现的缺陷,直接原因是测试代码没有包含对应的部分,或者说用户没有按照我们期望的方式使用产品。随着产品功能的增加和扩展性的加强,按照产品使用说明来使用产品的用户恐怕是凤毛麟角了。我自己在使用IBM产品前也从来不会仔细阅读说明。

这其实不难理解,一行代码很容易做到“零缺陷”,但开发了100或者1000行代码后,就很难避免“引入缺陷”。有人提出,可以从编程人员每百行代码的出错率来估算产品总共含有的潜在缺陷数量,也有人从经验数据出发来推测质量缺陷数量,而我们真的无从考证哪个方法更为精准,这显然是一个百家争鸣的话题。

我们不妨选择一种,就选百行代码出错率的方法来推测吧。如果团队从事开发工作半年或者更长时间后,则不难得到一个经验数据,即团队或者个人的“代码出错率”,假设这个值平均为20%。我们借此可以推测,当他们新编写或者更改100行代码时,会引入20个质量缺陷。

如果我们对产品的测试是充分的(执行全部的测试用例),假设有10万行新增的代码,第一次测试完成应该能够发现10万×20%=2万行代码出错,开发人员因此要修复所有错误,相当于更新了2万行代码,这又产生了代码变更,则按规律将会有2万×20%=4000行代码可能引入缺陷。于是,我们决定做第二次测试(回归测试),假设本次测试还是充分的,那么第三次对代码的修改和测试依然存在800行错误。以此类推,第四次测试还有160行错误,第五次测试还有32行错误,第六次测试只有6行错误,第七次测试几近1行错误。

我们取的样本数据足够大,因此需要测试的次数多达7次,才能够真正将“顾虑”从产品中移除出去。而假设每次迭代所更新和影响的代码行数是1000行,则测试执行4次以后就能够让“产品预计缺陷数”趋近于零。

上述测试报告中的第三个问题是:“预计多少个遗漏的严重问题将在产品交付后被客户发现?”从理论上来讲,这个数字可以通过计算给出,先根据开发团队的代码出错率推算出总共多少个缺陷,再看我们计划和已经执行的测试次数,二者相减就可以推测出将遗漏多少问题,如果按照我们发现的严重缺陷占所有缺陷的比例,就可以推测出究竟会有“多少个遗漏的严重问题将在产品交付后被客户发现”。

例如,在V96Fp7的测试中我们取开发团队的平均出错率为20%,本次开发团队一共新增和更新的代码行数是10万,经过3轮测试我们发现质量缺陷数为790个,此时就可以得到,如果此刻交付产品,我们预计有800-790=10行潜在的代码行错误,而假设每行错误都折射新的质量缺陷,那么还有10个错误将留给客户,而已经发现的790个缺陷中有79个缺陷是严重缺陷,那么我们推算还有1个严重缺陷未被我们识别,这很可能被客户发现。

基于“平均出错率”的估计的准确度主要依赖于经验值,通过我们的观察,在较为频繁的迭代和有压力的环境下,经验数值往往和预期有很大出入。有的迭代表现得很低,而有时却偏高。采用新技术时,又会增加引入质量缺陷的风险;而在开发人员工作于较为熟悉的模块时,“代码出错率”很低。

这样看来,开发人员的心理状态也对质量缺陷的数量有相当的影响,如果开发团队的氛围比较轻松,出错率就相对低,反之就会高;而如果开发团队非常紧张出错率所带来的不良后果,这种条件下出错率仍旧很低。但介于这两者之间的心理状态往往产生相对高的“代码出错率”。

随着开发经验的累积和自查(单元测试、代码静态扫描)工具的运用,出错率会得到控制。其实,预测遗留问题的最好方法因人而异。例如,你的习惯是善于从宏观入手,对于抽象概念的理解好过对具体规则和实际情况的总结,则不妨凭借直觉给出预测;而那些性格很严谨、客观,喜欢关注细节和寻找问题根源的人,不妨试试以上的精确计算方法。

那么,目前的报告充分了吗?正如我所担心的,一些人质疑“足够好而且有限的测试”,却相信“我们需要做各种类型的测试,直到找到所有缺陷”。但是当我在过去的某个时段猛然意识到这种想法的严重性时,我已经没有更好的词汇来形容思想的解放和价值体系的重新构建带给我的欢欣雀跃了。

通过测试验收报告,我们告知管理层测试进度是100%尝试,并未发现重要的问题,也给出了可能流向客户端的错误数量的预期,好吧,我们长嘘一口气,报告终于交付了,报告提供了准确的质量评估且宣告评估过程完成,我们应该休息休息了……

但是,请等一等,还不能就这么划上句号,虽然我们的报告已经很好,但是报告真的给出了完备和正确的信息以做出产品发布的决策吗?我们有没有误导决策者呢?

下面要关注的问题出在这个“100%尝试”上。在测试执行的计划阶段、甚至更早的策略规划阶段,测试工程师会依据测试目标、测试环境、资源决定哪些测、哪些不测,哪些是有时间、有资源再测等策略。通常,这个过程在测试执行前就要得到批准,在敏捷开发中,测试计划和规划放在团队的产品清单中,测试工程师还要组织团队审阅测试规划和测试用例,以得到大家对评估目标的一致认同。

测试验收报告中对测试覆盖范围的补充说明并不是必须部分,但是作为专业的测试工程师,我们相信只有这样才可以合情合理地说明测试报告中“100%的完全尝试”所代表的意义,它涵盖了我们对承诺工作的严格履行,也显示了我们严谨和负责的工作态度。

鉴于目前V96Fp7功能测试Qcert的测试状态,我们可以声明正式退出测试,原因如下:

·在产品V96Fp7版本的核心组件Engine中发现多少质量缺陷?[xmz]:0

·你认为目前存在多少可以停止发布的质量缺陷?[xmz]:0

·预计多少个遗漏的严重问题将在产品交付后被客户发现?[xmz]:1

·测试完成的状态?已完成了测试的百分之多少?[xmz]:100%.100%

·是否有把握声明测试已可安全退出?[xmz]:Yes.

补充测试点覆盖范围报告:

·平台覆盖(如图6-1所示)。

00061.jpeg

图6-1 平台覆盖测试计划

·功能点覆盖(如图6-2所示)。

·测试领域覆盖(如图6-3所示)。

00063.jpeg

图6-2 功能点覆盖测试计划

00064.jpeg

图6-3 领域覆盖测试计划

至此,这个测试退出报告就非常棒了。不但提供了准确的质量评估,而且提供了质量评估的证据。管理团队应该可以根据这个报告做出选择,我相信测试工程师的专业性和工作态度也将得到认可。