锻造tester&coder的无缝合作理想

从一张表的索引想到的

        我们有一张保单基础信息表pol_main，大约有500万条记录，算是一张中等数量级的表，它关系着大量的保险业务操作和相关查询功能。这张表的pol_sts（保单状态）字段的cardinality（基数）是26，这个字段上有个独立的索引；另外一个常用的查询字段plan_code（险种代码）的cardinality在1000以上，并且在逐年随着新业务模式的出现而增长，该字段无索引。参照这两个字段，数据都是非正态的不均匀分布，而且这两个字段都是非常频繁的被查询语句用到。无论是从selectivity还是cardinality的角度考虑，在plan_code上建索引都要比pol_sts好，但是为什么没有这样做呢？我曾就这点疑问咨询过资深的开发工程师和数据库架构师，他们的观点是一致的：pol_sts字段上有索引是因为最初在做表结构设计的时候就做了，而当时没有考虑plan_code这个字段，估计当时在售险种只有几个吧；而现在不在plan_code上建立索引，主要是因为这个表、这个字段被引用得太多，没人能够评估得清楚这样做的风险有多大。

        要么删除pol_sts字段上的索引，要么建立plan_code字段的索引，最不济就是建立这俩字段的组合索引，看起来很简单的事情，实际操作起来却有着这么多的顾虑，为什么？因为没人愿意去挑战系统运营的稳定性，拿这个做赌注付出的代价的确是很大的。对于他们的担忧，其实我解读出来的信息就是：

1、 对软件测试的质量保证作用信心不足，不论是开发自己做还是测试部门去做；

2、 测试的成本太高，为了一个性能的优化，要牵动十几个人去测试，换来的质量提升很有限，换句话说，可能是测试的手段不够经济、不够高明导致了整个行为的ROI不高；

3、 总之，没有好的质量守护，没有好的软件测试，开发不敢轻易修改他们认为软件中敏感的地方。

        既然coder对自己开发质量的衡量如此依赖testing（注意：不是tester），那么他们是否为testing创建了足够好的环境呢？未必！再举个例子，我们公司的应用绝大多数是javascript/html+java+oracle这么三层。大部分人都知道SP代码易发布但是相对于Java代码来说，测试更麻烦一些；反之Java代码的发布都要走中间件的部署，需要起、停应用服务，看起来会让系统服务不连续，但是测试更加简单。而我们因为有固定的版本发布计划，所以SP代码在发布上的优势其实已经不明显了，但是大家还是热衷于写一些逻辑复杂的、相互调用繁多的SP代码来实现我们的业务需求，这是为什么呢？

        刚毕业那会，很幸运在神码融信的东亚银行核心项目做QTP的自动化测试试点和推广工作，真可谓是不舍昼夜的忙碌。早在那个时候，我就梦想着开发如果能够就一定可以建立标准的UI组件库，实现标准的拖拽式开发，不会随意命名一些组件；这样自动化脚本开发和维护就非常方便，很容易追得上甚至超过编码的进度。可惜这对我来说只是一个梦想，从未被实现，现如今在带领大家一起做Selenium/ WebDriver和WatiJ等工具的自动化测试脚本开发同样面临这种问题。很多页面组件没有id、name，coder们在修改的时候变动随意性也很大，实现方式五花八门，这样测试脚本的维护工作量也是非常大的，经常因为人力和工作量的比例不协调导致测试脚本维护不及时，运行稳定性不好。这样就意味着测试的投入需要增加而质量却不高，自动化的ROI呈指数曲线下降。有同事说：“测试自动化没有开发的帮忙就等于是测试自己在YY”。虽然有点夸张，但是意思很简单：如果coder如果故意不配合的话，自动化测试的确会因为可测性遭遇很多测试脚本开发技术实现上的问题，所以说低质量的应用代码能锻炼出自动化测试开发高手来，但是伴随着这种锻炼方法的是可耻的资源浪费。高智商的coder们想不清这么简单的问题么？当然不是，那他们为什么没有提供更具可测性的代码给tester呢？

        反过来tester对coder处境的考虑也是一样不够的，例如，很多tester不考虑coder的工作量，死硬地按照流程规范要求coder首次必须移交所有的SRS，拒绝增量迭代开发和移交；这样其实也是在逼迫coder们权衡之后移交一堆不可测的代码过来。再例如，tester只顾埋头想自己的测试设计和执行，不愿意主动帮助coder想设计和实现的方法，认为这不是自己的本职工作或者认为自己不具备这个“资格”去对coder的工作指指点点。高智商的tester们难道不知道自己这些不合理、不积极的做法最终会给自己带来更大的麻烦、更大的工作量么？他们应该知道，但是他们为什么没有采取更好的办法呢？

