测试管理 突破测试的墨菲定律 -- 有感于一次 UAT 组织

rodman1985 · 发布于 2017年11月13日 · 最后由 rodman1985 回复于 2017年12月05日 · 3341 次阅读
本帖已被设为精华帖!

前言

作为一个测试人员,如果只是将自己的责任定位在产品交付测试之后,用户使用之前,那简直就是一个灾难。如果这么思考,那你作为测试的职业规划、个人能力成长等都注定陷在一层阴影里,被项目组其他成员牵着走。

之前也有在写的文章里提到过 -- 测试人员是一定要建立主动防御体系的,这不是一个技术问题,而是几个基于技术和流程管控的工程意识。测试人员一定要能做到对风险有预知能力,有预先防范的能力,不然处在整个项目流程的最后一环,将永远摆脱不了被左右的局面。不要管业内喊什么测试左移、测试前置巴拉巴拉一堆,其实精髓就是作为测试请你尝试管理将要出现的问题和风险。

不就是UAT么,咱们怕什么

最近团队接了一个原本不该属于测试团队的任务UAT组织,注意是UAT组织不是UAT支持。关于UAT,我先强行科普一轮。

UAT(用户验收测试),英文User Acceptance Test的简写,也就是用户验收测试,或用户可接受测试,系统开发生命周期方法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

进行UAT的产品理论上来说,必须已经全部开发、测试完毕,代码状态处于冻结状态, 所有测试出来的bug都已经被妥善处理,重大的bug都被解决,并验证通过。 对于一些低级别 bug ,要么决定被写入发布公告中,要么被设置为不需要修改的问题。 在实际项目操作过程中,由于计划进度原因达不到理论状态前提,故此,UAT的效果也达不到应有的效果。

按照经验,通常UAT的组织是由项目经理和产品经理做组织的,至少我在大平安之前的几家公司是这么组织的。项目经理和产品更容易从项目进展和产品交付的角度做好把控,过程中可以请项目专家,测试经理,或专门的测试,开发等顾问对测试步骤进行补充。

UAT实施流程图

当然了当前现实中,抛给了测试团队几个难题:

  • 做验收的客户(合作方,还严格不能算用户)多数不懂如何做验收,也不愿意为验收做太多准备。
  • 产品交付根本就没有达到交付质量,项目还带着一大坨bug就要被强行提交交付。
  • 产品经理、项目经理都不乐意做UAT组织,甚至不惜认怂说自己做不了。

作为团队的测试总监,确实我开始是不想接手这件事儿的,因为在我看来确实不合常理。不管是出于行业惯例、还是人员能力等方面,我都觉得将这个事情布置给测试团队是不合理的。不过我最终还是考虑之后接手了这个事情,我的出发点是总成本:几个难题里面第一个对我们的影响最大,对方不懂如何做测试(对方甚至根本就不是有业务背景的业务or测试人员),我们每次都需要花大量的时间给不同的合作方做测试标准的讲解,做测试范围的沟通,做UAT计划的review,甚至是我们驻场给对方做UAT执行(是的你没听过,这典型的就是我是一个球员的同时还得比我去当裁判,我在禁区绊倒别人,裁判还得过来说你是不是把哨子吹一下,看算不算假摔算不算点球)。然后由于过程中项目经理又各种卡时间,导致我们支持UAT总是很吃力。所以算一下总成本,既然主要的工作目前都是我们在抗,项目经理和产品经理又做不好把控(这种做不好把控客观上讲是他们并不知道测试实施的难点在哪里,自然也无法站在测试的立场上看问题),那这件事从设计到规划到实施到进展控制都我们来做,反倒可以通过降低沟通成本而让我们的总投入下降。另外除此之外,作为测试成员尝试接入全程,提前规避验收测试风险对团队和单兵能力提升都有很大的帮助。

撇开纠结『是否行业里UAT应该己方测试人员来做组织的传统和惯例』-- 这个问题,对提升测试的全流程把控能力,个人认为还是有很大帮助的。所以,如果先不纠结责任归属,不就是组织个UAT么,有什么好怕的,撸起袖子干。

