在一家公司担任PM，顺便做了测试（顺便也做了运营、策划和QA）。
出产品文档的时候RD与BOSS表示需要产品做测试，目的是验收产品，以通过率判断产品是否合格。
无相关测试经验，只好边查资料边上，整理撰写了一份厚厚的测试用例。
到了开发约定的期限开始了测试，最后CTO却不认账，表示-我们RD测试的结果不是这样的，只好与CTO对着文档与测试用例一条条的过，最后测试结果依旧不如人意，虽然勉强达到了当初设定的通过率，但是基本流程没跑通。
这次测试，出现如下几个问题：
1、产品基于开发交稿日测试，而RD基于出测试报告那天测试。
由于测试时间不同，测试结果自然不同。产品测试应当以RD交付日/约定日/开发完成日测试，测试必须基于一个完整的版本，边开发边测试永远无法出具产品测试，产品测试属于黑盒测试，盒子里的东西不断变更，永远无法输出一个正确结果。
2、基于百分比判断产品通过率。
产品通过率对于测试结果而言没有任何帮助。通过率过高可能是由于文案或小提示错误，也可能是一个BUG带来的连锁错误。通过率低也不代表测试没BUG，基本流程没跑通，谈什么通过测试？
测试的结果应该是流程完整性，BUG频率，用例完整性的综合性结果。是否通过测试要根据产品整体的预期、希望达到的效果、可以接受的BUG量来决定.
3、测试结果的跟踪反馈。
测试结果出来了，RD没跟上节奏修正怎么办？RD修正了没及时通知测试怎么办？产品出具了测试报告如何确保RD确认并修复中？
关于测试结果的跟踪，上一家公司使用的是Tower在线把问题列出来，现在使用的是mantis，内网服务期内提交BUG，然后RD根据mantis上的BUG描述修正相关BUG，完成了打个勾/开发有问题留言/产品流程有问题直接找产品或留言。在线工具的好处在于避免了产品天天跟着开发转，追问这个做好了没/BUG确认了吗这类问题。对于RD而言也可以根据自身工作计划安排修复BUG的时间。
题外话
工作与生活中都会遇到形形色色的人，这是一件很有趣的事。
无法预料到遇见的人会在什么时候坑你一把，就像无法预见相恋多年的恋人说走就走。
也会有相识不久却似多年好友，可以把酒言欢，共醉一榻。
还有初见就分享你手上的重担，争取各种资源共度难关的大牛。
打不倒你的都会让你更加强大。
共勉。
晚安！
网友评论