码迷,mamicode.com
首页 > 其他好文 > 详细

测试人员如何把控项目进度

时间:2020-01-08 10:45:39      阅读:132      评论:0      收藏:0      [点我收藏+]

标签:select   设计   nbsp   ==   大学毕业   发送   必须   存在   如何   

项目背景简介

项目代称

K项目

项目成员

6人(1个测试猿+5个程序猿)

项目周期

两个月(截止日期,国庆节前)

工时评估

以天为单位(模糊评估)

测试猿的窘境: 
1、需求文档不明确? 
2、提测时间不明确? 
3、项目进度不明确? 
4、我是谁?我该干嘛? 
想必每个测试猿都会遇到以上的窘境,版本到项目快截止时才提测,最后项目延误了,又要默默的背锅? 
项目进行了半个月,依然没有我什么事儿,我真的不想国庆加班啊,去年就已经安排了今年的国庆节行程,怎么可能延误,必须要改变现状了···

一、主动沟通,抛出问题

主动找研发经理沟通,抛出问题,提出解决方案;迈出这一步我也是三思而后行。 
1、找到沟通有效的人

· 找项目负责人?项目负责人只是其中一个研发,解决不了根本的问题。

· 找项目经理?项目经理经常出差,很难得到准确的回复。 

· 最后,只能冒昧约研发经理谈话了,程序猿的直属领导,应该是最有话语权了。

2、抛出问题,提出解决方案 
存在问题:

· 需求不明确,没有相关文档输出

· 任务没有划分优先级

· 任务工期评估模糊

· 按目前的进度,国庆前不可能完成该项目

解决方案:

· 工时精准评估,以小时为单位

· 提供产品待办列表,输出任务优先级、研发进度、提测日期等信息

· 进行迭代开发,三期迭代,每个迭代为期两周(离项目截止日期正好6周) 

技术图片技术图片?

备注:该图片为引用图片

沟通结果:

· 第一点被否定,可以尝试进行迭代开发

· 测试(me)主动提供迭代需求清单模板

· 测试提前介入,先行接口测试,后续功能测试

二、迭代开发,积极推进

1、我主动提供迭代开发需求管理模板 (见如下截图); 
2、总共三期迭代,每期迭代历时两周; 
3、周一:项目负责人邮件发出一期迭代需求清单,抄送项目干系人; 
4、周五:测试负责人,总结项目进度,邮件发送项目干系人; 
5、每期迭代结束,总结本期迭代的完成率以及优缺点,要生成可交付的产品; 

技术图片技术图片?

三、迭代结束,项目完结

经过为期6周的迭代开发,团队小伙伴的不懈努力、研发经理的不断施压;项目最终按时完结,回归测试也提前完成,终于可以安心庆国庆、过中秋喽···

四、测试经验总结

1、如何实现测试左移

· 需求阶段介入,明确需求甚至可以给出自己的对产品的设计意见

· 先行接口测试,尽早发现接口层面的问题,可避免后期测试浪费时间

· 重视数据库测试,新的项目所有的表都是新建的,可以从表结构、字段、索引等各个方面把关,遇到问题前期修改成本较低

2、多版本并行,如何高效执行测试任务 
由于我一个测试猿要对接五个程序猿,某天出现了同时提测四个版本的情况,在片刻的慌乱后我采取了以下方式:

· 提测任务按优先级排序,进行一轮主功能测试,使每个程序猿手头都有缺陷要处理;

· 对优先级较高的任务进行第二轮全功能覆盖测试

· 回归缺陷,之后再进行三轮冒烟测试,发现新的缺陷,绝对不能让研发空闲

· 就像玩游戏一样,轮番先各个研发扔bug,直到所有bug关闭才game over

3、迭代开发、敏捷测试 
由于我大学毕业后就加入了敏捷开发团队,敏捷(scrum模式)对我的影响很深,一直想在现在项目中推行敏捷,但是大家都不愿意拥抱变化,敏捷最大的一个特点就是“拥抱变化”。因此本次项目就采取了迭代开发的模式,用敏捷的思维进行测试

· 当面沟通,减少信息误差