墨菲定律带来的UAT危机

再来科普一轮什么是墨菲定律,“墨菲定律”是一种心理学效应,是由爱德华·墨菲](Edward A. Murphy)提出的。
主要内容:

  • 一、任何事都没有表面看起来那么简单;
  • 二、所有的事都会比你预计的时间长;
  • 三、会出错的事总会出错;
  • 四、如果你担心某种情况发生,那么它就更有可能发生。

在一次记者招待会上,斯塔普将其称为“墨菲法则”,并以极为简洁的方式作了重新表述:凡事可能出岔子,就一定会出岔子。

墨菲法则在技术界不胫而走,因为它道出了一个铁的事实:技术风险能够由可能性变为突发性的事实。 几个月后这一“墨菲定理”被广泛引用在与航天机械相关的领域。经过多年,这一“定理”逐渐进入习语范畴,其内涵被赋予无穷的创意,出现了众多的变体,其中最著名的一条也被称为Finagle's Law(菲纳格定律),具体内容为:If anything can go wrong,it will.(会出错的,终将会出错。)这一定律被认为是对“墨菲定理”最好的模仿和阐述。

墨菲定律主要内容是:事情如果有变坏的可能,不管这种可能性有多小,它总会发生。

“墨菲定律”、“帕金森定理”和“彼德原理”并称为二十世纪西方文化三大发现。除了墨菲定律,其他两个也很有意思,有兴趣的可以自己百度下,对你也许也有启发。另外再说下,墨菲这个人是一个军人,是一个工程师,不是专门的心理学家,更不是什么敏捷教练。顺便这么一说,是想和各位工程师共勉下,项目怎么做,项目有什么规律,是你作为工程师最有发言权的,不一定是你的老板或者那些高价请来的敏捷教练。

工程中无处不在的墨菲定律

If anything can go wrong,it will.(会出错的,终将会出错。) 这句话真实又刺耳的摆在我们面前,那这句话是否真的诚如字面疑似,你觉得会发生的不好的问题都一定会发生?

我先说说我的理解,还有一个心理学效应叫罗森塔尔效应。大概意思是说,暗示在本质上,是人的情感和观念,会不同程度地受到别人下意识的影响。人们会不自觉地接受自己喜欢、钦佩、信任和崇拜的人的影响和暗示。而这种暗示,正是让你梦想成真的基石之一。反过来,如果你一直心里暗示自己这个会出问题,那很大概率,这个问题终归会发生。这两个效应的总结有着异曲同工的部分,如果在项目实施中,你自信满满认为问题都可以克服,并为出现的困难做好客服的准备,那最终问题多数是会被解决的;如果你开始就暗示自己这个会有问题,基于心里暗示又忽略了对潜在风险的前置处理,那问题一定会发生。这不只是是在测试领域,任何领域不管理解成是墨菲定律还是罗森塔尔效应,都有一个潜在事实 -- 我们对自认为会发生的风险,缺乏提前预估和处理的动力,我们想当然的基于历史经验认为问题既然一定会发生,我又何必在自认为不可逆的事情前面螳臂挡车。而这正是我们的问题所在。

那我们这次组织UAT都遇到了什么问题?下面是组织开会时,我听到的一些问题:

  • 和我们合作的行方,他们自己的测试人员能力很差
  • 他们连case都不会写
  • 他们都不了解业务是什么
  • 他们都无法做好验收测试的评估
  • 对测试数据他们都没有任何概念,想起来了就问我们要,也不考虑我们的时间
  • 行方环境总是掉链子,不停的出错
  • 总是莫名其妙的要求SIT和UAT并行

听完大家的吐槽,我先默默的划了一张图,如下:
项目实施流程草图

画完之后问了大家一个问题,『既然大家都知道UAT有很多问题,那我们开始从什么阶段防范UAT的问题的,或者说我们从那个阶段开始做组织,开始控场的』。我指了指立项阶段,没人举手;我指了指需求阶段,没人举手;我指了指开发阶段,还是没人举手。可以比较确认的多数人还是在SIT阶段而且是SIT的后半段才开始掌控UAT的实施 -- 当然这个时候不做也不行了,因为UAT就要开始了。

