项目管理经验漫谈：作为测试项目负责人，这些年我的所见所得

正文

请到「今天看啥」查看全文

不同的小组虽然主要负责的模块不同，但会要求全体成员对项目都有基本的了解，版本后期的交叉测试都会要求小组间互相交叉测试，以确保对新增特性有一定的了解。 每次版本结束后的分享总结会上，也会有分享当期版本的重点需求，以确保全体成员都能对每个版本新增的重点需求有较好的掌握。

任务跟进

进入迭代周期后，项目负责人确定当期迭代需要完成的需求列表，并梳理需求的优先级，开发负责人确定各需求的开发时长后，测试负责人与开发负责人沟通确定各需求开发计划（开发启动时间、开发结束时间），确定本次迭代的提测批次和各个批次的提测时间点，进而确定测试排期，评估各个需求的预计测试时间后，完成测试计划的制定，发送测试计划。

测试计划一旦确定，开发、设计、测试均按照此时间点执行，在预定的提测时间点完成相关需求的开发、自测后，由开发负责人负责当前批次所有需求的提测，此部分需求转入测试周期。 我们会有一套完整的标准，来衡量已提测的需求是否符合提测标准，对不符合提测标准的需求进行打回，并对此情况做以审计备案。

测试周期，我们会按照计划完成测试的执行。 在此过程中，我们会每日早上输出当前迭代的状态，包括各需求的提测状态，是否存在延期，已经提交的需求的测试进度，当前版本的缺陷状态和缺陷分布，以及版本流程中存在的风险等。

风险控制

这里所说的风险，主要包括因开发提交测试延期造成的风险，因开发质量不好给测试进度可能带来的风险，因产品体验、需求变更等造成的风险，因与第三方相配合（接口支持、页面支持等）存在进度不可控可能存在的风险，因人力不稳定（偶尔存在人力临时借调）可能存在的风险等。

对于这些风险，我们归纳为两大类，一类是团队内部可以控制的风险，对于此类风险，我们可以通过团队内部的沟通协调实现较好的控制； 另一类是与外部团队相关不太可控的风险，针对此类风险，我们就需要通过一些制度约束、风险预警等来实现风险等提前预知和把控。

针对风险预警，我们建立了一套风险预警体系，像天气预报中的预警体系一样有不同的等级，而不同的等级对应的处理方案也不尽相同，知会到的相关人员也不同。 随着等级的提升，相关处理方式也随之提升，有效保证风险的可控性。

过程改进

请到「今天看啥」查看全文