ShowCase—提升开发质量，解放测试压力的利器

ShowCase，第一次听到这个词，还特意去百度了下，却没找到合适的解释。后来同事在会议中继续说，“这个是腾讯公司常用的一个控制点，我们公司当前似乎也合适引入。”
我饶有兴致的听着，才知道，很早之前，在QQMail产品开发过程中有一个要求，就是开发人员和测试人员，在完成一个大的需求/迭代后，要把相关的项目经理、产品经理、开发人员、测试人员都组织在一起，一起演示下这个产品功能目前开发到什么程度了，是否符合产品经理设计的需求方案，是否满足用户的诉求，是否主流程跑通满足提测条件了。

后来，在项目中，我尝试引入这个流程，也逐渐发现这个控制点，有一个极妙的地方，就是开发同事以一己之力，和测试同事和产品同事的扯皮次数，终于减少了。。。

作为一个项目经理，慢慢体会到了ShowCase更多的妙处，比如需求交付的质量提升了，产品和用户验收通过的概率提升了，项目交付的可控性提升了

ShowCase的两大功能：

1、解决研发与各侧矛盾，提升需求准确性。

• 为了减少矛盾、保障开发和测试对需求理解一致，我们在项目过程中会通过计划会、需求讨论会、开发前需求澄清会、测试用例评审等等这些关键活动保障，那么ShowCase也是一个很关键的控制点。
• 计划会中产品经理讲解需求，开发和测试都会参加，如果需求理解不一致的地方就马上沟通由项目经理或产品经理把关。
• 到测试用例评审的时候，需求细化成一个个测试用例，这样让开发和测试进一步深化理解需求达成一致。
• 到开发完成功能给测试ShowCase，测试再一次核对开发实现功能与需求是否一致，明显不一致的地方当场指出来，等开发人员修正后才提交给测试进行测试，这样就基本能保证测试一次性就能跑完这个需求的所有测试用例。

2、提升开发质量，保障测试工作的顺利接入。

• ShowCase演示过程，原则上要求在测试环境中进行。一方面，开发将功能部署到 “测试环境” 上，需先对照用例进行冒烟测试，并标记自测结果，作为转测交付件。等自测通过后，再开展ShowCase会议，对产品、UI 、测试等人员进行业务和功能展示，目的是完成“正确的做事”，让大家对研发的成果进行double check , 需求实现达成一致意见。
• 如果演示顺利通过则项目经理按照转测标准发转测邮件，测试人员则回到座位进行用例执行。如果演示没通过开发人员则继续修改代码完善直到演示通过为止。
• 为什么开发一定要在测试环境上进行ShowCase，因为如果开发人员用自己的代码进行演示的话，还是有可能会出现代码效果与自动构建的程序不一致，所以为了避免这种情况，开发最好是在测试环境上进行演示。BUG解决完后打回给测试的时候，建议开发也要进行小型的ShowCase。

经过多次的磨合，我也开始逐步调整这个ShowCase的会议安排，我发现一套很好的操作方案：
1、会议时间：在研发后期，提前跟研发负责人确定showcase会议具体时间。一般ShowCase安排在转测前1-2个工作日比较合适（需跟研发负责人确认可保证主流程研发完毕，基本可跑通；开发需完成自测），安排在16点前结束会议最佳，留足2小时用于有争议的功能点可再次沟通。一般会议可能需持续1-2小时。
2、会议过程：前端同学负责投屏演示，每个功能点应尽量都点击演示一遍；后端同学负责紧急修复现场演示中卡住主流程的问题，或者提供测试数据等；测试同学负责记录自己发现的BUG或者争论点；产品同学负责解释有争论的需求点设计意图；项目经理负责控制会议议程，同时判断此次ShowCase是否通过+是否可转测。