这里就可以看出这个比较大的问题了,基于经验大家都知道到UAT阶段会出很多问题,但是仍旧放弃在从立项到SIT之前对UAT阶段的风险做掌控,那问题到UAT阶段你担心的问题都一定会发生。这也就是这次UAT过程中的墨菲定律事件。自然而然,这也可以理解为,是由一个墨菲定律带来的UAT测试危机。

当然这个问题是需要举一反三被扩展的,不局限于UAT的组织,我们在测试过程中的很多问题都是担心发生然后就必然发生了,比如担心提测延期 -- 比如需求大、架构不问题、人力不足会有延期风险,但是我们基本上不会在前期就做控制,那提测一定是延期的。所以,在我个人看来,更准确的表述是 -- 对你担心的事情,如果你不克服悲观情绪并提前做防范,那你担心的事情都一定会发生。

克服测试过程中的墨菲定律

诚如一些文章提到的观点 -- 墨菲定律只是将生常生活中的一些现象进行归纳的心理学方面的总结。出发点是人,所以能够解决的也是人!人通过调整自己的思想,看清事情的发展方向,便不会受自己心情的影响是终导致事情不可控。所以要先给自己定格调,测试过程中任何担心会发生的问题,都可以通过预判和防范而得以解决。

  • 理论一:任何事都没有表面看起来那么简单。

当然,任何事情总有它的前因后果,最后呈现在你眼前的只是结果的表像,甚至未到结果,只是过程中的一步。简单来说,就是不要让事情发展出乎你的意料,手足无措。对应的方法很间简单:遇到事情先了解它发生的原因,预料它发展的方向,做好当它向不利自己的方面发展时的应对。

同样是以UAT为例,旗下其实总结分析会有非常多的问题,归类一下有:合作方的需求同步;合作方的环境不稳定;测试数据准备不充分不完成;交付版本控制混乱;缺乏UAT执行的计划,合作方执行几乎乱来;合作方的人不认真撰写用例或者不会撰写用例。

有了上面的归纳总结,你就离看清看似简单的事物不远了,最起码基于对历史问题的归类总结,我们有能力做总结和分析,对之后发生的类似的问题不会手足无措。

多总结多思考多反省

很多事情,我们第一次去做的时候,我们要容忍自己对未知事物的认知问题导致的潜在风险,这个不可怕。事后一定多总结,多分析。让那些曾经看似简单的事物,因为总结发现的问题,而逐渐抽丝剥茧将完整的真像摆在我们面前。另外经验某种意义上也是相同的,作为一个测试,我们测试一个新业务、新项目也并非都是0准备去拥抱新事物,就比如做测试的分析,怎么分析用户,是否需要做各类型测试,这个是可以从其他经验借鉴的,但是有些内容比如之前一直测试非金融产品,突然测试金融产品发现安全测试成了你一个完全新接触的内容,那这类型的你可能要抱着纯粹学习的心态开始第一次。而在第一次接触之后,通过项目测试总结,问题总结,用户反馈和市场反应做总结,复杂的测试任务也会逐渐清晰,再下次也就不用担心了。

在这里需要强调下,很多做测试的同学,都不喜欢做总结,一方面是懒,一方面是没意识通过总结帮助自己做提升。如果想越来越能对项目有影响力,一定要克服懒惰培养能动意识。

  • 理论二:所有的事都会比你预计的时间长。 简单来说,就是你计划的时间永远不够用!其实这个就如人的欲望,永远没终点。当你在做一个项目or工作or事情时,你原设定完成的标准,当你实现了这个标准,你又会发现另一个标准貌似更合理,更准确,在这无休止的自我调整中,时间永远不够。但不用怕,标准你照旧设,但心态要调整:1. 任何事情都需要分阶段,每个阶段一个目标,到达到不需调整,完成即可直奔下一目标。这样总会取得阶段胜利而不会让墨菲定律消磨意志。2. 心理上明确预计好事情的时间会长,但总有解决的一日。所以胜利总归属于自己!

