showcase，开发中必须引起重视的小环节

有人说，测试者来自火星，开发者来自金星。这是因为软件测试员和软件开发者就好比一对冤家，里面的缘由说不清也道不明。开发代表着创造，而测试则代表着摧毁，因为测试的目的就是以各种方式不断地从开发出的产品中发现大大小小的Bug，长此以往，开发者认为测试者是在故意找茬，两者的矛盾慢慢就会产生。

    敏捷之前项目中也有开发和测试，就如上文所说矛盾不少，比如测试测出一个bug，提单给开发，开发看了觉得这不是一个bug，实际业务过程中根本不会有这样的操作方法。还有测试提了一个问题单，开发在下面回复已解决，测试回归问题单的时候发现这个问题还存在，就质问开发这个问题没有解决还存在，开发肯定会说这个问题我已经解决了，是不是你的程序版本不对，重新构建一次，测试重新获取最新程序还是如此，开发因为任务重，同一个问题老是提过来肯定就会觉得烦，这样来几次就有可能吵起来。反正到最后开发觉得测试能力不行就只会找茬，真正的问题没有测出来，尽纠结一些无关重要的问题。而测试觉得开发的功能质量不行，不支持他们的工作。

以前并没有独立的产品经理来写需求，一般都是开发人员兼写需求，然后给测试人员测，当出现需求方面的理解不一致的问题，肯定都是开发人员更有理，就算测试人员找到几个不合理的需求，开发人员通常也不会虚心接受，反而觉得是在找自己的茬。所以在团队中独立出来产品经理负责所有需求是很有必要的，这样产品经理、开发、测试三者之间形成三足鼎立是比较好的局面。

一般来说测试人员都不会自己从SVN下载代码编译生成程序，然后进行测试。而是开发人员把编译好的程序和升级的数据库脚本拷贝到服务器的公共文件夹，然后测试人员再从服务器拷贝下来，数据库脚本在测试库上执行，经常会出现开发人员漏拷程序文件和数据库脚本，这样测试的结果肯定失败，然后开发找了半天原因发现只是漏了某个程序文件，然后就再循环一次。如此方式双方协作的效率很低，浪费了大量时间。

还有就是开发在完成功能后，并没有仔细进行自验证，只要代码编译通过了，一些明显错误没有修正就丢给测试去进行测试，那测试随便点两下系统就走不通了，只好打回给开发，一个需求测试用例跑完得反反复复好几次。

所以开发与测试之间要想好好协作，得双方需求理解一致、运行程序一致、运行环境一致、数据库一致，还要解决测试人员获取测试版本的方便性。

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

运行程序、运行环境、数据库保持一致，这个靠手工的方式是很难不出错的，最好是通过一些工具来保障。我们团队是使用Jenkins来做持续构建，开发人员完成功能开发，然后提交代码到SVN，Jenkins检测到代码库变动，自动拉取最新代码进行编译构建、发布程序，测试数据库也自动还原成与开发数据库一致。

我们团队ShowCase的具体过程是这样的，开发完成功能提交代码后就通知测试进行ShowCase，这样时候持续构建已经生成了最新的环境，然后开发在测试环境上向测试人员进行功能展示，开发会按照需求把自己开发的功能都详细演示一遍，如果演示顺利通过测试人员则回到座位进行用例执行，如果演示没通过开发人员则继续修改代码完善直到演示通过为止。为什么开发一定要在测试环境上进行ShowCase，因为如果开发人员用自己的代码进行演示的话，还是有可能会出现代码效果与自动构建的程序不一致，所以为了避免这种情况，开发最好是在测试环境上进行演示。同样测试执行用例后产生的BUG，测试会提问题单，问题单要有详细的操作步骤与界面截图，然后开发人员解决BUG后要对此BUG进行根因分析，是代码逻辑错误还是需求理解问题，方便以后对BUG进行分析。BUG解决完后打回给测试的时候，开发也要进行ShowCase。

总之，现在觉得团队中开发和测试之间的关系还比较好，协作也很流畅，现在看来确实还是方法不对，虽然知道问题的原因但苦于找不到对症下药的办法，如果你的团队中也有类似情况可尝试一下ShowCase这个方法也好。

敏捷开发系列文章目录