三角形测试的小实验

三角形测试的小实验

What I Thought About The Experiment of Triangle Testing


 

到目前为止,我在不同的场合做这个三角形测试的小实验已有4次了,结果都比较雷同。现在就拿最后这次实验-台北20180516这场-为例,分享一下我的一些看法,因为台北这场的采样点比较多,数据分析更可信,现场参与者接近130人,不过遗憾的是,我最终只拿到73份测试结果(部分数据已遗失、还有部分人员可能是没有上交test result sheet)。

 

实验的过程

被测对象是一个判断三角形形状的小程序,网址是:http://www.developsense.com/triangle/triangle.html

 

整个实验过程基本上按照一般的测试过程进行:

了解需求-->测试计划-->测试设计-->测试执行-->测试报告

 

  • 了解需求

 

我会简要介绍一些需求:输入是三角形的三条边,分别是a、b、c,输出是三角形形状的判断结果,包括:一般三角形、等腰三角形、等边三角形、不是三角形这几种情况。

 

  • 测试计划

 

粗略的计划:设计10个测试用例,投入1个人做测试执行,时间是10分钟。

 

  • 测试设计

 

事先准备好的10个待测试用例如下:

 

  • 测试执行

 

要求现场每个人独立完成测试,可以使用笔记本电脑,也可以使用手机测试。

测试时间一共是10分钟。

 

  • 测试报告

 

要求实验者在测试执行后,填写如下简要的报告:

(注:其中Quality Evaluation从左至右分别对应1分到5分。)

 

实验结果分析

以下是73份测试数据:

 

1. 测试中发现了什么

作为一名测试人员,每完成一次测试,应该具备准确无误地描述测试结果的能力。本实验揭示,“Telling Testing Story”的能力普遍堪忧。

 

有这么几个明显的问题:

 

  • 测试报告中数据统计错误,比如第61条:6-6-4-3-2,Pass 6个,Not Pass 4个,那么总共执行的不应该也是6个。类似的统计错误还有不少,比如将pass 和not pass的数据填反的、不知道某个结果是否应该计入Unexecuted,等等。各位可以在原始数据中继续寻找。我在录入数据时,发现不少自相矛盾的数据。

 

  • 对发现的缺陷缺少必要的记录,每个人发现的缺陷数目不尽相同,可是绝大部分的“Test Result Sheet”上对于所发现的缺陷都缺少哪怕是最简要的记录,如下面的例子所示。虽然测试时间只有10分钟,当发现缺陷后做些简单必要的记录还是很需要的,况且据我现场观察,绝大部分人都可以在4~5分钟左右就完成了这10个用例的测试,所以时间紧张应该不最主要的原因。某种程度上说,“发现缺陷做必要的记录”这基本上已经成为了一个测试人员下意识的动作,而实验的结果恰恰相反,这也许值得我们深思。

 

 

  • 质量评估缘何如此?对于最终的质量评估这块,有三个方面值得关注一下。

 

  1. 同样的测试结果统计数据,不一样的质量评估结果

 

比如占比比较多的“10-9-1-1-0”这组数据,最终给出的质量评价一共有6种,有人认为质量很好,有人认为很差(并且没有给出具体原因):

 


我想,这也警惕那些managers,不要只看表面的数据,这些数据讲的话未必都是对的、完整的,而是需要与testers面对面交流,了解更多的真实的关于测试、关于质量的信息。

 

当然,这也充分表明了“质量是主观的”,同样的被测对象、同样的测试用例、同样的时间投入、同样的测试结果统计,结果却是相差甚远的质量评估。(当然这个小实验,在演讲现场,想要表达的是“即使按照标准的测试流程操作了,然后报告所发现的问题以及测试进展,仍然无法知晓真实的质量”。关于质量,有很大一部分是在冰山之下隐藏的,详细信息可以观看演讲视频了解。)

 

 

  1. 不知道如何评估质量

 

12%的人,test result sheet质量评估为空白。还有一些人,虽然给出了质量评估,却与前面的测试统计数据表现出来的质量截然相反,又没有额外的补充信息加以解释。比如“10-9-1-1-0”质量评估为1,当然,这其中不排除理解错误,所以填写有误的情况。

 

  1. 没有标记为何如此评估质量

 

只有6张,即8%的人,在test result sheet上给出了部分解释,为何会如此评估质量。绝大部分人都没有给出任何解释。

 

 

2. 做了哪些测试

如果观察第一列Executed的数字,会发现绝大多数都是“10”,这很有趣。

 

是否这10个用例就是最重要的用例呢?看起来,绝大多数人是这样认为的,于是他们会优先执行这10个用例,如果有余力,再做些探索(这里要严重纠正一下这样的观点:其一,探索在测试中无处不在,只要是人在测试,执行用例本身也是在探索,只不过更多的是围绕着用例探索罢了;其二,不必非得先执行完所有的用例,再执行其他之前没有计划的部分,好的测试过程一定不是由测试用例主导的)。

 