作为测试,时间上有如下几方面的未知性,首先测试的难度超过了自己的预期,研发的修复能力低于预期或者许诺,赶商务活动工期整体压缩。

先说第一个问题,测试还是要讲测试经济学的,所以不可能做无穷尽的测试,在测试遇到意外需要增加工时时,首先要在源头上思考下,如何规避可能出现的意外。在整体执行过程中,是不是优先完成必须的内容,非必须的是否可以降低优先级,并在可承受的范围内适度裁剪。至于突发的测试内容(比如集成的第三方组件做了更新,突然发现需要增加适配测试工作),也是一样的思路先评估风险,看这件事重要不重要,如果重要那是否有操作范围让一些原本耗时但是风险较小的测试让步(比如APP前端版本修改不大,考虑直接用monkey随机测试代替人工回归做兼容性测试)。

  • 理论三:会出错的事总会出错。 这个其实是心理暗示,就是让人潜意识认为事情不会太顺利,总会有那么一些事情发生而影响结果。当然,世事难料。所以在这个基础上,首先我们坚定自己意志,不怕出错!先将心理建设好,下一步,不怕出错的前提是:什么我们都已预见,然后想方设法避免出错,接着就是提早计划好出错了的对应措施。

所有的事情,包括测试在发生前都是有信号的。还以UAT为例,说我们担心对方的测试执行会有问题,那我们是否可以在sit前和对方沟通,让对方告诉我们他们的产品理解和测试理念。部分合作方在UAT开始前连人员名单都给不出来,那显然是一个UAT执行会出问题的大信号。如果说一开始我们做对接就发现对方没有测试执行人员,技术负责人也说不清,意识到有测试风险,还不做一些控制,那真的会出错的事情总会错。

所有的风险发生前都有信号

如上图,我们一个测试项目从开始到结束是经历一连串测试事件的集合,这个过程往往环环相扣。但是在风险发生的之前,或者说和前一个事件阶段并行阶段就一定有信号放出来,放出来的时候,请不要自己这是报个风险 -- 你要知道只报风险是解决不了问题的,而我们的目的是解决问题。那此时基于历史经验,你要在风险信号曝出的时候就启动一些应急方案(如蓝色部分),让你的事件流重新回到合适的轨道上。记住这个逻辑,不是到一个关节点把你担心的事件都看一遍,这样太累,而是有一个完整的应急方案集合,在某些信号抛出的时候,触发你的应急方案。

  • 理论四:如果你担心某种情况发生,那么它就更有可能发生。 这个更简单,不就是自己都潜意识认为某种情况很重要影响很大,所以会担心。所以这个理论就是让人将自己内心害怕的东西揪出来,直接面对,而不是因为怕了而逃避,通常越逃避越做得不好,坏事就一定会发生,所谓越怕鬼越见鬼!

做一个能动性的测试

之前也提过,先撇开技术能力,你是想做一个executer,还是一个tester,还是一个QA,还是一个QC。

如果你只是按照别人给你的计划,别人给你的方案做测试实施,那你永远都只是一个executer,等着被机器和AI取代的那种

如果你能对项目有自己的分析和见解,知道如何做测试分析测试规划,那你是一个tester,但你很容易达到职业生涯的天花板。

如果你对项目测试独立的见解,对质量有良好的意识,对质量工作展开有明确计划,那你是一个QA,但你可能还不足以影响一个领域。

作为测试,请热爱这个行业,所有墨菲定律、罗森塔尔效应都只是我们给自己开脱的接口,尝试做到对全流程质量的把控能力,这才是你应该做的。

共收到 36 条回复
981500

😀 难得看到一篇这么精彩的测试管理文章;说到底 测试要具有主人翁意识,把产品当作自己的宝宝

605 chenhengjie123 将本帖设为了精华贴 11月13日 23:48
110

赞,方法论落地之后,再回归方法论回顾与总结。很多东西感同生受。

5895
981500hu_qingen 回复

嗯 是的 看到有些测试同学,习惯当前现状,缺乏进取,确实有点难过。

5895
110Lihuazhang 回复

