【项⽬】Showcase的重要性
⼀对⼩‘冤家’。有⼈说，测试者来⾃⽕星，开发者来⾃⾦星。这是因为软件测试员和软件开发者就好⽐⼀对冤家，⾥⾯的缘由说不清也道不
⼀对⼩‘冤家’。showcase
明。开发代表着创造，⽽测试则代表着摧毁，因为测试的⽬的就是以各种⽅式不断地从开发出的产品中发现⼤⼤⼩⼩的Bug，长此以往，开发者认为测试者是在故意茬，两者的⽭盾慢慢就会产⽣。
" 相杀 "
⽭盾解决。为了减少⽭盾、保障开发和测试对需求理解⼀致，我们在敏捷过程中通过计划会、需求讨论会、开发前需求澄清会、测试⽤例评审和⽭盾解决。
开发ShowCase这⼏个关键活动保障。计划会中产品经理讲解需求，开发和测试都会参加，如果需求理解不⼀致的地⽅就马上沟通由项⽬经理或产品经理把关。到测试⽤例评审的时候，需求细化成⼀个个测试⽤例，这样让开发和测试进⼀步深化理解需求达成⼀致。到开发完成功能给测试Showcase，测试再⼀次核对开发实现功能与需求是否⼀致，明显不⼀致的地⽅当场指出来，等开发⼈员修正后才提交给测试进⾏测试，这样就基本能保证测试⼀次性就能跑完这个需求的所有测试⽤例。
协作
优化的ShowCase过程。完成功能提交代码后，这样时候持续构建已经⽣成了最新的环境，然后开发在 “测试环境” 上对照LLT⽤例进⾏冒烟优化的ShowCase过程
测试，并标记冒烟基线⾃验结果，作为转测交付件。冒烟测试通过后对产品、UI 、测试等⼈员进⾏ShowCase，向⼤家进⾏业务和功能展⽰，⽬的是完成“正确的做事”，让⼤家对研发的成果进⾏double check , 需求实现达成⼀致意见。如果演⽰顺利通过则项⽬经理按照转测标准发转测邮件，测试⼈员则回到座位进⾏⽤例执⾏。如果演⽰没通过开发⼈员则继续修改代码完善直到演⽰通过为⽌。
为什么开发⼀定要在测试环境上进⾏ShowCase，因为如果开发⼈员⽤⾃⼰的代码进⾏演⽰的话，还是有可能会出现代码效果与⾃动构建的程序不⼀致，所以为了避免这种情况，开发最好是在测试环境上进⾏演⽰。BUG解决完后打回给测试的时候，建议开发也要进⾏F2F⼩型的ShowCase。
ShowCase
综合，解决歧义的⽅法为：
对于开发⼈员：编码前进⾏需求澄清、编码后进⾏showcase、showcase问题修改代码后再showcase、问题单解决后进⾏showcase通过后对于开发⼈员
把问题单⾛给测试；
对于测试⼈员
对于测试⼈员：对测试⽤例进⾏评审、提单前和开发确认、问题单打回前和开发确认；
“ 相爱  ”