如何做好软件测试管理人员
转自51testing,写的生动实用,没有大话空话,可以看出作者完全是自己实践得出的真知!---1. 具有较好的人格魅力和亲和力:真正来说做到这一点非常难。
这不仅要求测试经理有宽广的胸怀,良好的沟通能力和语言表达能力,还要求测试经理具有较强的应对能力。
向上能把工作汇报的让领导满意,令领导信任。
能把工作任务轻松, 无异意的下发给下属, 并让他们饱含工作热情共同协作去完成测试任务。
如果您能够把扭转下属的思想,把“要我测试,变成我要测试”,我想你一定很强了。
如果陌生的人一见到你,通过谈话就觉的你很强,都愿意和你交朋友,那你的人格魅力一定不错了,呵呵。
2.最好具备较强的测试技术水平:一般来说,作为测试经理,在一个测试技术性的团队里,如果你有很强的技术,并且你的技术是最棒的,下属不能够搞定的问 题,你都能够做的很好,即时有时候你凶了点,团队里的成员心底里都还是很敬佩你。
如果你有技术,但是技术不高,你组内的技术高手一定是你的亲密战友,这个 时候唯一的出路就是凝聚团队的力量,取长补短,也能够取得较高的效率。
还有一点值得注意:在分派工作的时候,找一下组内的骨干,看看是否有新的或者好的处 理办法,这样一来,避免在开会的时候遇到分工或者技术上的尴尬局面。
但有的测试经理具备了很强的技术,整天对团队的成员都板副面孔,那你也很难做到人见人 爱。
唯有为人待人真诚中肯、随和亲切,整天都是笑脸相迎,那呆在这样的团队里工作,一定很开心。
所以要做到人见人爱的测试经理,较强的测试技术水平不能够 忽视。
3.乐意处理下属在项目中碰到的困难:在带领一个团队开展测试工作的时候,当你的下属碰到困难的时候,你更多的是给下属鼓励和安 慰,帮助下属分析出现问题的原因。
比如说一下:“幸苦了”!“干得不错”!“慢慢来,没关系的”!下属听了也很开心的,并且以后干活可能会很卖命,因为他 的工作得到了领导的认可。
或许该问题你也不一定解决得了,这时候你一定要挺身而出,协调测试团队的资源尽力帮他解决问题,久而久之,你的威信就树立起来 了,之后就好办事了。
4.勇于承担责任,把功劳推给测试团队:软件测试经理,作为一个中层经理。
管理者一定要想管好下属,必须“身先士卒”、“以身作则”,事事为先、严格要求 自己,处处起到表率作用。
示范的力量是惊人的,一旦通过表率在团队中树立起在员工中的威望。
将会上下同心,大大提高团队的整体战斗力。
常言到:“得人心者 得天下”,做下属敬佩的领导,将使管理事半功倍。
如果下属在测试项目中出现问题,上级领导怪罪下来,自己勇于承担,多检讨自己,少怪罪他人。
始终用平和语 气与下属沟通,最后一定要找出出现问题的真正原因。
让出现问题的下属,自己过意不去,从心底里佩服你,想法补偿你。
项目得到喜讯,比如:某个测试项目做的 很好,领导表扬的时候,把功劳推给大家,很多时候,容易让人感动,让人佩服得“五体头地”哈哈。
5.对下属多一些宽容和生活关心:特别是对下属不懂,自己懂得很精的地方,下属问的时候,一定要有耐心,给下属详细讲解。
切忌:看不起下属。
如果真是这 样,你这个经理就很失败了。
反正对下属,在很多地方,要多一些理解和包容,最好能和下属打成一片,当下属不认为你是领导的时候,你就真是领导了。
如果做领 导做到别人都当你是朋友,那你真的就成功了。
还有一点就是要察言观色,随时发现和了解下属的困难,不管是工作方面,还是私人方面,都要关心。
比如说:某个 下属买了房子,准备装修,那他一定很关心装修方面的东西。
如果你懂得很多,那和他交谈时,多一些这方面的话题,他也会很开心,觉的你这个人相当热心,并且 也会觉的大家有共同语言,以后当你碰到问题的时候,他一定会鼎立帮助你,因为他认为你是他最信任的知己。
也可以多在生活上关心下属。
比如有项目要加班什么 的,有时候陪陪下属加班呀,吃个午饭宵夜呀,聊点家常呀什么的,自己买单后,公司报销,效果真的不错哟!6.力争多给下属争取福利在公司条件允许的条件下,多给下属争取福利!但是做这件事的时候,一定要在公司利益和员工利益之前要平衡。
若过分的给员工争取福 利,会造成公司对你有意见,同样,过分的以公司利益为重,员工对你也会意见大!总之,每种情况都要有度,力所能及的事,一定不能放过。
很多时候,为员工申 请比较多的福利,即时没有成功或者工资变化不大,但是下属都看在眼里,还是很感激你的,因为他知道你已经尽力了,觉的你很够哥们,为你工作很值。
7.多给下属锻炼机会,培养下属能力:作为测试经理不可能向测试工程师那样什么事情都自己做,并且事事都自己做也不现实。
可以在不同的测试项目中,安排测 试主管。
然后对测试工作进行协调,参与测试中发现重大问题的讨论。
这就要求测试经理懂得用人,懂得计划。
在制定详细的测试计划的同时,自己把握测试项目中 的关键点和时间表,给下属更多的实践机会,让下属做事更具有责任心和成就感。
测试主管在做好测试项目的同时,又减少了测试经理的工作量,学...
软件测试人员的量化管理有哪些呢?
一、测试设计 1、工作效率相关指标 (1)文档产出率:这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。
用于考察测试人员测试用例文档的生产率大小。
公式:∑测试用例文档页数(页) / ∑编写测试用例文档有效时间(小时) 参考指标:根据项目汇总得出平均在 1.14 页 / 小时左右,高于此值为优,低于此值为差。
(2)用例产出率:这项指标值主要为上述指标值的补充,用于考察测试人员测试用例产出率大小。
测试文档页数可能包含的冗余信息较多,因此要查看文档中测试用例的多少。
方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。
公式:∑测试用例数(个) / ∑编写测试用例文档有效时间(小时)来源:考试大 参考指标:平均 4.21 个用例 / 小时 2、工作质量相关指标 (1)需求覆盖率:计算测试用例总数之和除于与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情况。
来源:www.examda.com 公式:∑测试用例数(个) / ∑功能点(个) 参考指标: 100 %。
如果连功能指标都不能满足 100 %覆盖,起码说明测试不充分。
这个指标收集起来相当困难,如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。
(2)文档质量:测试用例进行评审和同行评审发现的缺陷数,或者将此缺陷数除于文档页数算出比率。
此指标考察测试人员文档编写的质量如何。
公式:∑缺陷数(评审和同行评审)(个)来源:考试大 ∑缺陷数(评审和同行评审)(个) / ∑测试用例文档页数(页)采集者退散 参考指标:由于评审是发现的缺陷数是不固定的,因此,这个指标没有可供参考的数值。
如果缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向对比。
(3)文档有效率:使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。
用于考察文档是由有效的指导了测试工作。
公式:∑缺陷数(系统测试)(个) / ∑测试用例文档页数(页) 参考指标:平均 2.18 个缺陷 / 页 注意:如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部分。
(4)用例有效率:使用测试用例发现的全部缺陷除于测试用例数总和。
这一指标是上一指标的补充指标,用于考察用例质量是否较高
软件测试之测试管理有哪些原则?
5.重视结果而非时间 许多认可建立在员工完成工作的时间上,而不是他们最后的成绩上。
但是,花费在工作上的时间不一定和创造性有必然的联系。
如果你真的想改善对创作性和工作效率的认可的话,不妨考虑保证你员工每周只工作40个小时。
我常常听到一种表示对员工的异议就是“你整整一天什么都做不出来。
6.承认自己的错误 每个人都会犯错。
他们会因为忘记开会而使客户发怒。
承认你犯错是令人尴尬的。
我们中的许多人认为对小组承认自己犯错会失去尊严。
如果你不是经常犯错,你承认错误的时候其实能够赢得尊敬。
如果你忘记一次会议,你为此道歉,其他的人会理解你并且最终原谅你。
7.决定承担一个项目必须首先问你的组员是否有能力完成当你是一个下级的员工,你的老板对你说“我们是否可以在下个十月完成项目?”回答说“当然”会令人惊讶。
但是,你的员工会因为你回答“我要考虑一下。
”而表示赞赏。
什么是软件测试项目管理
项目管理是一个管理学分支的学科,指在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望。
项目管理是对一些与成功地达成一系列目标相关的活动(譬如任务)的整体。
这包括策划、进度计划和维护组成项目的活动的进展。
软件测试后测试用例怎么管理系统
以一个网站注册功能为例: 用例编号:register001用例标题:注册功能验证用例级别:高预置条件:服务器开启输入 : A.用户名:11111 b.密码:22222 C.确认密码:22222 。
。
。
操作步骤:1.进入注册界面。
2.依次输入A,B,C... 3.提交。
预期结果:注册成功,跳转登陆界面。
。
测试项目管理和普通的软件测试有什么区别呢?
测试项目管理和软件测试区别还是很大的软件测试相对而言你要负责面可能就是做好自己的工作,就算合格了,主要负责1)测试用例的准备,2)测试执行,3)提交缺陷,当然其实性能、安全也是类似的工作,相对而言软件测试主要负责执行类的工作,以及整个测试项目中的某个环节。
而测试项目管理负责的工作就比较多了,首先,你要会涉及到的各种测试任务,因为在每个测试执行前,你需要进行测试用例的评审,和需求、用户、开发,你要对你的团队人员准备的测试用例是否符合要求有个直观的了解。
其次,你要了解你的项目流程规范、规则、体系,你要了解你所带领的测试团队,在项目的什么时候要做什么事情。
第三,你要会正确的时间安排,首先要保证测试团队在项目中,有足够的时间进行测试、回归,保证项目的质量,同时不能造成项目延期,第四,好的沟通,作为测试团队项目的管理者,你不仅负责着团队的工作,更是要能够和上级、下级、项目经理、用户进行沟通,无论是需求阶段的先期沟通和介入,还是在执行阶段,甚至后期的运维的时候,测试经理都会需要和他们打交道。
最后是心态的调整,测试在国内最不待见的(你找茬,没人会喜欢你),所以,你会得罪人,不过请记住,良好的心态、不懈的坚持、公正的态度,是做好一个测试项目管理必备素质之一。
这是我从一个工程师干到负责测试项目所积累下来的经验,希望对你有用。
...
项目管理的软件测试有哪些经验呢?
1.测试用例包含测试文档和测试数据两部分,在实际操作之前,请先准备好测试数据,即要在界面上录入的数据,原则上是所有在界面上输入的数据都要写进测试数据(excel表)中,并注意归纳整理,每组测试数据都应有相应的测试目的。
2.测试数据的准备需要考虑到一定的覆盖率,但100%的覆盖是肯定做不到的。
请根据测试用例文档的内容尽量达到最有效的覆盖。
3.测试用例并不是一成不变的,应在测试过程中随时更新、补充,不断完善。
如果在测试过程中发现原测试用例有不完整甚至是错误的情况,请及时补充或修改。
这一点很重要,切记。
因为在此时多一分心,将来的测试工作必会少几分力。
4.在测试过程中发现的BUG请填写到缺陷管理工具TTP中,特别注意要将BUG情形,重现步骤等描述清楚,不要因偷懒或错别字等原因使得开发人员无法正确理解和无法重现该BUG,甚至造成歧义,以免对开发者和测试者增加许多不必要的工作量。
5.做好BUG的跟踪工作。
测试工作并不止于发现BUG,而应对每个BUG跟踪到底。
BUG自提出之后,就要一直跟踪,敦促相关人员解决。
时间太长仍未解决的,要查明原因,并汇报至项目经理处。
在TTP中,则体现为所有的BUG最后都要处于“closed”状态。
6.做好版本控制。
程序源代码的版本控制工作由开发组负责,但测试组也需要管理好测试系统的版本,保持与最新程序同步,以免对不正确的版本进行测试,做无用功。
7.做好回归测试。
开发人员修改BUG后,测试组要尽快将程序更新至测试环境,并做回归测试。
此时除了验证所发现的问题是否被修正外,还要特别注意的是,此项改动是否会对系统的其它部分造成影响,从而产生新的BUG。
因为有时候程序员对程序的一个不正确的,哪怕是小小的改动,都可能会对系统带来更多的BUG,而这些BUG往往又是很隐蔽的,所以要特别小心。
这一点非常难做到,需要靠测试人员的经验和细心。
这里有一个比较好的方法,就是要求开发人员在解决问题的同时,要详细的说明该问题产生的原因,及他对哪些源程序文件做了什么改动,填写到TTP中,越详细越好。
根据我们部门以往的测试经验,我觉得这一点做得还很不够,很多程序员并不愿意做过多类似的归纳整理工作。
其实这是对大家都有好处的事情,一定要请大家共同配合。
8.在测试过程中,如果重复的操作过多,在条件允许的情况下,可考虑使用功能测试工具winrunner,quicktestpro等来简化操作。
软件测试之如何有效实施成本管理呢?
要把成本管理的具体行爲按照每个步骤进行好,就要依靠类别预算提供给我们的资讯。
成本管理的实施进程功能和类别成本可以促动一个基本的IT成本模式的运行。
这个模式不可能解决公司在成本管理中面临的所有难题。
公司的管理者还需要在对公司的规模、具体应用、商业进程和固定可变基础综合考虑后再做出成本预算。
尽管这样的模式不能满足所有的需要,但是它可以提供给公司管理者回答这些问题的基础。
更重要的是,“功能成本+分类成本”的成本管理模式大部分公司都能使用。
很多标准金融报告系统能够提供功能和类别预算,而运行这些成本模式也并不复杂。
统计图表是进行类别分析的关键。
与你公司的金融部门协作来扩大图表功能范围以适应本公司的需要。
大多数金融系统支援标准图表的扩大,而且进行这一步的工作是相当容易的。
功能成本通常与IT公司的结构紧密相关,所以有关的金融系统资料一般来自公司的财务部门或是成本管理中心。
首先,根据公司的业务需要来进行你公司的机构设置,然后与金融部门合力在公司的金融系统中建立一个成本管理中心。
这一步骤也很容易做到。
一旦你对公司的金融系统做了调整,你必须采取一些必要的措施来保证在新的结构下公司的成本管理具有保密保障。
简单做来,要对调整变化进行记录,并对相关人员进行培训。
要做得完善一些,还需要管理者对你所做的工作进行重新审查,有可能的话还要修改公司现行的成本开销所需要的程式。
总结没有哪个公司的CIO想要把更多的精力投入在公司的成本预算上面,但是商业界的现实告诉我们,这些CIO必须管理好他们公司的成本,至少要像其他单位的财务部门所做的工作一样才行。
一
软件测试缺乏配置管理的问题解决方法有哪些呢?
由于缺乏必要的配置管理流程和工具,很多软件企业在日常的开发工作中都会或多或少的遇到如下的问题:组织的知识和过程财富流失现代的社会竞争激烈,人员流动频繁,如果由于没有必要的配置管理流程和工具,大量的文档和代码等知识财富必然缺乏统一的管理,可能随意地保存在项目经理和软件工程师各自的机器里,往往会因为硬盘的故障或人员的离职而永远的消失,软件组织的数字财富就这样因为缺乏必要的配置管理而白白的流失。
不能及时了解项目的进展状况现代软件工程思想认为越早发现缺陷和风险,采取相应措施的代价越小。
CMM 的一个重要作用就是要提高软件开发过程中的可视性,使得问题能够被及时的发现。
然而由于缺乏配置管理的流程和工具的支持,部门主管无法确切得知项目的进展情况,即便是项目经理也不知道各个开发人员的具体工作,项目进展随意性很大。
所有的问题往往都会集中到项目里程碑时一起出现,这必然会造成巨大的开销,其结果往往是容忍部分缺陷存在或者延误开发周期。
所有问题只能寄希望于最终实施时再解决,项目的实施工作因此变成了无法汇报、无法理清、无休止的维护。
缺乏实现并行开发的手段 在日常的开发工作中,经常会出现并行开发的需求,比如:对于一个项目可能要在开发新版本的同时继续对先前的版本进行必要的维护,或者针对某个特定的版本需要针对不同的客户同时进行客户化的修改等等。
在并行模式下,不同开发人员可以同时编辑修改某一文件,并行开发有可能产生冲突,但是却能够提高开发效率。
如果没有配置管理工具的支持,进行并行开发将十分困难,单单通过人工操作,往往会造成修改过的bug 重复出现或者几个人进行相同的工作,产生不必要的浪费。
软件复用率低下 软件复用是现代软件工程中的重要思想,是提高软件产品生产效率和质量的重要手段。
软件产品是一个公司的宝贵财富,代码的可重用性是相当高的,如何建好知识库,用好知识库将对公司优质高效开发产品产生重大的影响。
但如果没有良好的配置管理流程,软件复用的效率将大打折扣,比如对于复用的代码进行了必要的修改或改进,却只能通过手工的方式将发生的变更传递给所有复用该软件的项目,效率如何可想而知。
另外由于缺乏进行沟通的必要手段,各个开发人员各自为政,编写的代码不仅风格迥异,而且编码和设计脱节,往往会导致开发大量重复的难以维护的代码。
无法开展规范化的测试工作 在传统的开发方式中,由于缺乏必要的配置管理和变更控制,测试工作只是人们的一种主观愿望,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是走走过场,测试结果既无法考核又无法量化,当然就无法对以后的开发工作起指导作用。
对软件版本的发布 缺乏有效的管理因为缺乏有效的管理手段,往往会在产品发布时却无法确定该版本所有的组件,或者向用户提供了错误的版本。
对于特定客户出现的问题,无法重现其使用的版本,只能到用户的现场才能进行相应的调试工作。
由于应用软件的特点,各个不同的客户会有不同的要求,开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同地方提出,由不同人解决,其做法也不尽相同,程序的可维护性越来越差。
这些都会延长实施的周期,同时意味着人力物力的浪费。
缺乏历史数据的积累,没有软件开发的历史数据缺乏软件开发的历史数据是大多数软件项目失败的关键所在,这样的结论也许使很多人感到吃惊,但事实就是如此。
因为软件开发的历史数据是反映软件开发队伍的能力的标尺,没有了这个标尺,就无法对软件的开发过程有一个清醒的认识。
而良好的配置管理正是收集软件开发历史数据的重要来源。
无法有效的管理和跟踪变更软件的一个显著特点就是易于改变,没有配置管理将无法对软件的变更进行有效的记录、跟踪和控制。
转载请注明出处51数据库 » 软件测试主管 如何管理