现在主要在知乎,地址:https://www.zhihu.com/people/qqrrm 老的文章在:http://blog.csdn.net/pyp

开发对于测试的误解问题回复

上一篇 / 下一篇  2018-05-27 15:25:01 / 个人分类:测试

原文在https://zhuanlan.zhihu.com/p/37288095,格式更清晰些,紫色部分为原文引用。

今天看到一篇文章关于质量保障部(测试)人员的测试管理及KPI工作的思考与讨论》,感觉里面对于测试方面的看法基本都是错误的,但是其中的一些观点很有代表性,就详细回复解答了一下,在这里重新做一下整理和记录


因为研发管理不可避免的和测试打交道,会深入到测试管理的种种利弊中,所以今天因为一个问题和测试争论很久。

故事是这样的:今天团队的一名新人截图告诉我说,测试提的bug,他标记外部原因后给测试,测试又打回来,并回复“请修改状态为已解决”。

新人就表示了不理解,因为bug的本身是因为研发中需求变更导致产生的历史错误数据干扰,上线后不会有这个情况,严格的说也确实不应该是研发的开发bug。

但是测试缺认为,虽然你是历史数据,但是我确实发现了问题,你标注外部原因,是对我工作的否定。

经过沟通,确认了问题的核心是,测试对BUG数量,BUG等级,BUG有效率进行了绩效管理和考核,而《外部原因》这个状态的bug不会算在有效BUG统计中。

也就是说,开发和测试对这个BUG的状态共识并不一致。

测试角度释疑:

个人一直不建议测试人员和开发人员对于缺陷是否需要修改直接进行交流,因为太容易产生文中的矛盾。个人觉得比较理想的状态是缺陷提交后有一个确认过程,比如通常每天测试完成,个人习惯找项目经理确认当天发现的缺陷,确认哪些是缺陷哪些不是缺陷,或者确认是缺陷但是项目经理认为可以暂时不修改,因为不涉及具体的修改缺陷的开发人员,所以即使开发人员有意见认为不需要修改,请先去找项目经理沟通,项目经理确认后再和测试负责人重新对缺陷进行确认。这样通过中间人不易产生矛盾。

开发人员可以说测试人员提交的缺陷不是bug,这是很正常的行为。但是对于一个问题是否是缺陷测试人员有自己的标准,此标准不会以开发人员的看法改变。当缺陷出现争议的时候应以测试人员为准,因为缺陷为测试人员提交,需要测试人员确认验证后才能关闭,开发人员责任仅限于缺陷修改。

对于文中的历史遗留问题,开发方既然知道是问题,那么在测试的角度就是缺陷。测试通常没有必要理会缺陷发生的原因,缺陷存在就是存在,开发人员的职责是把缺陷处理掉,至于开发人员说上线等非技术手段就能处理的问题,在测试这边是不存在的。因为太多情况下开发人员都是在应付,即使到线上环境,此问题也未必会解决。测试人员遇到过太多类似的事情,所以很多时候不会信任开发人员的解答,只有修改并经过测试人员验证过的缺陷才能关闭。


定义
探讨这个问题,我觉得首先要定义清楚两个个事情:
1、BUG其实是要分两种类型的。
即 生产BUG 和 测试BUG。
这两个问题应该单独管理并分开讨论。很多公司对于这两种问题从工具到认知都是分开处理的。
2、定义一个名词《真实bug》,也就是开发完成交付后,测试拿到的研发成功他客观真实存在的真实bug数目。
这个不等于测试提交的bug数目。
生产bug越少,测试bug越接近真实bug。
测试bug完全等于真实bug时,生产无bug。

测试角度释疑:

测试人员的工作是发现缺陷,无论什么样的缺陷,和缺陷数量无关,和缺陷质量无关,缺陷就是缺陷。

对于测试人员来说,并没有区分什么生产BUG、测试BUG、真实BUG的必要性。测试人员都了解缺陷具有无尽性,只要有时间,总能发现新的缺陷。

