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