转虫师:测试人员定位

不要为了测试而测试

  前几天做了一个测试的PPT ,就是讲项目中要用到的测试技术,总结了半天其实实际的产品中没什么技术,熟悉需求,转化成用例,待项目上线后验证功能就OK 了;对一个自身质量要求不高的项目,我们有时候为了体现自己价值,非要在一些不痛不养的问题上揪着不放。

  举个不恰当例子,某钢琴高手开了一个补习班教钢琴,家长送来一孩子目的只是让孩子学学钢琴;钢琴高手为了体验自己的价值(牛B),硬是按照贝多芬的标准去培养,孩子弹不会《XX交响曲》不让孩子走。先不说孩子有没有贝多芬的钢琴天资,也许孩子压根就不想成为贝多芬。

当然了,如果你办的是“中国音乐家钢琴协会”,你有责任要求会员达到国际超一流水平,为国家和个人赢得荣誉。

  有时候不要为了测试去测试,或为了体现自己的价值去做一些对整个项目贡献不大的事儿。当然,我在这里不是让测试人员放弃自己的原则。要知道不管是产品、开发、测试都是围绕着产品的发展贡献。

  为贡献产品的发展测试远比为了测试了测试所带来的价值大得多;所以站在产品的发展上去看待测试工作更能体现自己的价值。

记得去年的总结再讨论自己对流程的理解。随着工作年龄的加长对这些问题也有进一步的看法;所以,再拿来炒一炒,希望能炒出新的味道。

没有最好的开发测试流程,只有最适合项目的开发测试的流程;

  去年的一篇说软件测试流程,严格规范的测试流程一定比没流程好,敏捷的流程一定比传统的瀑布流程先进。这个观点没有大的错误,但是我们忽略了所做有产品这个“对象”;忽略了产品的特点与阶段。

  例如两三个开发合伙开发一个项目(或产品),这时你让他们建立一套规范的流程,按流程实施,显然是不现实,我想摆在他们面前最主要的问题是,如何快速的把客户需要的功能开发出来换成money ,维持生计以及公司运作。

  例如一个各种功能已经成熟的项目,有着庞大的用户群,以维护为主的更新,它的版本功能的上线必须要建立严格的发布流程,经过充分的测试才能上线;用户群越大,暴露的问题越多,问题带来的影响也会越大。

  同样是一个web产品,笔者目前所做的项目流程完全不是这样;我们的发布流程很简单,测试流程也很简单,不去写的规范又复杂的测试用例,放弃了使用缺陷管理工具来反馈问题;

  沟通变得尤为重要;我不否认这样做会给产品带来了一定的风险;对于严重的问题,我们可以通过快速的版本回滚,对于轻微的问题,我们很快会在下个版本迭代中修复。是不是有点敏捷的味道在里面。

  为什么会这样?因为这个产品属于前期开发阶段,很多功能还没上线。整个团队都在贡献着产品的发展;需要快速的将需求转化成功能给用户使用。

所以,没有最好的开发测试流程,只有最适合项目与阶段的开发测试的流程;

产品质量与用户容忍度

  之前看过不少人讨论到底需不需要测试人员;我想说测试人员N年后不管是被重视了还是被淘汰了“测试的行为”永远不会消失;因为没有质量的产品基本上等于没有价值(也就是说没存在的意义),至于对产品质量的要求是由用户容忍度决定的。

  Facebook 没有测试人员!但是测试行为一直都在。开发找需求,开发、自测、发布,获得用户反馈,决定功能下线还是上新的功能---相当于一条龙的服务。因为用户的容忍度允许他这么做。

  微软不能这么干,修复一个windows 的bug成本很高,而且用户是花钱买的,也许用户是用来创造价值的(办室、存储、管理),也许一个文件丢失,系统崩溃会给用户带来巨大损失;所以,微软需要很多的测试员。

  拿修复成本与用户容忍度做标准,web产品优于客户端产品;在web产品中也要分行业;用户对银行系统、火车票、购物网站的容忍度显然要低一些,反过来说也就是对产品的质量要求更高,因为与钱挂钩。就算同一个产品,会员与免费用户的容忍度也是不一样的;因为会员用户有权得到更好质量与服务。

