一个案例引发的思考
今天下午，团队开了一个简短的版本总结会。会上测试经理分析了一个案例：某子程序在转测试后发现不能被平台调度，原因是子程序的调度入口跟不符合平台规范。很明显开发在转测试前没有充分自验证，测试经理提出，后续对跟平台对接的子程序转测试必须要有将子程序接入平台跑通后的验证报告和相关checklist，否则不予转测试！然后大家开始讨论，主要观点大致如下：
1、测试的兄弟认为从提升质量出发，开发应该充分验证，对每个子程序，都应该跟平台充分调试，并输出调试报告作为转测试入口条件。降低转测后发现低级问题，导致重新测试，浪费测试人力。
2、开发的兄弟认为，通常大部分需求实现都是对已有子程序的功能做优化升级，子程序跟平台之间的接口一般不会修改，而子程序的功能是可以脱离平台进行验证和测试的，如果要求每次子程序优化后转测试都输出跟平台调试的报告，必然增加开发人力投入，这也是一种资源浪费。
从开发和测试两个角色来说，矛盾点主要在于：质量和资源(人力)投入，大家都希望少投入，但把事情做好（质量高）。团队一直强调基于角色和流程开展工作，开发和测试之间定义了标准交付件（如自验证报告，代码检视报告等），因此测试很自然地想到在角色之间的交付件中增加一个跟平台的调试报告来拦截开发问题流入测试。基于流程规范来解决问题的思路应该来说没有问题，但这也仅仅是头痛医头脚痛医脚的办法，如果问题都这么解决，那么下一次出现另外一个问题，再增加一个转测试交付件（并且这个交付件真正能起到拦截问题的作用还很小），这样机械式执行，开发人力浪费无疑非常大，作为项目经理，希望用最少的开发和测试人力，交付高质量的产品，这当然不是上上策。那么如何避免开发的低级错误流入测试从而导致测试人力的浪费呢？从本文前面描述的问题可以抽象出问题的特性：
1、子程序包含功能和接口，而开发通常关注于功能验证，接口因为涉及到其他平台或者子程序，被忽略了。
2、开发粗心，或者意识不到位，导致没有验证到接口
那么这类问题如何避免呢?开发在转测试前必须保障交付的子程序的功能和接口的正确性是不可更改的，那么是否一定要输出调试报告等交付件呢，个人觉得只需要一个checklist即可（即：开发在转测试前，只需要在checklist上签字画押，表示该子程序基于xxx平台调试通过，如果不涉及，即写明无需跟任何平台调试并说明原因）即可转测试，即如果子程序涉及跟平台联调，那么联调必须执行，但无需输出报告。有人会担心了，万一需要联调的子程序，开发人员明明没有联调却在checklist上注明调试通过怎么办，问题还是要流入测试，其实这个问题可用考核来解决，将质量和个人绩效挂钩，转测试不通过计入开发质量关键事件，作为绩效考核输入，很多时候，只要有这一条，无需在流程中增加很多交付件，各个角色会自己想办法提升交付件的质量的，项目管理，甚至团队管理不应该将每个人都塑造成一个模式的，大家基于一个大的流程和规范，在流程规范内保持适当的灵活性（个性），所谓八仙过海各显神通，我们不必要求所有人都像何仙姑那样使用莲花过海。
以上记录比较仓促，观点不一定正确，如有不同看法，欢迎留言。
