51Testing软件测试论坛

标题: 历历在目的 2年 测试生活 [打印本页]

作者: 草帽路飞UU    时间: 2017-6-20 09:49
标题: 历历在目的 2年 测试生活
一、前言二、情怀三、懵懂四、清晰五、进击

作者: 草帽路飞UU    时间: 2017-6-20 09:49
六、升华

    天道酬勤,机会都是留给有准备的人的。16年7月份,我老大提离职了,产品总监第一时间就是让我接手,慌张的心又开始跳动,我才工作参加一年,就要做测试老大呢?我能不能做到,团队中还有比我更有经验的小伙伴,为何是我?或许我真的是有备而来的,还是那句,有机会干嘛不试,跳动的心沉静下来,好,我来,就是那时刻,我开始担任团队的测试老大
    可以说我是个小白老大,之前一点管理经验都没有,不过以前在大学当学生干部的时候或多或少还是有一些作用的,做leader的第一件事,调整团队的测试工作方式,实现所谓的端到端测试(这是我理解的端到端,可能和其他朋友不一样),就是一个人负责一个端的所有方面的测试工作,比如自动化,性能,专项,甚至是测试工具的开发,果然这效果还是每明显的,一个月过去,产品端的质量真的有所提高,同时团队成员针对端的能力也提高起来,这是因为以前大家做的事情都太乱了,还不如先专注做好一个方向,再做其他的,所以就想到了用端到端的方式,在这期间,我们把web端,ios端和android端的自动化测试推了起来,每一端基本都是独立一人完成的,就这过程,团队的成员熟悉了怎么用RF的框架,后面我还强调大家要学原理,还分析过RF的执行原理和分层结构,这样大家不仅能力提升了,产品的自动化测试也得到推进,巩固了测试的环节,显然,持续一段时间,产品的质量能得到提升,尤其是web端,以前季度bug数会上100多的,后面就50多,而且以前每个版本测试周期为一周,后面2到3天就行了,这都是效率的提高,成员得到升华,质量得到保证,这是测试工作的最优状态
    第二件事,其实以前做的都只能叫做产品测试,还没到达产品质量保证的高度,项目发展到一定程度,有些事情还是要管起来的,一开始是什么情况,测试团队是在研发提包给我们的时候,我们才知道要测什么,这是不对的,版本管理无任何秩序,什么时候上线什么版都不清楚,比如上线和发版的定义都区分不了,于是,我联合测试团队的成员和产品经理,研发等开始制定产品的质量流程,像需求评审、用例评审流程,这看起来有点不像互联网敏捷团队的模式,但我们是以一种轻便地方式来实现,产品主大局,产品需求一般是阐述大概要做什么,但很容易会漏掉细节,谁补,测试人员,不是总说测试比产品经理更了解业务吗,所以用例评审的时候我们就可以体现细节的问题,用例编写和研发实现的周期调整为同期,测试左移,用例编写完成后用例评审,我们也不是说一条条用例地看,对于敏捷,快速迭代,这不是个好办法,那用什么,xmind是个好工具,产品经理能用来列需求,测试也就能用来列测试关注点,测试关注点覆盖产品需求路径,同时提出产品需求未描述清楚的地方,并且通过易用性,功能性,可靠性等一些方法也提出关注的细节,这样既能补全需求,也能前提告之研发哪里有坑,同时也巩固测试的一个关注点和范围,一举多得,可能这说成用例评审有点怪,叫测试关注点评审更好,随便,为解决问题而设计实行适当的方案或流程就好,与此同时,那为产品作版本灰度上线方案,设计灰度的范围以及要关注的功能,同时版本上线之后,做好和客服的对接,做好线上问题收集和整理,还有很多,像版本号管理,提测规范,上线流程等,虽然作为测试负责人,但在产品质量保证的范围下,事无巨细,从需求到研发到测试到上线运营,每一块都需要保证
    第三件事,缺陷管理,每个测试人员提bug的方法方式都不一样,甚至bug描述方式都不一致,研发经常和我吐槽,提bug连个图都没有,测试环境没有,甚至没有测试账号,然后我们研发环境又没重现,那要怎么修bug,还有的是,客户经常反馈的bug范围和我们测试发现bug的范围相差深远,说明两点:1、测试重点没有贴近客户,我们所认为的重点模块不是客户的常用模块,2、我们提bug的质量没有保证,加大了沟通成本,这个也是要解决的问题,怎么做,我们先把产品的各个端的功能模块分类好,作为bug的功能分类标签,明确模块优先级,制定bug优先级权重,同时标明好无效bug和线上bug作为测试人员的把控质量的一个评价指标,举个例子:以前我们总是觉得我们的沟通模块很重要,一般一个版本可以在沟通模块测出25个bug,然后协同模块才5个bug,结果上线之后客户反馈的问题或建议全是协同模块,沟通模块没几个,就是证明,客户目前多数是用协同模块,但我们却把工作量放在沟通模块,那就不太对了,所以结合线上bug的数据作为一个测试重点的一个标准,同时还有就是我们平时在当前版本结束之后,对功能模块所对应的bug数进行分析统计,做好缺陷趋势分析和风险预估,那下一个版本的测试范围和重点就出来的,这个是提高效率的方法,同时我们统一了bug的模板,每个人的格式都是一致的,研发看起来舒服,bug自然也修得畅快,我们回归的时候也舒服,一举多得
    还有很多很多,我作为测试负责人之后,的确是做到了为团队带来了一些改变,这也是我本来努力的方向,后面在团队里面坚持每月至少一分享的习惯,厉害的时候,一个星期4次,但是我们都不是瞎培训瞎学,脱离业务的技术方案都是炫技,华而不实,我们培训都是为了解决当前工作上遇到的问题的,都是学最能解决问题的技术方案,而且我一直很崇尚圆桌型的培训,虽然有主讲人,但每位小伙伴在培训之前都或多或少去了解培训主题涉及的内容,之后培训的时候大家一起提出不同的看法和见解,经过自己思考的接受学习也是有效,大家共同进步,这有什么效果呢,说点实在的,前文提到本来测试团队几乎没人会敲代码,后面16年底17年初,都已经会独立写一个测试框架和app专项测试工具了,而且这过程中还不断引入像anyproxy、docker,locust等一些技术方案到团队,也说起分享培训,我自己也是活跃在各大测试技术群里面,以前也是到处问人,到现在到处帮助别人解决问题,还是回到分享者才是培训的最大收益者,自己不懂的,还会刻意去搜贴结合自己的经验得出解决办法,空余的时间也会去参加一些测试沙龙,和其他同行保持交流,了解行业的发展动态,自然而然,接触的知识和人也多了,渐渐地学会了洞悉技术发展方向,能够迅速地了解和学习适应时代的技术,这也是作为一个测试人员的嗅觉,懂得变,学会如何进步
    七、沉淀
    质量保证分为3大块,产品质量保证,交付质量保证,运营质量保证,只有这三大块做好,产品的价值实现才会得以保证,但是有多少人是理解这三块是要做什么的,所以我就说有部分测试人员对自己的要求不高,测试的价值是可以再提升的,看看上面的三块,就知道测试人员的重要性,但又有多少人做到
    我在年初的时候面试了很多测试人员,其中还面试了几位工作超过10年的前辈,这里不是抹黑,的确有一个现象,我面试那位前辈,工作10年,之前也是测试负责人,自己是偏向自动化测试的,好,我问他怎么做移动端的自动化测试,他也是知道用appium+语言这个方式去做,我问他是怎么设计一个自动化测试方案去解决自动化的问题的,就一直和我说工具,我问他有用什么设计模式去提高代码的可维护性和执行效率的时候,不懂,好,我问appium是怎么和手机通讯来执行自动化测试的,也不懂,其实都没问题,最后让我直接否决掉的原因是,我问他是怎么管理测试环境的,他说测试环境是研发和运维搭的,测试不懂得搭,算了,我聊不下去了,我问原理,是因为作为测试负责人,也是一个带人的角色,你自己都不了解清楚的东西,在团队里面实现,团队的成员也不会了解清楚的,估计解决问题的程度也不高,感觉就是在项目里面用用而已,而且连最基本的测试环境都给研发或运维做,那测试做什么,怪不得别人说测试低端的,东西不仅要学会,还要学精,上面的情况违背了力所能及即可为的原则,而且都不仅是能及,是基本要求。
    第二记得应该是工作4、5年的,问测试策略和测试计划的区别和作用,和我说没做过测试计划和测试策略,还有个更离谱的,简历里面写着自己会性能测试场景设计,面试的时候给个案例给他做,写不出来,什么是业务场景设计,什么是数值预估和瓶颈分析都不太清楚,我直接问他做过多大的并发:50人,我马上跪了
    几乎没有人拥有我刚才所说的嗅觉,最简单,现在那么火的docker,我面试的所有应聘者居然没人知道是什么来的,就那么一段时间,我患上了面试恐惧症,简称“面瘫”,怎么做测试都不太清楚,不用谈产品质量保证,更不用说三大质量保证,别人总说测试入门低,在团队地位不高,我一开始也不太信,因为我们测试组在团队里面还是很有发声权的,因为我们抓紧质量,那些还是在点点点的,总认为自己找过多少bug很牛,学过多少工具很牛,到头来就导致认为测试很低端,话也说回来,我在面别人的过程中通过交流也学了很多知识和经验,同时我有个面试习惯,我会专门挑应聘者的问题来给他们提供一些建议和看法,就算后面面试失败了,我起码也不会让你白来一趟,更狠的是,我举办过一场特色培训,我让我们测试团队的成员做面试官来面试我,面到我说不出话为止,面试别人其实对自己来说也是个总结的过程,你在问别人之前起码你要了解清楚你要问的东西的原理,那才会踏实,那就是一个提高的好办法,所以我就让我们团队的小伙伴面我了,果然有效,她们当时还准备得挺充足的,我有几个时刻就差点说不话来,哈哈,我当时也感觉到大家已经明显进步很多了
    时代变了,仅仅是找bug牛已经不够了,所以后面每天一句:不要为了用工具学工具,要为了解决问题而学,还有要做质量保证,不仅仅是测试,bug是要预防,不是找,这让我更加巩固上文所提到的一些看法,也是在这段时间,我也不断地再深化提升自己,把之前去年做过的技术方案通过理解原理和结合业务,优化了几个技术方案并在团队里面使用,能解决问题,为团队带来好的改变,自然也会收到回报,除了能力的提升,地位的提升也会有的,今年3月我也被提拔为资深工程师级别,这些都是要靠积累的,要做上面的事情,我基本上每天只睡6小时,每天都在想尽一切办法怎么才能解决问题,提升质量,提高效率。天道酬勤

