再次,需要一点胆大精神,不害怕会破坏什么东西,不管你有多位高权重,他们也不害怕把发现的事实告诉你,他们更不害怕站出来据理力争,一定要把他们相信可能影响到产品成功的问题解决掉。club.mypm.net
善于分析,善于学习,事实上,测试人员一直在学习,他们的工作性质要求如此。技术总是在变化,接到的每个项目或多或少跟上一个项目不一样。有时候有很好的文档,有时候却没有,必须问出正确的问题,研究正确的问题,把谜题的各个碎片联系在一起,然后得出正确的结论。PgMp.mypm.net
当然,测试人员也有不好的特质,尤其对于那些经验丰富的人为说,不容易信任人,这是从实践中历练出来的,别人总是告诉他们模块X不需要测试,或代码Y“没动过”,这种信息错的数多到数不清了。所以,就算你告诉测试人员草是绿的他们也要亲自过目才敢相信。当然了,不是所有的测试人员都具备这些特质。好吧!也许你做测试是为了一份稳定的工作来生活。也许你不是“真正的”测试员。bbs.mypm.net
寻找测试的乐趣项目管理者联盟
只懂执行其他人测试想法的人,不能算是一个真正意义上的测试人员。当一个测试人员运行一大堆已有的测试用例时,容易心生厌烦。可能会快运行这些测试,只是想让他们从眼前消失,这意味者他们可能不会非常关注执行的测试,当然也就不能像认真彻底的执行者一样找出某些问题。pmp.mypm.net
很多测试人员觉得单调乏味而不屑运行回归测试,虽然大部分测试员都理解甚至同意回归测试的必要性。项目管理论坛
一个“真正的”测试人员一定会把这些已有测试看作自己的职责范围,重新考虑其中的想法,提出问题,充实和改变测试,探究原来的分析没有考虑到的地方。如果原来的分析实在很棒,寻阿能他们也找不出来太多可有更新充实的内容,进而增加了无聊指数。service.mypm.net
并非发现的所有问题都可以得到解决项目管理者联盟
虽然,看到这个结果会打击测试人员的积极性,但这是真的。最有经验的的测试人员会同情地拍拍你的肩膀说:地球人都知道事情不仅仅是发现问题那么简单。他们也会充分理解、会力支持你的决定:问题A、B、C 可以不解决,并不会有人对这样的决定怪罪你。拥有多年工作经验的测试人员会说出大家都愉悦的意见,因为他们从这家公司的项目经验中学乖了,知道这样会给他们(以及他们部门)带来最好的质量结果。但是需要记住,他们之所以肯牺牲问题A、B、C ,很可能是为了说服你解决更严重的问题D 和E 。当然,大多数测试员是希望发现的所有问题都能够得到处理,现实总没希望的那么好。项目管理者联盟文章
测试员只喜欢有趣的缺陷转自项目管理者联盟
所有的测试人员都会告诉你,缺陷是存在的,然后缺陷就真的存在了。一般来说,让事情变得好玩并非缺陷的数目。比如一个测试人员可以在大的网站应用程序中发现上千个表面错误,就是语句与错别字,给用户看的文本有语法错误,图标上的颜色不对,或都屏幕上有东西位置放得不对。www.mypm.net
测试人员非常讨厌这样的错误,特别是发现有很多的时候。因为记录这类错误比发现它们所花费的时间更长。而且他们一般属于低优先级,很容易得到解决。对!测试人员就是变态的喜欢让开发员束手无策的问题,这样似乎更能体验他们的能力与价值。项目管理者联盟
不要去预测问题优先级项目管理者联盟文章
在IT领域经验丰富的前辈会告诉你,某个应用程序的最终用户可能会对你觉得微不足道的问题深切关注。这跟人的“烦恼因素”有很大关系,一个错别字或字体用得不恰当可能不会影响用户的使用,项目组的所有人都认为这是个小问题。但是对于每天要看两千遍的用户来说,“烦恼因素”是非常高的。项目管理者联盟
例一个双击鼠标就可以完成的操作,我设计成了三击,只是多点了一个鼠标而已。这也许有趣,但对于每天操作几百遍的用户来说,他会破口大骂地拿起鼠标甩到地上。这太令人讨厌了。这影响的他们的工作效率,也行效率与绩效、奖金挂钩。项目管理者联盟
测试人员报告他们发现的一切问题,其中经验丰富的人员会根据其理解来报告严重程度,但一般来说不要试图预测业务优先级。他们理解中的业务优先级通常就像开发团理解的一样,是不太完整的,并不是基于用户的个人体验做出的。经常有用户愿意“将就”使用有严重错误的代码,却在最后一刻强迫要求修改或添加看起来并不重要的东西。training.mypm.net
测试人员的工作是寻找、发现、报告,而不是用神一样的能力去评判,测试人员应该随心所欲的提供他们的专业意见,事实上,项目组的所有人都应该随心所欲地提供专业意见。项目管理者联盟
报告你发现的所有问题项目管理培训
有一个令人遗憾的现实,那就是测试人员不将他们发现的所有错误报告出来。原因可能有很多,但最常见的是他们觉得报告某一种或某一类错误没有意义,因为反正都不会被解决的。这是从实践中“学”来的,你通常会发现有这类态度的测试人员不抱幻想、厌倦、愤世嫉俗、对工作不感兴趣。他们报告缺陷的兴趣和热情已经被工作环境慢慢消磨掉了。另一个原因也许是他们相信从政治上和实际上来说,报告他们发现的一切东西是不“聪明”的,他们应该只报告那些公司在乎的东西。那么,如果公司看不到整个大局,怎么知道在不在乎呢?每个人都明白很多错误是不能(或者从财务的角度来说不应该)在产品发布前解决的。成功项目管理的“艺术和工艺”的一个要素是对推迟和解决哪些缺陷做出正确的决策。比如,项目组决定解决1 4 个缺陷,推迟另外3 2 个。但是测试人员选择不报告3 2 4 个缺陷,因为开发团队“从不解决”字段错误,这意味着项目经理和上层的管理者正在根据错误、不全面的信息作决策。在这个例子里,用户界面就不能在万众瞩目的黄金时段隆重登场。项目管理者联盟
另外,就算是在一个并不解决某类错误的公司,报告每个错误也可能会最终改变公司的政策(或称之为“一直实行的陈规”)。如果一个测试人员报告了4 0 个错误,一个都没解决,应用程序就发布了,然后用户以紧急的优先级报告同样的错误并要求尽快地解决它们,那么开发团队和项目经理以后就会开始注意这类缺陷项目管理者联盟
测试员一直在想法破坏你的程序项目管理者联盟
好的测试人员同时是富有创造力和想象力的。测试通常是一个破坏的过程,正因为如此,在正式产品环境下运行测试需要非常谨慎的决策。好的测试人员不必试图证明软件运行正常,他们是来证明软件不能正常运行的。这一态度差异是测试人员能发现如此多缺陷的主要原因,他们就是想发现缺陷。他们分析手上所有的信息,坐下来思考怎么才能破坏应用程序。项目组里没有其他人有这样的使命。开发人员一般甚至没有足够的时间持续写代码,更不要说试图挤出足够的时间来想怎么破坏代码了。最终用户通常只是执行日常工作的操作,如果有东西“坏掉了”,他们可能陷入恐慌和沮丧之中。另一方面,只有测试人员勇敢地参与进来,使出吃奶的劲儿去发现软件中的缺陷,他们却为发现另开发人员痛苦的缺陷而兴奋不已。项目管理者联盟文章
这正好应验了妈妈一直告诉我们的话,要是你只盯人身上坏的一面,那你就只能发现坏的东西。测试人员全面地盯着系统中出错的一面找问题,顺便也就检验了运行正常的部分。但他们关注的焦点总是向着错的东西,而不是对的东西training.mypm.net
测试角色的本质bbs.mypm.net
很久之前,就有关于测试人员的角色的争论,我们再来总结性的说说测试角色的本质。talent.mypm.net
|