适用场景:测试团队建设总结、测试资源优化总结、测试流程管理总结
演讲要点:测试人员扩充提升效率、测试需求点位大幅增加、测试设备配置优化升级
行文逻辑:扩充测试人员→提升测试需求点位→优化测试设备配置
我是在7月份到新单位工作的,新单位是一个很不错的单位,项目饱满,资金等方面也没有太多的问题,但就测试部门工作的情况却很不乐观。具体表现是人员少,任务重,人员不稳定。领导对测试部门的工作很不满意,在面试我的时候就多次表示了对公司目前测试不满,期待我来之后能够带领测试部门有一个比较好的发展。
首先说说我们公司测试部门在这四个月的变化吧。
1、测试人员大量增加
原来的测试人员为3人,现在为14人,人员扩充了3倍,目前来说,测试人员的数量还不是很多,但相比原来部门的扩充速度还是很快的,另外一个方面,由于我们工作比较有成效,领导基本认可开发人员和测试人员比例可以达到1:0.8或1的比例。我想这个比例对一个国内的企业来说已经是很高的比例了。
2、个人素质的提高
具体的个人素质提高不是很好说,还是用项目来说吧,我刚来的时候,测试人员在一个系统测试的时候,一般测试需求点位500个左右,后来一个项目在作回归测试的时候,测试需求点达到15000个,第二次回归测试的时候测试需求点达到了49000个,这里要说明的是,我们测试需求点的增加不是为了增加而增加,而是对被测试需求各种使用情况分析的更详细,程序覆盖强度越来越大的结果,测试发现的问题深度逐步增强的反应。
3、机器设备的变化
测试人员是开发群体的弱势群体,他们的机器配置也是公司低的,刚来的时候,测试人员使用的机器都完全不能满足自动化测试的需要,目前,测试人员基本都提高了机器配置,测试人员很高兴。另外我们还有专门的测试流程管理服务器,一些淘汰下来的老机器作为专门跑测试用例的测试专用机。
4、开发人员对测试人员的态度改变
测试人员在开发过程中处于弱势地位,这是一个不可回避的现象,原来开发人员可以随意的让测试人员做自己认为需要的测试,而测试人员是没有办法拒绝的,甚至连具体测试的方法和手段开发人员都要干涉,而一旦出问题,首先怪罪测试人员,而不是找自己的责任,测试人员成了项目失败的替罪羊。而现在这种已经发生了很大的改变,至少测试人员有能力展示他们的特长。而不是开发人员的附属。
5、领导对测试工作的态度转变
我刚到单位的时候,领导们对测试工作很不满意,给我印象深的是领导说,测试部门的工作人员,可用的就留下,不可用的就直接开除,这对测试人员的工作评价实在不高,现在好多了,首先测试部门现在的工作得到了领导的认可(原来我们总是被批评,而现在总是被表扬),其次,人员、设备的配置在增加,重要的是,我们要求的测试时间可以得到保证。
适用场景:测试体系建设总结、测试流程优化总结、测试管理方法总结
演讲要点:测试环境搭建与工具配置、测试流程规范化建设、新订单系统测试问题分析
行文逻辑:组建测试部→建立测试环境→制定测试流程→开展系统测试→分析测试问题
光阴似箭,岁月如梭,一转眼,我来到__已经九个月了,在这段时间里,我们公司从没有测试人员,到测试部的建立;从没有测试环境到测试服务器的建立,测试工具qc、性能测试软件loadrnner的安装使用;测试部规章制度的建立测试流程、测试规范、bug等级制度的建立、测试报告模板的建立、qc使用手册的书写等等;
在这近_个月工作中,我们测试部苦过、累过、紧张过。但这一切最后都被成功的喜悦所代替,我们测试部也就是在这苦中、累中、成功、失败中一步步成长起来。
20__年_月,我来到__,在李经理的指导下负责测试部的组建、部门制度文档的建立、安全测试软件的研究、盘点机系统的测试、新订单系统的测试等工作。
虽然测试部在20__年中取得了不小的成绩,但是还是存在很多不足,比如新订单系统的长期测试,工期长期推延,迟迟不能结束!这是测试部在下一年要重视的地方,要认真总结的地方!
下面是这一年测试部遇到的重大问题及原因与对策:
1.新订单系统的多伦测试后还不能封版完工
原因:
bug太多,严重影响阻碍测试的进度(尤其是报黄页的bug);具qcbug管理系统统计,新订单系统中bug总共__个,一级竟然有__个之多!
2)存在拆西墙补东墙的严重现象(很严重)
原来好的没有bug模块,由于修改bug重新出现缺陷,出现拆西墙补东墙,bug循环出现,杜绝bug遥遥无期!
3)软件开发基本定型后,还在修改数据库结构,修改底层代码!
4)软件开发基本定型后,还在修改需求!
5)开发人员不按照需求开发软件;开发出来的模块或功能和需求有出入
6)部分模块需求在测试快结束后,需求还没出来,开发人员在等需求!(如新订单系统中的利润表模块)
7.)测试人员不足;软件模块太多,测试周期长!
对策:
1)检查:对于1级bug太多,只要开发人员开发出的模块后或修改的bug后自己先走查一下流程,看看流程是否能走通,是否还报错,这样就能确保一级bug出现的机会大大减少!
2)开发人员在修改bug之前一定要认真先想一下,我这种修改方法会不会给其他模块带来bug?会不会影响其他人员的模块出错?然后在下手修改代码!
3)一旦所有人进入全面开发软件后,数据库和底层代码就不能变动!
4)一旦进入开发阶段,需求就不能再随意增加变动!
5)开发人员严格按需求开发项目,不能私自变动开发;如有变动需要,要所有部门领导在一起商量,并下发通知商量后的结果!
6)要做到在写代码之前需求必须全部写完!
7)大型项目,测试人员必须配足,岗位齐全,从而缩短测试周期,一个人的精力与技术经验必定有限!
适用场景:项目测试总结、团队管理总结、流程优化总结
演讲要点:测试任务规范制定、测试用例设计优化、部门制度完善举措
行文逻辑:制定测试规则→编写测试用例→整理测试文档→培训新人→完善制度
转眼间来公司已经一年多了,在这一年多的时间里做了很多工作,也学到了很多知识与道理。下面针对20__年的工作情况,进行简单的阐述。希望各位领导和同事能对我的总结进行批评指正。
一、工作职责
我的工作职责主要有以下几方面:
1、功能测试。
2、性能测试。
3、配置管理。
4、培训、带领新人。
二、工作总结
20__年我主要完成了以下几方面的工作:
1、测试工作。
2、配置管理工作
负责将每次测试的交付物、培训文档、测试模版等整理并上传到svn上。
3、培训管理工作
20__年下半年,由于工作较为繁忙,测试团队在不断壮大,我负责带领指导3个新人。负责培训测试技巧,指导书写文档等工作。
三、经验分享
从多次测试任务中,总结出以下两点:
1、测试任务开始前,将测试范围、深度、文档书写规范等规则统一制定好,减少返工的工作量。
2、编写测试用例前,将所有情况简单列举出来,与开发人员或需求提出人员确认无误后,再具体形成文档。
四、对部门建设的建议
在部门建设上,我想可以从以下几方面逐步开展部门建设工作:
1、强化制度建设。例如:系统上线后新增bug的责任划分、任务延迟时需说明原因等。
2、争取能让开发人员了解测试过程。如果能让开发人员了解测试过程,可以让测试工作更好开展,以及获得更好的配合。
3、加强部门测试成果的积累与沉淀。每次测试完成后,相关测试人员要进行业务总结,写成文档上传svn,以便知识共享。
4、除了将已有测试成果进行有效管理外,还需要将已有的测试知识沉淀下来。例如:对项目的测试经验,性能测试的经验,测试用例设计经验等等。
五、20__年计划
20__年,我希望能通过参与具体项目的实践,达到以下目标:
1、能将测试过程在项目中真正的运用起来,并让项目的开发人员了解我们的测试过程。
2、在项目中沉淀出一些部门成果。
3、除了保质保量的完成项目测试工作外,我还将积极、主动的参与部门建设工作,和部门所有成员一起努力,在领导的指导下,将我们部门做成受到公司认可,有一定地位的部门。