八、最后说几句

    人往高处走,自身的发展也很重要,也由于个人发展和家庭的原因,很快和现在的公司说88了,来公司两年,让我从一个测试新人蜕变,很感谢现在的团队和公司给我那么多机会和条件,让我得以发展起来,同时也通过分享我过往的经历,希望对测试新人们有一些小帮助,同时也欢迎前辈们继续给我还有我们这一辈测试新人指导,我们一起创造测试界的光明和未来
    一个成功的团队少不了这三种角色,第一:把控方向的人,一般是产品负责人,团队的生死几乎就看他了,第二:团队第一生产力,一般就是架构师,技术最牛的那位,有方向,有策略,还要看能不能实现,第三:据说外国对他有个称号叫master,他懂技术,懂业务,懂流程,根本就是一名全栈人员,他了解团队的优势和劣势,从而能在制定产品策略,技术方案以及生产过程提出建议和改进方法加以保证,给团队发展保驾护航,他是团队的消防员和安保员,测试人员的最终发展方向应该就是这个团队第三人了,个人看法,大家一起加油,谢谢
作者: 海海豚    时间: 2017-6-20 10:23
受益匪浅!感觉自己工作的这一年,最缺的就是方向,一直都在学习工具,可以并没有多少用在自己的测试工作中。“不要为了用工具学工具,要为了解决问题而学,还有要做质量保证,不仅仅是测试,bug是要预防,不是找”,这句话我会深深的记住,谢谢您!

作者: 乐哈哈yoyo    时间: 2017-6-20 10:27
海海豚 发表于 2017-6-20 10:23
受益匪浅!感觉自己工作的这一年,最缺的就是方向,一直都在学习工具,可以并没有多少用在自己的测试工作中 ...

一起加油进步!
作者: 乐哈哈yoyo    时间: 2017-6-20 10:27
学习了!
作者: 草帽路飞UU    时间: 2017-6-20 10:28
乐哈哈yoyo 发表于 2017-6-20 10:27
学习了!

加油!
作者: 岛屿soliloquy    时间: 2017-6-21 14:50
学习版主的经验。一起努力……




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2