项目需要考虑进度、成本、质量,测试过程同样需要考虑这些内容,需要在有限的时间内发现尽可能多的缺陷和影响比较大的缺陷,这才是一个测试人员体现价值的地方,所以才会有需求评审、测试计划、测试用例等等。

总之,生产BUG、测试BUG、真实BUG在测试人员这里没有必要区分,因为定义本身就是有问题的。


什么是质量保障工程师
我们再来明确下一名质量保障工程师的定义,测试人员都喜欢叫自己质量保障工程师,部门叫质量保障部,那么顾名思义,测试 就是进行质量保障的。而保障的质量,当然是上线的质量,而不是开发后,那是开发的事,测试能决定吗?
所以一名合格的测试,首先要保障上线后的bug数目小于预期。上线后能够尽可能的没有bug。
也就是说,测试工作的究极目标,就是要上线后没有bug,至于需求分析、用例编写、测试、回归,沟通,管理,这些过程,都是为了实现最终目标的手段和方法,那么这个过程中产生的bug数目,即测试bug,还有意义吗?什么才是有意义的呢?

测试角度释疑:

没有质量保障这个叫法,通常说的是质量保证。质量保证是QA(Quality Assurance),QA主要工作是检查流程是否符合预定目标,比如项目计划说要有需求,那么QA人员会在计划时间检查是否需求人员完成了需求文档,需求文档是否进行了评审。测试主要工作针对产品,发现产品中的缺陷。

虽然很多非测试人员都认为质量保证和测试两者是一样的工作,但实际是不同种类的工作。一个测试人员通常不会叫自己质量保证工程师的,我们只会叫自己测试工程师。

现在在很多公司,确实不区分QA和Test,工作内容也同时包含两者,但是两者实质确实不同的工作内容。

质量是产品的内附属性,可以认为无论是QA还是Test主要是为产品的质量目标服务。产品开发出来,质量上限实际就已经决定了,Test可以通过工作使产品努力达到质量上限目标;但是开发和QA可以提升这个质量上限,比如QA可以要求开发做单元测试和集成测试,而测试通常是没有这样的权利的。

测试的工作内容是尽可能的发现产品的缺陷,对产品上线后的问题通常并不关心。这里有一个测试清除率的概念,就是测试的缺陷没有在当前期间发现,遗留到了下一个阶段,这个可以对测试做一个考核目标,但是并不是测试人员关心的问题。测试人员只会关心当前阶段如何尽可能多的发现缺陷。

测试可以认为是对质量属性的一种度量,通过测试发现的缺陷,可以了解当前产品的质量情况。比如测试发现的缺陷较多,可以认为产品的质量较差,并不是缺陷全部处理了,就认为产品质量好了。因为发现的缺陷越多,可以认为没有发现的问题更多,产品本身质量就有问题。还是那句话,提升质量更多靠的是开发人员和QA,到测试这里,一切都已经太晚了。


传统kpi的参数分析
1、bug的数量和bug的级别
我认为,测试过程中的bug数目,bug等级,统统没有任何意义。因为各个需求复杂度不同,各个需求开发人员不同,开发周期不同,开发质量不同,这些会决定真是存在的BUG总数就不同。
比如需求A ,到交付时,真实BUG数目是100个,测试测了60个,其他40个上线了,这算成功吗?
比如需求B,到交付时,真实BUG数目是10个,测试测了10个,其他0个上线,这算失败吗?
结论:比较两个分别负责需求A和B的人员 产生的bug数量和bug级别,没有任何意义。因为你也不清楚真实bug数目,并且无法预估。

测试角度释疑:

只要在测试用例的覆盖范围内,测试发现了多少缺陷就是多少缺陷,即使测试阶段测试人员发现了10个问题,到客户那边发现了1000个问题,也无法说测试人员是失败的,因为测试人员可能已经在他的工作范围内尽力了,测试人员都清楚并不能用缺陷数来度量测试成功或失败。