所以,关注分析用户的容忍度的测试才不会把自己变得格格不入。

提升自己的贡献

  前面的东西貌似都在“弱化”测试存在的价值;俺本来就不被重视,所以俺就需要更加认真和努力找问题来提升自己存在的价值,你现在说,有些产品不需要太指着的去测试;那你说俺还能干啥?

  当我们把测试看成是为开发和产品服务时,也许情况会完全不一样。我们可以提供哪些服务?

  • 用测试发现产品的不可以测试性

  前面已经提到队团不管是否有测试人员,但测试行为一定会存在;如果一个产品都不可测试,如何去发现并修复bug ,如何去维护与扩展?尤其对于web产品来讲,不可维护与扩展的产品无疑是致命的。(可以通过项目重构再解决)

  • 建立产品质量的评估方法

  为项目团队提供每个版本的bug趋势分析数据,让项目中的每个人都了解项目当前的状态

  通过分析bug数据来建立或完善各种Checklist,帮助项目团队更好的完成需求评审、设计评审以及代码评审,减少bug出现的机会。同时,可以定期将多个项目的Checklist进行合并,使单个项目的经验可以通过Test Team快速的流动起来,及时的作用于其他项目

  主动为Architect Team提供每个项目的性能测试数据,帮助他们获取更多的实际项目信息,减少踏入“陷阱”的几率

建立可持续运行的测试框架

建立自动化测试测试框架;

构建持续集成,使版本的迭代与更新得到快速的反馈。

建立关注开发质量的开发文化

没有测试人员自测节省人力的了,尤其在单元测试层面。产品的质量应该由开发与测试共同承担。(现实中的责任到人,让团队很难形成这种文化)

贡献产品发展

  旧病成医,测试的产品多了自然会对产品有自己的理解,产品的定位,用户习惯与体验; 可以从测试的角度贡献产品的发展。(这个由产品的特点,公司文化决定)

时间: 2024-11-07 19:31:54

转虫师:测试人员定位的相关文章

测试人员在团队中的定位

前言 接触了许多非测试和新入行的测试从业者,听到最多的问题就是:“测试是否被需要?“ 团队职能介绍 <暗黑者1>中有句台词,“专案组有五个职能角色构成,侦探.网警.痕迹侦查专家.法医还有心理学专家”. 软件项目开发也是个分工明确的系统工程,不同的人员扮演了不同的角色,可以分为:项目.产品.开发.测试.美工等等. 项目经理负责分配资源,确定优先级,协调与客户和用户之间的交往. 产品经理负责市场调查并根据产品.市场及用户等的需求,确定产品功能的定义.规划和设计. 开发包括开发经理.前端开发.后端开

测试人员掌握代码的重要性

在测试中心做了一年的测试,从一个对业务不熟悉的小白到能独立掌握一个两个或者更多业务:从一个连ORACLE都没有接触过,连LINUX都不知道是什么东西小白到能在平时测试时稍微写写存储过程,写写shell脚本提高测试效率.点点滴滴的成长都使得自己在测试的发展上继续保持兴趣.想想当初点开界面左点点,右点点,程序偶尔出现BUG,自己便会兴奋地记录QC,截图加日志给开发排查,当时想想可能还是蛮有成就感的,毕竟程序在自己的手中得到了提升. 我相信大家都是慢慢成长过来的.但时间久了,就比如说一年这个时间点,我

关于全功能团队及测试人员的发展

