产品经理为什么要认真对待测试工作

写在前面：我为什么要转载这篇文章？因为刚入职的时候，接了一个改动较大的需求，结果开发两周，测试周期长达两个月，也是醉了。事后总结，一个重要的原因就是没有认真对待测试用例评审这件事情，导致测试测到哪里算哪里，每次要上线的时候都会发现bug，搞得大家都加班，还特别累。

下面是我目前安排测试的一个流程：

1、首先，讨论需求，出技术方案的时候，如果有必要可以叫上测试工程师一起参与；

2、在开发进行的同时：

      （1）给测试工程师做需求宣讲，先讲业务逻辑，再讲技术方案，然后讲页面上的一些显示逻辑和计算方法；强调测试用例需要覆盖哪些方面，指导测试方法；

      （2）让测试按照规范的格式撰写测试用例，尽量要描述具体；

      （3）自己先审核测试用例，提出修改建议，与测试讨论，确定测试用例文档；

      （4）对于比较大的项目，安排测试用例评审，让开发、测试、PM一起参加。

      （5）大的项目，如果能分步提测，建议分步提测；

      （6）在测试过程中，自己也参与测试，看一下产品是否符合自己的预期。

下面是转发的一个文章，讲的是安排测试用例评审的原因。

无论是初级测试工程师，还是高级的，专家级的，设计出来的测试用例都需要经过评审。

　　原因一：设计完成的测试用例要分配给每个人来设计具体数据，并实现自动测试。设计用例和实现用例、执行用例并非一人完成。设计用例的人并不知道用例在具体执行的时候是否有问题，或者哪些步骤不能实现自动测试。再者“测试是无穷尽的”，谁又能保证自己设计的用例能覆盖完全？

　　原因二：测试人员总是抱怨测试出来Bug后与开发扯皮太多，主要的原因之一是测试人员和开发人员对于被测试功能的理解未达成一致。因此用例需要提交给开发人员check，并在测试开始之前对于测试目标的功能需求理解达成一致。用例一般比需求文档更加具体，能更好的体现具体测试思路。如果在测试开始之前就提前和开发达成一致，那么在你发现争议的bug的时候，就不用费劲解释了，可以直接告诉他“用例评审的时候已经确认是这样了。”

　　原因三：让需求人员参与评审，她们能帮助你找出更多的问题。经常在测试的时候，有些细节是无法送需求文档上得知的，需要频繁来和需求人员沟通，问东问西，如果他们在忙，也许会产生这样的心理“怎么连这个也不知道？”我们测试人员多委屈，吃苦不讨好。所以在评审的时候让需求人员明亮的眼睛多帮我们找出问题，解决疑问。

　　原因四：设计完成用例至少要让Leader评审下，让她理解你的思路，如果有问题也及早提出。不然当你测试的模块出现问题的时候，Leader绝不会说都怪她当时没review你的用例，责任还是在你身上。

　　原因五：现在有很多人是项目外包或人员外包，那么完成每一项工作的第一件事就是提交客户评审，当然在提交给客户前自己team先评审下最好，确保提交给客户高质量的成功。

　　原因六：如果严格按照用例数量来计算工作量，真正测试A模块需要200个用例，一周的时间，可是你却由于某些误差设计出100个case，那么评估出来3天的工作量，那么你就等着加班吐血吧。

出处：http://www.51testing.com/html/54/n-810854.html