嗯嗯,有感于毛爷爷实践论。

9210

好久没有看到这种坐下来安安静静分析问题的文章了,题主看问题的角度也非常值得我们学习。
赞👍。

340457
5895rodman1985 回复

越测试,越迷茫,从管理角度上讲,很支持楼主观点,但现实工作中,好不好做,愿不愿意去做,很难讲,也许这就是有些人不想做管理的原因吧😁

5895
9210xuxtc 回复

谢谢你的鼓励,我一直把自己当成团队导师看,也只想安安静静的带好大家。

5895
340457Roc 回复

哈哈 普遍培养 重点选拔,热忱的疏导换不来反应也是常事。转管理后很多时候是挺心累的。

4060

写得真流畅 赞赞赞

340457
5895rodman1985 回复

😄 😄 做不了管理,打打辅助,助攻还是可以的,感恩为人遮风挡雨的leaders

5895
rodman1985 · #12 · 2017年11月14日 作者
340457Roc 回复

做了几年管理,还是怀念傻逼一样做测试开发的日子。

8ffeea

这么久以来终于有一篇比较好的文章来谈测试

5895
rodman1985 · #14 · 2017年11月14日 作者
8ffeeadengli_lhk 回复

谢谢认可😜

16280

楼主总结的很赞!
这个方法论在平安科技可以归结为能力模型里面管理类的识别风险、规避风险的体系
简单来说就是要有能力看得出哪里可能会发生问题,要拿一套方法/方法论出来实施,避免这些可能发生的问题真的发生

学会用项目管理的方法论解决每一件事,这是管理入门的一件必备技能,可惜我最近看过太多不懂PM的主管了

5895
rodman1985 · #16 · 2017年11月15日 作者
16280fudax 回复

可惜我最近看到好多不懂项目成员管理以及项目管理的PM(项目经理)了。

13231

😂 还没从管理的角度总结过,有项目需要做验收测试时候,只是会总结技术点,对技术点进行回顾和梳理;
学习了!

5895
13231Qian 回复

总结还是有很多方面可以看的,有技术改进的,有流程改进的,也有单兵能力提升以及团队协作的。想自己提升自己,还得长思己过。

13231
5895rodman1985 回复

赞👍

0a25e0

有收获~赞这种行云流水般的文章

5895
rodman1985 · #21 · 2017年11月16日 作者
0a25e0Burning9 回复

谢谢过奖了

96

这篇文章的境界很高
一直都在思考如何能成为有气质的测试,一开始想到的是写代码,学开发技术(虽然,这关也是要过的),但是测试的技术好像也就那样..(我每次看测试书籍,都觉得好像不高明,就是说说什么东西怎么用,甚至还买过一本书大半篇幅都贴的是代码...)
直到看到这篇文章 ---- 测试的精髓是对质量的把控啊,找Bug, 自动化呀性能呀,这些技术层面的测试只是一部分,并且要在质量目标下合理安排,而对风险的判断和处理这才是质量的根本,测试的灵魂啊

5895
rodman1985 · #23 · 2017年11月17日 作者
32joy 回复

嗯 是的,之前我也面了很多掉在唯技术的思维小巷里的同学。我问他你接下来有什么职业规划,他告诉我说继续走技术路线,我问他你为什么要走技术路线,怎么走技术路线,想解决什么样的问题,输出什么样的价值。不少同学能模模糊糊回答前两个问题就不知道了。我只能fail掉他们的同时,告诉他们,问题要反过来看,你想输出什么价值,有什么问题等着你解决,你打算有什么手段解决(技术手段也是一部分手段),最后才是你如何提升你解决问题手段的。
当然了,作为一种手段,你自然是多掌握几种好些,解决起问题来才容易游刃有余。

14929