其实这10个用例是我随意设计的,我只是想观察如果给tester一些用例,他是否很容易被束缚在这个范围内?结果显示,基本上很多人的思维都受限了。

 

绝大多数人都忘记了,想要测试,首先要learning:通过探索被测对象,来学习了解被测对象,这是第一位的。执行完这10个用例,与“了解被测对象”和“探索质量相关的信息”相比,在绝大多数情况下,并不是那么重要。你是否注意到了,用例里并没有谈到任何关于三角形颜色的问题,我在描述需求时也没有提及?你是否注意到,我对可输入数据的范围并没有提及?你是否注意到,我对三角形将如何显示出来,也没有提及?所有需求中没有提及的、或者你之前未知的这些信息,不需要先learning吗?无论需求文档写的有多么细致,当你与被测对象交互的时候,总是会有些新的未知的信息冒出来,所以边探索、边学习、边测试,是必选项,不是可选的。

 

从这些结果表单上看,额外做的探索并不是很多,多数都局限在测试用例的范围。

当然,“探索”的成分比较少这个问题,不能归咎于测试用例,而是更多地取决于测试人员的探索性的思维和技能。对于优秀的测试人员来说,测试用例只是个参考和辅助,绝不会束缚他的测试范围。

 

而且,我在设计这10个用例时,故意埋了一个坑:选择了测试数据655356553465533。如果我看到这样的用例,首先就会思考,65535是最大值吗?于是尝试一下65536。如果发现65536也能通过,那么就免不了继续探索其边界值究竟在哪里?当然,这个时候,也有可能,先做个记录,把这个疑问记录下来,留待后续探索,这就涉及到测试人员的self-management skill了。

 

我在现场观察时,发现很多测试人员测试到这个貌似边界的用例时,很轻松地标记用例为pass,然后测试下一个用例。我想,这大概表明,他们在按照测试用例测试的时候,完全没有思考这些问题:为什么要测试这个用例?设计它的初衷是什么?有什么疑问?有什么与此相关的地方需要探索?如果一个测试人员只会follow事先写好的test case,那么他顶多算是个checker,不能叫做tester。(关于checkingtesting的区别,请参见这篇bloghttp://www.taixiaomei.com/others10.php

 

作为本次实验的设计者,我更希望看到的结果是Executed=10的结果,比如第5910365961列,我很想知道他们做了哪些我不知道的实验和探索、他们是否发现了一些我不知道的问题和风险。毕竟,对测试人员,更有价值的活动是探索,更有价值的信息是我之前未知的与质量相关的信息,如果他们告诉我的信息都是在那10个用例范围之内的,并且大部分都是pass的用例,没有什么新奇的,对我来说,No New Information = No Information

 

3. 为什么做这些测试

遗憾的是,实验中没有一个人勇敢地站出来,问我这样的问题:为什么要测试这个小程序?我把这样的技能叫做KYM - Know Your Mission。如果现场有人这样问我,那是给我的最大惊喜,我一定会亲自把“海盗小蛋糕”奖励给他!

 

在考虑具体的whathow之前,绝大多数情况下,我都建议测试人员首先要考虑的问题是why。为什么要测试它?这个产品是给谁用的?主要的使用场景有哪些?需要我提供什么样的测试服务(反馈什么样的信息)?等等。

 

事实上,在这个网址下http://www.developsense.com/triangle/triangle_spec.html,有这个小程序的需求描述,虽然很简单,也不难发现,这个程序主要是为了训练和提升测试人员的测试技能而用的。那么,所有发现的bug也就不是通常意义上的bug了,这些bugs有助于程序的终极目标-训练testers,因此反而变成了feature。那么,相应地,质量评估也要重新做了。After all,如果我们都不晓得程序的目的是什么,如何给出准确的质量评估呢?如果我们都不了解Stakeholders的期望,如何让他们对我们提供的测试服务感到满意呢?

 

结语

需要补充说明的是,这些问题,并不是只存在于台北的IT人中,实际上我在上海的交流与会议上,做过同样的实验,结果没有太大差别。

 

虽然这只是个mini实验,却也反映出当下IT人在测试技能方面的欠缺。除去上面谈到的telling your testing storySelf-managementKYM之外,还有很多技能,比如taking notes abilityexploration abilitydetecting defects skillsrisk identification skillsasking right questionscritical thinking skillsmodeling skills等等。这些技能也都是做好Exploration必须的技能,而本实验也反映出Plan Based Thinking在测试界仍然大行其道,虽然我很不情愿承认这一点。

 

 

 

Comment Box is loading comments...