测试&开发 谁坑了谁？

      测试与开放本来都是软件工程中必不可少的常见工作， 个人认为并没有严格的界限来划分测试与开发。 虽然在全球大分工工作环境下，流水线式生产几乎随处可见，然而Agile式开发的兴起恰恰反驳了所谓的大分工协作。 流水线式生产的优点在于利用重复劳动提高劳动回报率， 降低对人员素质的要求。 然而弊端也是显而易见的， 应变需求能力弱（一有改动整条流水线都要跟着应变）， 信息沟通困难（上下分层太多，职能过于分散，且大部分流水线工人只能理解他们做的那一块的意图，对于其他改进得良苦用心难以理解）。 个人认为最大的弊端在于严重扼杀成员的创造性， 这种行为与把人当机器使无异。 如果以开发优质软件为Team Target 的话， 就不该有没有测试意识的开发抑或完全不懂开发的测试存在， 只应该有软件工程师一职， 只是工作侧重不同而已。
    然而国内的IT环境却是这副模样， 测试变态地找着各种corner case的bug，根本不管软件处于哪个周期，该优先解决何种问题。 开发明知是提前优化，过分设计, 但是和测试又讲不通。 要么强硬不改，和测试闹得很僵， 要么改了又改，疲于奔命。更有些开发由于自身设计问题，导致修改成本很高，就拖着很多致命bug不改。 带着bug上市， 最后只怪用户没有经过严格训练， 不能体味自己的良苦用心。 总体格局就成了测试抱着是bug就该修正的测试理念没完没了的找茬。 开发抱着你不懂我的设计只因你层次不够的观点消极抵抗。 最终就形成了开发测试形同水火的局面， 却忘了大家本是出于同一目的努力的合作伙伴。 当然，国内绩效与工作量的计算方式也客观催生了这些矛盾，并且这种情况在国外也屡见不鲜。
    由于长期受分工式开发模式所荼毒， 国内积累了大量的码农与黑盒测试工程师。 串联起他们的就是一个优秀的TL， 结果就是TL要面面俱到，很累。 码农没日没夜的编码，但是对系统整体认知度不高， 总是难于在代码上有所突破， 写来写去就会写手上的那么几个功能或算法， 感觉职业前景一片灰暗。 而且多数开发总不明白为啥需求一直在变，弄得他们必须不断推翻之前写好的代码，疲于奔命。 但是具有良好的编码习惯与风格和通过经验总结出来的合理架构技巧的优秀程序员，总能够把各个功能接口设计的尽量透明，正交。 整个程序尽量紧凑。 好的重构习惯也是重要的，这种优秀代码总会表现出异于改动和复用的优势。 而要做到这些，除了有一个聪明的大脑以外，更多的就是要多涉猎软件工程的各个领域了。 没有做过测试的开发必然不会出于testability的考虑进行编码。不了解整个产品设计的码农也很难有好的架构设计。 最后得出的产物就是低质量的代码。 而且，开发很累。 相对前两个角色， 测试在这里面会稍微轻松些。 因为他们可以完全不管不顾，只要不停地找茬就可以了。但是这种做法是很不负责任的， 很多本该由测试担纲的工作转嫁到开发头上，难怪开发总是跟测试剑拔弩张。
    作为一个QA，要做的不仅是找bug， 也该对整个软件工程有个全局的把握， 能够知道不同时期的缓急轻重。 能够一定程度上分析BUG的code根源，至少要尽量避免把bug丢给错误的开发来处理。 对一些基本的编程技术和算法至少要做到了解， 虽说你不写代码，不用dirty hand， 但是陈述你的问题时至少要能说到点上， 开发跟你解释为啥会这么设计，为啥这个bug无法修复的时候你至少要理解他在说什么。 比如说‘鼠标移到XXX上去后的悬浮菜单无法弹出’和‘XXX的handover操作无效’明显后者更能让开发理解到BUG是发生在什么地方。 Download数据时UI卡死时至少该想想是不是数据操作放在了UI线程上， 这个BUG该给后端程序处理呢还是该让前端UI来处理呢？ 反复操作越来越卡最终crash时首先该意识到可能是内存泄漏。 一个bug辗转多次才落入正确的开发手中与一次性找到core issue 让正确的开发来解决其中的效率差不言而喻。一个连框式结构都没听说过的web测试工程师又能对软件的改进做出多少贡献呢？
    有的管理人员对测试认识比较深刻，只要是测试人员发现问题，就要求开发人员必须限期修改完成，而不是对问题进行分析、评估并根据开发人员的工作量进行适当的安排。这样有时开发人员容易与测试人员造成矛盾：这么简单的问题也要提出来，而且这么多小问题，我哪有时间去改那！测试人员也不高兴了，我没有错呀，我都把问题发现了，提前告诉你不是很好吗？要是到了用户那里岂不是麻烦了？我做了好事不但不感谢，反倒成了我的不是了。但是测试人员也不愿意得罪开发人员呀，所以有时矛盾发展结果就成了开发人员与测试人员私下里达成协议：不记录问题，与双方都有利。
    其实出现以上种种开发冲突不和谐的原因不外乎两点，1： 个人素质 2： 管理方式。个人素质的客观表现就是相互不理解。 并且常会有开发轻视测试的现象出现， 开发觉得测试的问题不值得浪费他的时间或改动他优雅的代码， 便找些技术上的不可行来否决测试的bug。 如果此时测试完全不了解相关技术的话， 很可能即使bug严重影响软件质量， 依然无力与开发相争的现象出现。 这种不对等关系一旦形成对整个软件工程都是很危险的， 毕竟测试才是站在用户角度使用软件的， 这种架空测试工程师权限的情形无异于置用户需求不顾， 闷头做软件，最后做出来的东西完全无法交付。 在我的工作过程中真的极少见到无法修复的bug, 只有修复难易的区别。 很多无法修复的问题都是受平台特性限制， 但是计算机技术发展几十年， 你会发现几乎所有问题都有前人考虑到了，如果这个BUG的确致命， 那就该不惜一切代价将其修复， 即使更换平台， 所谓的技术不可行多数时候是敷衍之词。 再说到管理，现在很多小企业管理混乱， 有的甚至连QA都没有。 只管让程序员苦逼的写代码，做出的东西能跑，不crash就赶紧交付。 结果必然是不断的用户抱怨。 还有的测试环境相当简陋， QA发现问题通知开发一声，不设缺陷跟踪系统， 最多找个execel啥的记录下。 到后期要么记录一团糟无法维护和评估产品质量， 要么开发修bug完全不分优先级， 哪儿心情好就修哪儿， 没修到得就算了。还有一个弊端就是TL仲裁流程复杂化， 很多需要TL仲裁的问题可能会被单方面忽略或者有些问题还要花很长时间向TL解释。 很多能自动化的单元不自动化， 测试与开发不得不不断重复劳动，劳民伤财。 过分重视开发或测试， 架空其中一方。 时间分配不合理， 开发工作的时候测试无所事事， 测试工作的时候开发没事做。
     个人感觉一个成型的软件开发环境， QA team 与 R&D team 必须协调发展。 微软之类的大公司现在是做到1：1， 个人感觉由于工作性质关系，与其用1：1的测试人员来配合开发工作，不如用由少量的软件工程师来负责测试，协作开发工作。 这样既可以缓解开发压力，又可以很好的协调进度和时间。关键时刻还可以担当下救火队员的角色。 看过人月神话的同学应该知道IT工程的人月效应， 与其找完全不了解项目的高级程序员来救火，不如由项目内的测试人员来担纲更可取。 一套好的QA Tool尤为重要， Linux如日中天 Linus做的内核功不可没，但是GNU的一整套R&D工具才是其生命力来源。 同样的工具效应在Android 与 IOS上都得以验证。 好的QA Tool不仅能完成大量的自动化工作， 还能为TL， 开发， 客户提供全面直观的产品进度与质量。 
     搭建环境时，以下几个条件是必须具备的：
     1. 一个好的版本控制系统 （代码管理全靠他了）
     2. Build server （有了他，开发的工作轻松了，分布式工作必须品。 GNU的auto-make，auto-build真的很好用，动态链接库这一发明也帮了测试不少忙）
     3. 缺陷跟踪系统 （BUG也是需要管理的）
     4. Task management system (进度要透明，需求要明确)
     5. Wiki (相当于一个内部博客， 便于信息沟通。 QA report 一般也发布在上面)
     6. IM， EMAIL server， Test system(如果有大量自动化需求的话。。)