在通常情况下是可以对缺陷进行预估的,比如CMMI到4级后,度量数据都应该限定在一个比较确定的区间范围内,缺陷数据也不例外。无论是测试缺陷还是现场用户缺陷,都是可以在计划阶段就预估的,只是需要很**的开发流程和一定量的成本。


2、bug的有效率
有效率的定义应该是 bug是否是有效的,所谓有效,那其实就是 bug是否是bug,这个当然是有意义的。但是其实对于中高级以上的测试,既然提出了bug,很少是使用方式,或者执行流程造成的不是bug的无效bug,所以这儿数值,能力达到一定程度,变化并不会特别大。
另外这个值其实从统计学上,仍然具有缺陷,即数据量样本越大,也就是越大的需求,越复杂的需求,出现无效bug的概率越高,有效率月低,所以并不能完全说明什么。
结论:bug有效率,有一定程度的意义,kpi占比可以较低。

测试角度释疑:

这段我从头到尾都没有看懂什么意思。缺陷就是缺陷,没有是否有效的区别,每一条缺陷都是有意义的。

感觉答主对中高级测试有误解,中高级测试是可以用更好的手段发现更多的缺陷。举个例子大概说明一下,比如初级测试人员的工作可能只是执行测试用例,中级测试人员负责编写测试用例,高级测试人员可以通过开发测试工具、优化测试流程、通过对业务的熟悉编写较少的测试用例发现更多的问题等等。无论初中高级测试,绝对没有什么高级测试发现的缺陷就一定比中级的好。还是那句话,高级测试可能发现初级测试发现不了的缺陷,但是就缺陷本身没有高低贵贱之分,缺陷本身没有有效无效之分。

对于缺陷,测试人员通常使用严重性来区分,比如一个缺陷,可能对于产品质量影响比较大,不修改此功能就无法继续使用,那么可能就是一个严重缺陷;比如仅仅是一个文字问题,开发人员连续使用5个叹号做强调,我可能就会提一个轻微缺陷,告诉开发人员最好一个叹号都不要用,也不要用红色之类的提示,所有的提示要统一风格,避免引起客户的不适感。

开发人员对缺陷的区分主要是优先级,就是修改的顺序。比如一个缺陷,对于测试人员来说可能严重性很高,但是开发人员认为其他缺陷更紧急,测试人员发现的缺陷虽然引发的后果很严重,但是客户很难触发这个缺陷,那么可能就放在最后修改,开发人员会优先修改客户容易发现的缺陷。


应该怎么做?
大家发现,所以一个质量保障工程师(测试),最重大的产出都不具备考核价值,那么我们应该如何考核测试的KPI呢?
根据上文的例子,我们很容易发现,其实关键的问题是需求A开发完成后,他的真实BUG数目是不可预估的,高质量的开发和设计过后,充裕 的时间过后,他的真实存在的bug可能很少,甚至不存在。
相反,低级工程师、不了解业务的人员开发,时间过渡紧迫加班赶工,等诸多因素可能让真实bug较多。
在这种情况下,我们要保障的是 尽可能的发现真实bug,尽可能的让自己发现的bug数目接近或者等于 真实bug数目。
所以,我们为此付出的努力,工作方式,流程,才是我们考核的更重要的部分。

测试角度释疑:

缺陷度量数据是可以预估的。

每个公司进行大量的项目后,只要有一定的测试数据收集和分析,新的项目根据规模、类型等至少可以在数量级范围内对相关数据进行预估。测试工作也都是在一定时间和成本下进行的,所以测试一定也会考虑投入产出比。