这两天部门内部在讨论全功能团队的相关东西,希望后续能慢慢的实施起来.这里全功能团队的概念,简单来说就是希望能够减少团队的规模,加快产品交付的节奏,类似于敏捷开发模式中的小步快跑,能够频繁的有版本上线运行.总体方向来说是好的,这套东西很多互联网公司也玩的很顺畅,但是在华为,最起码在我所在的部门内,还非常缺乏这方面的积累和氛围.整个研发的运作模式和管理层都是从传统的运营商转型过来的,团队庞大,低效,笨重...等等一系列的缺点. 关于这种团队模式的优缺点,如何根据自身的项目实际来运作,以及在这种模式下

测试人员内功心法

转眼间2017已过了十天,中国传统的新年也马上来临.目前大家的状态应该是人在曹营心在汉,早想着回家过年的事情了吧?抢票,参加年会,中奖的高兴请客,没有中奖的替同事高兴,反正是不亦乐乎!由于最近一段时间比较忙,也没有写太多的东西出来分享给大家.不过在这新年即将到来之际,还是感觉应该写点儿东西的. 往期我分享的博文一般以技术偏多,要么就是一些儿个人心得,具有指导性的文章:不过这些都是比较具体的套路,就像武学上的刀法,剑法,棍法什么的,其实最重要的心法,我一直没有涉及过.原因是什么呢?中国人每个人都有

测试人员的核心能力与素质

声明:该文不是我的原创作品,是我的同事魏增艺的大作,独家授权我来进行发表. 在<测试人员的角色>一文的最后,我们相信优秀的测试人员是项目的前灯,是整个研发系统的反馈回路.那么什么是优秀的测试人员呢?具体说来,具备哪些核心能力与素质的测试人员才能胜任这样的角色呢? 对于能力模型,例如常见的"冰山"模型."洋葱圈"模型等,都将一个人行事的内在动机或价值观等置于核心位置.同样,对于一个测试人员,我们并非看他在进行什么活动,而是要关注他为什么要进行这些活动.本文

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

测试人员和开发人员如何更高效的配合工作

一.对开发人员的建议: 控制版本/补丁发布频率(重要) a) 版本交付间隔保证在2个工作日以上,尽量避免出现版本/补丁频繁交付导致的测试不充分. b) 控制版本补丁数量,原则上除紧急补丁外,多个补丁合并发送.这样可以让测试人员对交付版本提供一个更准确的质量状况. 版本能按计划交付(重要) a) 根据青铜器上填写的版本交付计划或者约定的交付日期进行版本交付. 明确每个版本的送测内容(重要) a) 含故障单.缺陷编号.具体功能修改等,避免出现模糊描述:如修改了用户管理模块--应描述修改的具体内容.

测试人员职业规划

公众号里发文章,超链接只能链接到发布过的文章,所以这几天我会把以前写的但没群发过的文章重新发一下便于页面跳转,各位看官请知悉. 关于测试人员的职业规划,我想无论是刚入行的新手,从业几年的测试工程师,还是大牛们,都需要面对并慎重的考虑.做测试有前途吗?做到什么程度才算好的测试?如何才能成为大牛(怎么把工作做的卓越)?......从目前测试行业的人员结构来说,新人占了绝大多数,所以远方有一盏明灯就会显得更加重要.在这个问题上,我考虑过很多,也做过很多尝试,之前也把自己的一些经历和心得发到到自己的博客

15问答为专业测试人员揭开“精准测试”的面纱

 15问答为专业测试人员揭开"精准测试"的面纱 什么是精准测试?软件测试是否必要达到精准?精准的同时是否提高了测试成本?精准测试对于普通测试工程师乃至测试行业会有怎样的影响?让我们带着这一系列的问题来关注精准测试的15个问答,揭开精准测试的面纱. 1.到底什么是精准测试?它和传统测试的区别和联系 相对于普通测试,精准测试是在传统测试过程中,通过技术手段对被测程序进行360度全景测试,将测试过程可视化.数字化.标准化,从而达到被测程序上线稳定.无风险.维护成本低等优势. 和传统测试比起来