关注这个社区好久,不过一直没怎么浏览过。。。今天从码农头条看到这篇文章,深有感触。。。
我们一直低头忙着做一些事,有时候忽略了做这件事的意义以及对自己带来的改变,初心啊初心。。。
之前也走进了一些技术小巷子,努力提升技术,以为可以解决一切问题(尴尬。。。),现在心态算是改变了。
其实个人觉得,无论做什么事情,一定要明白自己的价值诉求是什么,做什么事可以产生什么结果和效益,作者的文章,给了我很大触动,恰巧公司要做UAT,可以当做一个参考的思路,真心感谢作者大大(✿✿ヽ(°▽°)ノ✿)
至于思考和总结,我觉得不论工作还是生活,总是需要这么做的,明得失很重要!我个人也在坚持写博客,总结自己工作或学习中遇到的问题,知识点,即是总结思考,又是分享,因为我相信这么做是对的。。。
文章已经分享到部门群里,并艾特了项目经理😂 😂 😂
最后,谢谢作者大大。。。

14414

赞一个~文章很流畅~

目前的工作和pipeline相关,个人认为pipeline的核心价值之一就是全流程的质量控制,虽然并不全面,但是核心也是希望能够提前暴露风险,不让上一个环节的问题流入下一环节.这和缺陷修复成本理论(缺陷越晚发现修复成本越高)异曲同工.

5895
rodman1985 · #26 · 2017年11月22日 作者
14929imyalost 回复

哈,您过奖了。
之前在简书写了几篇,发现互动一般,后来还是发现testerhome是测试人员的家。
关于记录和总结,我个人还是觉得蛮有必要的,我坚持写了六年的工作日报。定期就反思一下自己当时做了什么事情,自己的时间去了那里,哪里有可以提升的空间也是一目了然。也会为自己曾经稚嫩的想法无语,同时又赶快自己在变化。
最开始的时候也盲目的觉得测试就是提bug,就是不漏测。后来发现效率低,又导向了测试工具和技术的小巷思维里面,想着如何提升技术能力。然后在工作五年左右的时候醒悟了,发现做测试无非保障两件事质量和效率。然后其他任何事情,比如技术、工具、流程都是保障质量和效率的手段。现在很多时候大家忙着提升手段深度,都忘记自己到底想解决什么问题了。
也许就像那句诗说的,我们都走得太远,以至于忘记了为何出发。

5895
rodman1985 · #27 · 2017年11月22日 作者
14414AngryTester 回复

谢谢
嗯 从转管理以来,一直强调团队对全流程的把控能力。
一方面确实作为测试,一直是流程的最后一环,做事太被动,我又是一个控场选手,这让我受不了
另一方面,想提升作为测试的能力,甚至是提升项目的实施能力,都必须从全流程下手,不然完全没机会。

9792

拜读文章,非常受教,作者看问题的高度和全局意识很值得学习~

看完正文和评论,深感自己要去反思以下几点:

  • 提前看到了上下游团队的问题以及问题所带来可预期的风险,但总是会以碍于面子不方便直接指出问题、也许风险不一定会产生的侥幸心理、以及事不关己高高挂起的懒惰等各种理由,来选择性的进行回避。到了风险真正发生时,又开始手忙脚乱,事后反思为什么没有提前备案,但下一次项目开始又会陷入到这样的循环中
  • 唯XX论的小巷思维,在一个阶段,总会陷入到技术/管理可以解决所有状况的误区里去,从而无法真正站到全局去思考当前最需要解决的问题是什么,最需要输出的价值在哪。一叶障目不见泰山,就是这种状态了
8ffeea

我觉得团队对于全流程的把控能力真的很重要
作为测试,主动性很重要

12450

总结的挺不错的,认真读完了。

5895
rodman1985 · #31 · 2017年12月01日 作者
9792flyinghema 回复

也确实在上下游沟通,想起电影《大卫戈尔的一生》,里面凯文史派西一直致力于废除死刑,并对一些证据法的判断逻辑提出了质疑。但是法官、司法体系都不接受。凯文史派西引用了这样一段话,当时对我很有感触——心理学家库伯勒·罗丝阐述过公众面对灾难带来死亡的五个发展心理学阶段分别是:否定,愤怒,讨价还价,抑郁,接受。