Coder和Tester的渊源

        接上文，我能想到的原因很简单：因为负责coding的和负责testing的不是同一群人，所以往往由于他们专心于“本职工作”而忽视了对对方工作进行深入的思考，他们忽视的是对自己造成什么样的间接影响，最终忽视的是自己交付给客户的代码的质量，也是自己的口碑。即便他们中有些人偶尔能想到这些，替对方多考虑一些，他们也无法打败流程的约束和更简单实用的诱惑，换句话说：选择短视，选择当下可见的便利；选择无条件服从流程规范，选择拒绝持续改进。

        把一个人的“本职工作”变成了多个人的“本职工作”，用流程来约束势必造成这些现象的出现，但既然coding和testing不由同一拨人负责已成既定事实，那么很明显，coding和testing的合作变成了coder和tester的合作了。我把二者的合作关系和渊源分成5个层次，仅供参考：

1、 原始模式——没有专职测试人员，没什么可以讨论的；

2、 相互指责——我能想到的关键字是权力制衡与推诿或过分干涉，常看到这种现象，抱怨的帖子满天飞；那些自以为善于“权术”的管理者也很喜欢利用coder和tester的冲突和相互推诿去做所谓的“制衡”，相信这种管理者会渐渐退出IT的舞台，不过这种相互指责的现象貌似短时间内还不会那么快消失。

3、 相安无事——我能想到的关键字是既定流程下责任共担与成果共享，我个人感觉这是我们公司现有的一种常态，彼此照章办事，无过多思考和改进意识；即便彼此心里对对方有更多期待也不便明说，总觉得干涉对方的工作很不礼貌。在我看来，这是虚假的尊重，却是真正的安于现状和不思上进的代名词。

4、 相互倚重——我能想到的关键字是质量守护和可测性保证，表现在积极的互动和沟通：乐于相互尊重但决不因为害怕冲突而不提出自己的意见；懂得换位思考但决不迁就对方短视或者不经济、不科学的行为。coder要实现一个重构或者系统改造，他们可以依赖测试的质量保证和守护作用；tester要更快更简单的测试也可以要求coder使用更合理易测的实现方式，在哲学上叫相互独立而相辅相成。

5、 分久必合——我能想到的关键字是当下流行的持续集成和敏捷开发，大神们都在论证在今后的敏捷开发模式下，专职的测试人员会不会消失的问题。在我看来，正如上文所述，二者相互换位思考不足或者不深入导致二者合作不能更加“无缝”和高效，所以长久看来合是必须的，至少这是一种需求，而不是一种来自对客观形势的判断。但是我能理解的只是一种组织结构的变化而已，我的观点可以归纳为三点：

a)    软件开发过程中的testing工作永远不会消失；

b)    专职的tester不会消失，至少在敏捷开发中不会消失，但以后的新技术和新理念本人无法预测，所以不敢说永远二字；

c)     专职的tester合入开发部门，不再与coder相互独立，而是可角色互换：tester从测试设计角度给coder提供更多意见和要求；tester亦可转换角色为coder，由其他的tester或者coder转换角色来做testing，须知“专职”和“全职”是不同的概念，如有异议，我们再讨论；

        由于经历有限，所以我无法论证上面这5个层次是否需要逐步发展，也不知道从2或3直接跳入5会不会达到预期的效果，不过个人主观倾向于排斥这种做法，因为我认为双方在不具备主观能动性的情况下用什么模式去工作，结果都是一样的。

2012/10/9     刘毅       平安科技上海张江职场