· 持续改进,及时反馈问题

· 响应变化,停止推脱抱怨

4、有效管理缺陷,缩短项目进度 
敏捷中注重处理bug 的效率,发现问题快,修复起来也较快;我在实际的测试中采用了传统与敏捷结合的方式处理缺陷,减低了bug修复的成本,有效缩短了项目周期;具体总结如下:

· 页面缺陷,集中反馈,提供截图说明 ;

· 需求缺陷,双方沟通,达成共识后记录缺陷,可降低时间成本;

· 面对面沟通,主动重现解释bug;

· 重视缺陷的成本,高时间成本,低价值的缺陷建议口头通知解决,低时间成本,高价值的缺陷需要记录追踪;

· bug及时跟进:及时验证、及时反馈、及时关闭;

5、测试人员障碍补充

· 从质量上确定能不能上线的问题

例如:

 

一般公司会协商制定一个可上线标准,比如中等以上严重程度bug的修复率为100%,微小及建议性的bug修复率在80%等。有了标准,测试的时候 你要把这个版本涉及的功能要都覆盖到,新功能的,以及旧功能的回归等,你都测了再比对公司的标准或结合客户的业务,项目经理问你能不能上线时,你就很清楚的回答能还是不能了

· 测试进度不能推进有两个原因

一个是自身的,一个是团队的

自身的对需求理解不够,不如开发理解的深,这个对新来的是正常的,但是一定要积极的尽早的参与到需求讨论阶段,从整体上理解,再具体到功能的细节,有问题就问开发,想到的用例设计场景,没答案的和开发或产品经理等讨论确定。

没有做好的功能,肯定不能测试,测试人员都是有可测性接收标准的,没做或核心功能都没实现的,测试人员可以不接受测试,测了是对测试资源的一种浪费。这点测试人员要和公司层面达成一致,这个很早都是我们软件行业的一个通用的认识了

每一轮测试都会有计划,完成测试后,需要有测试报告(实现功能数,已实现功能数,已实现功能的bug严重情况统计)

· 原有的测试计划,是可能变动的(杜绝自己背锅)

重复的bug,需求的不明确,新的需求加入...都会影响测试的原有计划

例如:

我计划测100个功能点,设计500个用例,计划测1一个月,再加半个月的回归,就是1.5个月,原计划是9.1日开发提交可测的版本,那我就要测到10月中。

但是如果到了9.1日,开发根本无法提交给我,或者提交的没达到我们的可测标准被退回去了,等到9月中才再次提交,那我测试计划肯定要变更啊,这不是测试人员的原因了。

但是如果是开发9.1日按计划,提交了可测的代码,冒烟测试通过,测试接收了,但是到了10月中,由于测试的原因,工作量评估有偏差,人员变动等等,导致测试没进行完,给不出结果,这就是测试人员的原因。

这种计划也是可以变更的,只是这个变更是测试自己导致的,要反思和下次改进。

· 用测试数据说话,保障软件高质量。

千万不要拍脑袋说, 要测完之后用数据说话,结合项目讨论的发布标准。

在不完善的团队中,测完一轮,bug肯定很多,一般得要3轮才能达到上线标准。

测试给结论 是要很严谨和负责的。

· 测试人员如何看待重复bug

bug重现的,我们能做的也就是可以进一步分析下这一批次的bug重现原因,是配置管理没做好,代码没更新,还是代码覆盖了还是什么,让开发下次改进

总结

作为测试人员,一定要知道整个流程应该是怎样的,开发的责任是什么,测试的责任是什么,我们首先做好自己的,再推动其他的

然后就是业务了,基于对业务的理解去设计测试用例,这样覆盖的完善了,漏到客户那里的问题就少了

总之做好测试自己能做的,积极推动其他的,用数据说话,别拍脑袋,就可以了

总而言之:主动沟通、当面沟通、耐心沟通、持续沟通·····

测试人员如何把控项目进度

标签:select   设计   nbsp   ==   大学毕业   发送   必须   存在   如何   

原文地址:https://www.cnblogs.com/joy-sir/p/12165131.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!