1生产bug预期达成比
回到最初关于 “质量保障的定义”,很简单,我们首先要衡量的是一名合格的工程师有没有达到保障质量的目标,即如果上文提到的《生产bug》超出预期,那么工作其实是不合格的。
但是bug预期是一个较为抽象难以量化的东西,只能根据用例复杂度和需求复杂度等具体的需求表述,根据以往经验和团队能力配比,以及时间投入相关,由产品、研发、测试共同制定一个尽可能客观的预期bug数目标准。
比如一个10人/日的需求 ,bug预期是3 ,计算预期达成比。
所以在KPI考核中,生产bug的数目可以占到绩效占比的很大程度.

测试角度释疑:

生产BUG超出预期,可能是因为需求没有做好,产品和客户要的不一样;生产BUG低,可能是因为客户忍耐性高或者水平不足或者你们的产品客户买来根本就没有用。所以生产BUG不建议作为度量目标,因为你无法预期客户的行为。

度量目标通常是在可控的范围内制定,无法受控的度量目标就是在给自己挖坑,有过实际经验的兄弟姐妹都应该懂。


2、用例编写
详细的用例会覆盖客户的各种实用场景,保证在测试过程中尽可能的发现所有的真实bug,而优秀的用例编写又能让测试用最少的时间,完成测试。所以符合规范的、考虑全面的,有逻辑条例的用例编写,是kpi考核的关键参数。
这条其实会和很多人认为的bug级别有关联,有些管理者认为能够发现高级、严重bug的工程师是优秀的,实际上,如果程序真实bug没有严重bug,你又何谈发现呢?但是不管有没有,你的用例应该覆盖的到严重bug,也能考虑到各种复杂场景,这个才是更重要的。

测试角度释疑:

测试过程也是有时间和成本制约的。

测试人员写用例,也需要考虑花费的时间。而且前期的需求、设计文档是否真的和实际产品一致,在测试用例上的投入是否值得。这个话题太大,我也很难细说。

从我的实际经验来看,开发人员写的文档很多都是用处不大的。根据开发文档写测试用例很多时候很难做到,而照着软件写用例,同样的实际我可以发现更多的缺陷。所以测试用例的编写在实际工作中很多还是在测试人员的揣度思考下进行,既要符合KPI的要求,又不要太费时间,还要对得起自己的职业道德,总之不是实际遇到此情况的人员,很难具体的评论说明。


3、bug描述与定义
发现了BUG如何第一时间周知相应开发,如何清晰的表达清楚bug内容,如果简介的描述出bug复现的场景。
如何总结出导致bug的真实操作原因和背景。这些是一个测试人员能力高低的重要标准。
优秀的工程师对于非必现问题的定位高效,排除无效操作,去除掉障眼法,找出真正必现的使用流程,问题的本质,大大提高了bug的解决周期。
举个例子 初级工程师“点击下单报错”高级工程师“在选择多规格产品,有优惠的情况下,选择下单报错”

测试角度释疑:

测试人员发现缺陷通常会第一时间提交到缺陷库中,具体的分析处理是事后的事情。测试很多时候一天发现几十个的缺陷,不可能每一个都和开发人员沟通确认,通常只有在缺陷过于严重,无法继续测试的情况下,才会联系开发人员。

我通常不会去理会缺陷发生的原因和背景。因为我主要做的黑盒手工测试,产品对于我来说就是一个无法探知内部细节的黑匣子,我只能通过一些操作,感知发生的回馈,此回馈如果和测试用例的预期不符,那么就是缺陷。至于为什么发生,那应该是开发人员关心的事情。

测试人员更关心的是发生了这个缺陷,是否其他模块同样会发生,是否进行不同的操作会发生同样的缺陷,是否此缺陷会引发其他的缺陷发生等等。测试人员更关心如何通过发生的缺陷找到更多的问题,而不是去关心缺陷为什么发生和如何修复。

初级测试和高级测试,对于同一个问题的提交应该是一致的,这个是测试人员的基本能力。不要认为一个问题不同的测试工程师会有不同的提交,缺陷本质都应该一样,缺陷发生的模块,操作过程,严重性,截图等等。

