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

一、主动沟通，抛出问题

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

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

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

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

2、抛出问题，提出解决方案 
存在问题：

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

· 任务没有划分优先级

· 任务工期评估模糊

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

解决方案：

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

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

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

备注：该图片为引用图片

沟通结果：

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

· 测试提前介入，先行接口测试

二、迭代开发，积极推进

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

三、迭代结束，项目完结

经过为期6周的迭代开发，团队小伙伴的不懈努力、研发经理的不断施压；项目最终按时完结，回归测试经验总结

1、如何实现测试左移

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

· 先行接口测试浪费时间

· 重视数据库测试任务 
由于我一个测试，使每个程序猿手头都有缺陷要处理；

· 对优先级较高的任务进行第二轮全功能覆盖测试，发现新的缺陷，绝对不能让研发空闲

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

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

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

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

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

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

· 页面缺陷，集中反馈，提供截图说明 ；

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

· 面对面沟通，主动重现解释bug；

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

· bug及时跟进：及时验证、及时反馈、及时关闭；

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

例如：

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

· 整体上理解，再具体到功能的细节，有问题就问开发，想到的用例设计场景，没答案的和开发或产品经理等讨论确定。

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

每一轮测试后，需要有· 原有的测试的原有计划

例如：

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

但是如果到了9.1日，开发根本无法提交给我，或者提交的没达到我们的可测标准被退回去了，等到9月中才再次提交，那我测试人员的原因了。

但是如果是开发9.1日按计划，提交了可测的代码，冒烟测试接收了，但是到了10月中，由于测试没进行完，给不出结果，这就是测试自己导致的，要反思和下次改进。

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

· 测试人员，一定要知道整个测试的责任是什么，我们首先做好自己的，再推动其他的

然后就是业务了，基于对业务的理解去设计测试自己能做的，积极推动其他的，用数据说话，别拍脑袋，就可以了

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