测试人员如何做好有效的pdca

      入职以来做的测试执行较多（这里主要是从角色上和项目管理分开，包含测试设计测试分析），现在就谈谈作为一个测试执行人员对如何做好pdca的看法。

       我们的团队，软件测试的终极目标是“快速发布高质量的版本”，那我就从进度和效率方面谈谈如何做好pdca。

效率：假如你拿到一份任务是满足smart原则，那么做好pdca的关键就是让项目经理及时了解你的进度，避免进度方面出现风险。做法：a.每天评估自己的工作进度，并知会项目经理(方式可通过日报或者更新projectserver等) b.当负责的任务进度有风险时要及时提出。必须要保证及时！举一个例子，假如你拿到一份任务，需要3天完成，1天下来你才完成了5%~10%，进度其实已经有很大的风险了，这时候就要提出来，不能到2天后发现自己才完成40%无非完成任务才提出，这时候就晚了，PM一般允许工作有风险，但是必须让PM及时的了解风险便于做出相应的对策。

质量：质量和进度其实是相辅相成的，如果一味地赶进度，质量不能保证，后续项目出现返工，项目周期还是会被拉长的。我们负责一个模块的测试，就要保证质量，但是PM审计和外部PMO审计还是会有问题，为什么？主要有2方面：a.我们的例行工作没有做到位  2.我们的风险识别，闭环意识不好。

例行工作：这主要是流程方面的一些工作，如failed案例标注bug id，bug属性标注正确，bug 回归通过后要passed相应案例等，这些工作是无需项目经理再去提醒的，我们完全可以自己制定一份例行工作checklist，经常去关注并确认。这里也有一个技巧，PM和PMO经常做的检视工作也可以加到我们自己的checklist中，如bug审核，缺陷预防库检视等。

风险识别，闭环：闭环是因为当前发现了问题，所以要针对当前的风险做闭环处理。。举一个例子，我们发现了一个回归不充分导致的bug，原因是bug没有审核。那么我们要分析是否还有其他bug存在此问题，这时候我们可以先自检下是否存在类似的共性问题 并知会项目经理对bug做2次审核。我在某个版本发现了测试策略漏测（测试策略是让开发保证质量）的bug，那这种问题的原因是测试策略问题，那么要分析是否有其他模块是否采用类似的测试策略。简而言之，就是点到面的分析。点到面的分析可以采用如下策略：

分析出问题的点（确认出问题的对象，如某个案例，bug，测试策略，测试方法等）--->确认点的最终原因（如案例没有做checklist自检，bug没有审核等）--->确认是否是共性问题--->分析other类似对象是否存在此问题--->落实。通过反复的点到面的分析，确认风险最终落地。


      上面说的是确保自己发现的问题的最终闭环，但是很可能可能会存在其他自己不能识别的风险，那该如何办？

我的想法是，我们最终负责的东西需要经过PM和PMO的审核，那我们可以采用利用他们的经验帮助我们。如现在PMO用的项目缺陷预防检视库，我们可以在确保负责的模块点到面分析自检完成后，利用缺陷预防检视库 检视自己的模块是否存在风险库的问题。这个也是工作的1个基本的思想，因为PM和PMO是我们负责模块质量的干系人，我们负责的东西肯定需要满足干系人的标准。

      综合上面分析，做好pdca需要做好基本例行工作，问题的点到面分析，借助干系人的经验等。做好pdca既保证了自己负责工作到位，也实现了测试人员的自由（否则项目经理经常会找你，工作会返工的 呵呵）


附录上我发现的pdca的不好的情况及自己的改进建议。

1.例行工作不到位：产出自己的例行工作checklist

2.工作标准不明确：有时候PM安排一份任务没有明确标准，有时候会发生PM向你要某份分析文档你却没有。建议PM和项目成员对每一份任务要明确相应的产出标准，尤其是对新员工（刚入职或者刚接触某个新工作的员工，即便是老员工）。

3.文档思路不到位：这个其实和第2点一样，不过这个很常见且很重要（我自己身上也发生过）。其实负责的模块质量分析一般包含你的测试策略 已测试点  测试结论，pdca无非是确保当前的风险被消除，所以你的数据已经要支持风险消除的结论。分析文档最好按照测试策略（测试分析），已测试点，点到面分析，测试结论思路来写。

4.pdca过度：有时候PM可能分析某个问题有点过度，本来可能是个性问题但是分析成了共性问题，其实这往往是问题的根本原因没有分析到位。这时候如果你想懒一点（不想测试太多内容），就要给出有力的数据支持说明这个只是个性问题。

5.不能尽早识别风险：这个取决于部分的经验，但是风险意识必须有。不过可以学习下风险库，学习下其他项目遇到的问题等