我个人不建议测试人员对缺陷提出处理意见,比如打印有问题,测试人员应该提出的是无法打印,可以说打印控件无法加载。如果更进一步的提出使用A打印控件更好个人就认为有些过了,因为测试人员的关注点一定是缺陷本身,说多错多,只能给开发人员留下测试人员开发能力不行的借口。


4、BUG生命周期跟踪与推进
对每一个BUG的产生、经过、结果都有良好的沟通,并了解问题的真正原因,记录归纳并协助其他团队总结分析。

测试角度释疑:

测试有操作不明白的地方可以询问开发人员,开发人员对于发现的缺陷有不明白的地方可以问测试人员。了解问题的真正原因个人认为应该是开发人员而不是测试人员的责任,因为通常测试人员并不会负责处理缺陷,所以真实原因只有开发人员知道。通常一次系统测试过程,会发现百级甚至千级数量的缺陷,分析过程实际是一个很大的工作量。


5、需求审核
作为整个研发中心的一员,在需求评审阶段给出合理性建议,提出需求遗漏的问题或者逻辑错误或者质量风险,都是一名高级工程师必备的能力。也是有效降低后期真实bug数目。
6、测试报告
定期整理需求测试报告,分类、总结,风险预估。有效的保障整个需求能够持续,安全顺利的进行是高级工程师重要的考核方向,给开发团队和产品团队做kpi数据支撑以及需求总结。
7、工作效率管理
如何有设立自己工作的时间计划、优先级安排,以及排期后准时达成,时间预期排期的准确性等情况。

测试角度释疑:

至少在我的经验里面,需求大部分并不能提供太有效的信息,顶多知道有什么功能,大概内容是什么。我主要做系统测试,系统测试的参考就是需求规格说明书,但实际对我来说,绝大部分项目需求并不能给测试人员一个很好的参考,需求评审只能发现一些比如性能指标不合理啊,功能说明在各个地方不一致,数据库设计有问题等等,对于最后的测试过程并不能起到决定性的作用。当然了,可能其他的公司会有需求写的很好的,可以对测试人员的测试过程起到很大的指导作用。


总结:
上文有些东西是不好量化的,但是不能因为不好量化,就去量化没有意义的量化,用bug数目考核。
上文只是从有没有好处的角度分析bug数目。并没有说统计坏处,这个大家可能都有经验。不提也罢。
反是保障测试中发现的bug尽可能接近 真实bug的有效手段和方式 ,是值得考核和提升的。
最后:
经过这个事,详细的思考总结了下测试工作内容及绩效管理,对自己是一个记录和成长,也希望对大家有帮助,引起讨论,更希望大家给些意见。

测试角度释疑:

测试的KPI是很多测试人一直的考虑的问题。测试出数据的地方通常只有测试用例和缺陷,所以从度量角度只能从这两者考虑,里面还划分很多的属性,比如严重性等,不是测试人员通常没有必要了解这些内容。

在测试的角度,从来不存在真实bug。我想也不会有哪个公司用真实BUG去考核测试人员。


其他的就不多说什么了。

其实写这么多,主要是太多的开发人员对于测试人员的工作不理解,此文就是,所以希望看到此文的无论开发人员还是测试人员还是其他过客,能了解测试人员多一些就多一些吧。

另外,很多的回复内容仅以自己的工作经验为准,个人并不保证全部正确,每个人对于同一个事件有自己的角度和看法是很正常的,工作不同,具体工作内容不同,对事物的看法不同也很应当,本人只是说明了自己的工作实践和自己对于测试工作的一些思考。

就是这样。

over。


TAG:

ghost51的个人空间 引用 删除 ghost51   /   2018-05-28 12:42:48
大牛哇
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2018-11-20  
    123
45678910
11121314151617
18192021222324
252627282930 

数据统计

  • 访问量: 30031
  • 日志数: 39
  • 图片数: 1
  • 文件数: 2
  • 建立时间: 2006-11-24
  • 更新时间: 2018-06-09

RSS订阅

Open Toolbar