在和上下游沟通的时候,确实我们是出于好心好意去提出问题,但是对方也会经历这样的过程 -- 否定你的观点,发现无法否定的时候就开始表现的很愤怒,在知道这个问题可能引发更多人更高层关注的时候胡和你讨价还价,之后问题即便是解决了,两个团队也是在抑郁情绪中接受的。

当然了,举例这个不是说咱们要回避问题,或者说准备号自损八千的解决问题。而是要劈开一条新路 -- 从开始让对方看到,他们是需要这个帮助的。比如做自动化持续集成,我们先许诺了一件事儿,研发同学你们的app构建打包以及分发我们管了,可以节省你们的时间,但是我们之后更高的目的是做一些改造支持持续集成。问题就稍微好解决一点了。

唯XX论,有些时候这是被畸形的招聘需求和一知半解的中高层领导荼毒的。我不能说没做过测试就不能完全管理测试团队,但是复用其他领域的经验来指导测试,还是多数时候不靠谱。我们自己要做好这个准备,从问题出发最后还回到问题去,这中间的路只是我们的手段罢了。

5895
rodman1985 · #32 · 2017年12月01日 作者
8ffeeadengli_lhk 回复

嗯 以前给团队成员做过一次分享 -- 一个好的测试 应该构建项目质量的主动防御体系。被动防御体系就相当于马奇诺防线,如果对问题不能及时应对,看到德国人攻打阿登山,就只能对问题坐以待毙。

5895
rodman1985 · #33 · 2017年12月01日 作者
12450siwen 回复

谢谢 认真看完的筒子应该不多,哈哈

12450
5895rodman1985 回复

其实呢,我更觉得测试人员在产品理解、开发技术理解方面要有自己的观点和认知。
因为大多时候产品经理跟开发和测试人员说的需求是ABC,开发和测试认为产品只想要A,项目做到一半产品说我其实还要B和C,这个时候大家都埋怨你产品又改需求了,其实一开始他都表述出来了,只不过处于技术层面并没有意识到还要B和C的需求。
测试人员在产品理解、开发技术理解方面有了自己的观点和认知才能够做到"全流程质量把控"的第一步。

9792
5895rodman1985 回复

心理阶段的概括非常精辟,谢分享~

QA职能的一项天然要求就是发现项目问题、推动解决项目问题。推动上下游改进几乎是不可避免,过往自己也踩了不少坑,总结到现在的经验是:单方面的指正和推动是不够的,要想达到大家都满意开心的双赢局面,测试需要参与甚至主导改进,不断用更好的成效来促成更好的配合度。

而如果就扔一个锅过去,接着就眼巴巴的等着对方把锅背完,合作团队不痛快,QA内部也会产生负面的抱怨,觉得对方不重视自己,对双方都不好。

5895
rodman1985 · #36 · 2017年12月05日 作者
12450siwen 回复

测试人员在产品理解、开发技术理解方面有了自己的观点和认知才能够做到"全流程质量把控"的第一步。

你的这个观点我是非常认可的,好的测试人员是会做到从产品需求到技术实现的良好衔接的,这其中一环就是都产品设计隐含需求的挖掘。比如音乐播放器的播放中断响应,大多数的产品经理都没有想好不同类型的中断进来怎么办,但是测试是可以做好这个把我的,因为测试同学天然的思维里面就有场景中断、现场保护以及现场恢复的思维。自然而然就应该想到来了一个电话怎么办,挂了之后怎么办。

5895
rodman1985 · #37 · 2017年12月05日 作者
9792flyinghema 回复

哈哈,这个地方不同的大牛可能有不同的理解。有的人会认为只要是影响质量的问题QA都应该关注,只要是能提升对质量保障的事物,QA都应该考虑去做。不过也有大牛的观点是,如果问题的挖掘和推动都依赖于QA去做,QA最终在团队里职能都发生了变化,轮为了过程改进小组。

我个人的观点,两者之间还是需要把握一个平衡,质量的保障是全团队的事情,不同角色应该有不同角色的重点内容,就好比篮球场上中锋不应该只负责进攻,后卫可定也不是只负责防御,但是1-5号位又互相弥补,同样的,鼓励成员做一些全局的事情,培养在项目角色之间的锋卫摇摆人。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册