zoukankan      html  css  js  c++  java
  • 浅谈测试和产品

    浅谈测试和产品

     很多测试的朋友在工作一段时间(比如4~5年左右)之后,测试的技术方面已经积累了不少,常见的系统测试、自动化测试、性能测试、灰盒测试之类基本都玩遍了,是不是还想扩展一下视野?

      好,那在不同环境下,CMMI、敏捷研发体系、精益研发下,试试这些比较新一点的东西:敏捷精益、看板、持续交付、持续集成、实例化需求...再拓展一下,搞搞Hudson、svn、Jenkins、git,玩玩Jira、Testlink,、Selenium,如果有兴致还可以在搞下Openstack、ganglia、Nagios、Puppet......等等诸如此类,完了,你会发现你其实已经超越测试,做了一些配置管理、运营维护的活儿,当然还有时间的话,再花点时间,加强一下代码、数据库、Linux,做得更深入一点...

      好了,当你这些也经历过了,也逐渐练就一身神功,成了高级测试工程师,往往得负责一些测试架构、关键测试技术攻关、带领测试团队之类的事情。时间久了,也都习惯了,但是也可能也会迷茫。

      但是,你就一直这么走下去吗?我相信一定会有朋友也在思考,是不是以后永远就这样了?

      每天当你看看新浪微博、或者科技新闻,看看36Kr、创业家、虎嗅之类上面的咨询,国内大点的互联网公司BAT与360之类的战战和和,一会儿玩收购、一会儿玩布局,小点的新兴创业公司层出不穷,甚至稍不注意拿到vc,突然就屌丝逆袭了,当然身边也有不少朋友的创业公司死掉的现实发生。

      各种发展太快了,消息太多了。容易迷失自我,你在做什么?为什么要做这个?做这事情有什么价值?

      ......

      多想想,多思考一下子。

      我想,时间久了,或许你会转型。

      如果你一路这么走来:初级测试工程师-->-中级测试工程师->配置管理+运营维护-->高级测试工程师-->QA-->测试经理-->测试架构师。我想,到了这一步,你又会哪里走呢?技术路线?还是向管理路线?

      有人会说走向PM,其实在与业界朋友们交流之后,很多人看来,很多公司的项目经理往往就是吹水,挂了一个项目经理的职位,而不是技术出身,只懂得管理,催进度,那个鞭子在后面要和各位战斗在一线的程序员、测试员同学们,实在是丢了PM这个职位的脸。

      而与其由测试经理转到PM,还不如做点实事。

      或许,你会想到产品经理!

      产品经理,有人称之为PM。当然,看起来和项目经理的简称一样,但是其实产品经理是PO,定义产品,设计产品,决策产品方向的那个人。

      笔者简单回顾了一下走过的路,其实前段时间也就由测试转到了产品。就测试而言,是个老兵,但就产品工作而言,是个新手。简单提下自己的感受:

      1.测试的输入输出很明确,而产品是不知道的。

      测试是看得见明天的,你甚至可以预计到解析来半个月、一个月、半年、一年内甚至更远即将要做、即将要测试的对象。因为对测试而言,需求永远都会有人为他澄清,找产品、找售前、或者直接找用户,有的公司甚至专门设立有需求工程师的职位,测试只要跟着需求就可以了,显性的需求很清楚,隐形的需求需要稍微挖掘一下。但基本都是确定的。

      对测试QC而言,预期结果是很明确的,输入输出都是知道的,主要就是在做校验、核对工作寻找缺陷,有些高级一些的,基本做到一点预防BUG;而对QA而言,则要确保质量标准是完整的,制定的流程是清晰的。但,其实这些都是固定的,有章法的,方法论在那里,一切都是有章可循的。

      但是对于产品而言,你是不知道的。你永远不知道怎么做,才是一个好产品。如何做,做怎样的产品才是更能满足用户需求、在市场上更受欢迎、而且可能会在以后引领潮流,改变人们很多习惯的一个东西。这是值得思考的。

      或许,你会感到比较酷。觉得自己也像乔布斯一般。呵呵,错了,并不是每个人都是那样的。

      2.测试面对的人相对容易沟通,而产品面对的人未必如此。

      主要面对着开发,甚至位置都天天在一起坐着;

      而产品则不同,你可能得出差,面对不同的用户,有的很聪明、有的很小白,有的用户很豪气,有的很刁钻,你永远不知道你会面对什么客户。

      3.测试的工作要更直接,而产品的显得迂回。

      测试需要准备测试计划,测试资源,测试用例,实施测试,完了提交测试报告,测试报告一般会实事求是的记录当前版本下测试的情况,BUG率多少,性能如何?测试用例通过率如何,需求验收情况如何?看,很客观的数据,是多少就写多少,没有任何水分。

      而产品未必,很多语言的东西,不做量化,甚至原型图概念,都是相对模糊的。而需求分析即是是经过与用户实际交流的,但是用户可能甚至都不知道自己究竟需要什么。用户脑袋里面想的是一个东西,结果语言描述出来是另外一个,而产品听的又是另外一个,画出原型图又可能是另外一个,对内部研发描述之后,研发们的理解又是另外一个玩意儿......看,经过多个人的中转之后,用户想要一个西瓜都有可能会被实现成为一个篮球。

      4.测试相对产品加班较少。

      当版本发布之后,测试往往会稍作休息。然后才可能准备下一版本的事情。而产品则不然,版本发布之后的这段时间,产品依然要继续,准备下一版本的计划,融入完善和优化产品的需求和想法。当测试们休息睡觉的时候,或许产品还在苦苦的回邮件,写需求分析呢。产品工作会更累更忙。

      5.相比测试,产品要承担的责任更大

      一直在说测试是帮助产品提高质量,不能保证产品的质量。那么产品的质量谁能保证?开发?架构师?设计?不会的!测试再把最后一道质量关,甚至都保证不了。还要谁保证?测试只是尽可能帮助提高一下,在交付用户之前内部先发现一些 BUG,请开发修改掉,另外一些性能问题,安全性问题充其量优化一下而已。

      但是产品是最直接给用户承诺的人,用户的需求来源、交付情况,产品是最直接的参与者。产品方向的错误,可能将导致内部研发方向的错误,外部用户的不买单,无疑造成一大悲剧。所以,产品承担的责任要更大。

      6.相比测试,产品的挑战更大

      正如前面所说,测试很多东西是确定的,明确的,很多公司甚至没有测试,或者由人兼职做下测试,当然也可能没有专门的产品经理。但是,肯定有人在定义产品方向。

      .......

      胡扯半天,未必每句话都是对的。希望各位朋友拍砖,给出更好建议!

      产品的路,任重而道远!欢迎各位测试大牛,产品经理等圈内高人来多多交流!

     

     
     
    分类: 产品经理
  • 相关阅读:
    使用shape来定义控件的一些显示属性
    Button颜色选择器进阶
    android用于打开各种文件的intent
    虚拟机操作
    二维码生成与读取
    input框只能输入整数
    实现FF背景透明,文字不透明
    打日志
    多选框
    时间戳
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/3203177.html
Copyright © 2011-2022 走看看