只有将我们自已做得更好!

W经理所负责的项目送测准点率出了问题，项目经理解释如下：

经过跟测试部了解，测试部判断准点率的依据有两点：

1.       送测的程序是否部署成功

2.       送测单是否发出 （这需要部署成功后发出才有效）

 

造成这次准点率问题的原因：

周四程序是按时部署，但只是部分部署成功，整个过程虽然测试部有人员参与，但没有及时通知到测试部门经理部署状况如何。

周五我们部署人员有其他事情，没有进行进一步处理部署遗留的问题，但测试部人员已经在测试部署成功的部分，此情况也是没有

及时通知到测试部经理，这个原因主要是我这边没有及时发出部分部署成功的测试单（之前以为测试单是可以后面补发的）。

周一我们部署人员对遗留问题进行了处理，我这边也才将测试单补发出去。测试部就以测试单发出时间计算准点率。

 

总结我们这边的问题：

1.       误认为虽然不是全部部署成功，但也算是送测成功。

2.       误认为测试单是可以后面补发

3.       对送测工作出现问题，处理的不够好，原因是对测试部的规章制度了解不够充分。

 

吃一蜇长一智，我们这边会再一次跟测试部了解测试的规章制度，以免后面继续发生问题。

 我对测试负责人进行了解后，测试负责人回复如下：

程序是星期四部署的，部署后我做了可接受性测试，发现待送测模块的主要功能无法测试，只有小部分可测试（版本未部署成功），这种情况跟XX沟通过，他说星期五过来处理，但星期五他有其它事情未能过来处理，直到星期一上午才把测试环境完全调好。此过程项目组一直未发“送测单”，测试部的送测依据是以接收到送测单为准，没有送测单不知具体送测哪些内容，送版本号、注意事项等。这个过程中也有催过项目经理发送测单。

       此项目刚开始送测时就有跟项目经理介绍过测试部测试流程，并提醒过送测单的总要性。介于项目组对于流程制度的不了解，计划安排一次培训交流会明确测试流程和制度。

至此我认为测试负责人是有做得不够的地方，但主要过错在于开发部门，事后跟技术总监交流时，总监认为解决这件事情的方法不对。至少测试部的做法是有漏洞也会给人造成误解的，回去跟过细想后，的确，解决问题的角度有问题，犯了本位主义错误，没有想过我们的做法的确会给项目组人员带来误解和疑惑。

 

所以针对此次问题我们内部进行了如下改进：

１．可按受性测试不成功需要发明确的邮件通知。

２．测试日报不只是记录测试执行过程的报告，有进行项目的相关活动也应该发相应的报告，例如部署，问题单重现等．

３．送测试不成功时应该明确通知相关涉众（项目经理，开发部部门经理，测试部经理）, 送测成功后发邮件通知相关涉众

４．送测时间到达，但项目组未有明确的邮件通知时，应该发邮件给涉众告知相关人员

５．制度执行力度的问题．

６．对项目组进行培训，告知容易出问题的点