培养测试人员的重要性

无论是公司领导还是测试人员本身，现在普遍存在一个错误的直觉，就是认为测试比开发简单，上手快，技术和经验要求低。很多公司将测试人员的工资开的比开发人员低，职业路线也没有开发人员宽广。测试人员自己也常常认为，做测试就是敲命令，取log，把所有的难题都交给开发人员，不认为自己对软件的质量提高也有责任，对自己的要求也很低。我也有一些同事认为，开发人员和架构师可以插手和质疑测试过程，可是测试人员不应该插手和质疑软件的设计和需求分析，测试人员应该只管好测试就OK了。
 
    其实，这样的想法，对企业自身的发展是很不利的。要知道，一个产品的质量取决于这个产品链上最薄弱的环节。设计开发和测试是对等的，设计强而测试弱，产品的质量一样上不去。
 
    软件是不可能不出错的。记得以前看过一本书，有个原来做硬件开发的人后来转去做软件。他写的代码一个错误也没有，大家都很奇怪，去问他是怎么做到的。他更奇怪地反问大家，啊？难道可以出错吗？他原先是做硬件的，硬件对bug是很难容忍的，所以要求处处小心，严格把关。可是软件就不同了，软件的bug似乎是与生俱来的，原因有很多。软件的应用发展很快，升级换代也快；软件结构复杂，层次丰富，接口众多；软件开发人员门槛较低，素质参差不齐；人们对软件bug的容忍度较高，等等。我们已经无法期望软件零缺陷。尽管敏捷的鼓吹者曾经宣称过敏捷环境可以避免传统软件开发带来的问题，但事实证明他们只是在吹牛而已。
 
    软件的质量在多大程度上依赖测试人员，取决于测试人员的素质和管理者对测试的理解。
 
    我比较欣赏米国的企业，把测试人员叫做QA，就是质量保证人员。这是在告诉测试人员，他们不仅仅要执行测试，而且要参与一切和产品质量有关的活动，是对产品质量负责的人。这样，测试人员的责任和重要程度就会大大提升。
 
    为什么呢？我们首先来看，软件的错误有哪些？
 
    软件从需求分析开始，就会引入错误。而且越是前期的错误，造成的损失就越大。需求分析，就是将用户的需求转化成产品的需求。这是系统架构师需要做的事情。系统架构师需要明确这个产品该如何来满足用户的需求，有哪些use case，这些use case直接关系到V-mode中对应着的系统测试的test case。系统架构师需要来自系统测试人员的反馈，来判断这个case的可测性和可用性。用户是否真的需要这些case，系统测试人员往往会给出他们的意见。Use case的偏差，直接会导致用户的不满，而且有可能导致整个feature的失败。我们有过不少这样的经历，就是系统架构师在需求阶段容易求大求全，在系统的复杂性和新功能对系统的影响上，在客户如何使用新feature上没有经验，在开发和测试阶段，麻烦不断，导致整个feature无法按期完成，最后不了了之，所有的努力都付之东流。系统测试人员在需求阶段加入，可以从用户的角度给架构师以反馈，告诉他什么功能是用户最需要的，什么功能是可有可无的，用户最关注的点在哪里。这样，架构师就可以有所取舍，将最能满足用户，且易实现和测试的部分规划出来，进行优化，舍弃那些对用户来说可有可无，却占到大量开发和测试时间的部分。一个公司的架构师往往是从软件开发人员培养而来，他们过多地重视开发成本，而忽视测试成本，也忽视用户的使用感受。记得有一个产品经理曾经告诉我，他们很难获得用户的真实感受，因为和用户开会的时间非常有限，一两个小时的会议，要讨论几十个新feature，每个feature只能占用5分钟，很难在这5分钟里问清所有的问题，只能靠猜。其实，比猜更有效的方法，是培养优秀的系统测试人员。他们不但熟悉测试，也能通过验证用户报的bug了解用户对feature的使用，也能够体会用户的感受。让系统测试人员参与需求分析过程，避免系统架构师出现大的偏差，帮助系统架构师预测用户对新feature的使用方式，是对产品质量提升的一个很重要的手段。
 
    然后是软件实现引入的错误。软件实现包括软件设计思想，软件架构和代码开发。对应的是功能测试。有些人认为，功能测试应该是黑盒测试，只关注需求，不应该了解软件的实现。我觉得这句话的意思是，不应该受软件实现的困扰。但是，知己知彼，百战不殆，这句话总是对的。有的时候，了解软件的设计思想，就可以预见软件实现是否满足了需求，可以避免毫无意义的测试，浪费宝贵的时间。比如说，我们曾经有一个接口双备份的feature，设计思想非常糟糕，逻辑混乱，只要看了设计文档，就已经很清楚测试的结果了。根本没有必要再去执行测试。正确的行为应该是“发回重审”，让软件架构师重新考虑设计方法。可我们还是执行了测试，发现了很多问题，然后是开发人员修改bug，结果越改越乱，最后连开发人员自己都不知道什么才是正确的行为。这个feature浪费了大家很多时间。还有一个IP QoS的例子，在了解软件人员的解决方案之后，我们就已经知道测试的结果了。我们认为这不能满足用户的需求，可是还是经过了测试，报错，改错的过程，也并没有达到一个好的结果。软件设计是否满足需求，这是软件架构师，有些公司是资深软件开发人员的工作。如果软件设计无法满足需求，后面的工作都是白费力气。测试人员参与软件设计，不仅仅是审查需求的可测性，也是在以测试和使用者的眼光来看待这个设计是否符合产品的需求，预见测试的结果。这对开发人员来说是很重要的。
 
    软件架构引入的问题也很多。有经验的软件架构师知道如何优化系统，如何减少模块和模块之间的影响，接口如何定义清晰并具有可扩展性，数据如何共享和保护，消息如何传递，如何在减少系统开销的同时增加系统的容量，内存如何分配，垃圾如何回收，在满足这些条件的基础上如何选择最简单的架构。这些说说容易，做起来很难。很多时候，糟糕的系统架构本身就会引入瓶颈。在了解系统架构的情况下，测试人员很容易就知道如何找出系统最严重的问题。我记得我到一个部门去做测试架构师的时候，测试人员经常向我提及这个系统的问题，他们已经在测试过程中有了很强烈的感受，可是软件架构师们却一直不知道，他们似乎听不到测试人员的声音。当我设计了几个简单的性能测试case，把最直接的测试结果摆在他们面前的时候，他们似乎是如梦初醒。但那个时候，已经进入系统测试阶段，修改软件架构是不可能的了。到了开发第二个版本的时候，架构师想修改软件架构，可是要付出的代价实在太大，只好做一些有限的调整了。如果在软件架构时让有经验的测试人员加入，让测试人员帮助检查系统的架构问题，而不是等到测试的时候才知道犯了错误，可以极大地提高软件的质量。
 
    也许大家会很奇怪，为什么开发人员不知道自己的产品有什么问题？这个道理很简单，因为开发人员是制造者，而不是使用者。很多软件人员除了编译自己的软件外，从来不使用自己写的软件。这样，他们根本不知道自己写出来的东西究竟好不好。我记得我刚开始做开发人员的时候，写用户界面。一开始我做得很花哨，功能很多，有些自鸣得意。但我喜欢做好了就让旁边的人来用用看，听听他们的意见。结果他们觉得我做得太花哨了，一点也不好用。我只好忍痛割爱，简化设计。我不停地修改，不停地让他们使用，反反复复很多次，最后在他们的抱怨声中我把所有没用的花哨的东西都去掉了，界面又清晰又好用，连自己都喜欢上了最后的风格。这也是为什么软件人员无法同时做自己产品的测试人员的原因。生产者很难客观地审查和评价自己辛苦创造的东西，所以他们对自己的产品不如使用者了解。测试人员在长时间的测试过程中，逐渐了解了软件和系统存在的各种问题，对可能出现的问题更加敏锐。那些架构师们也许只需要花上半天时间，找测试人员聊聊，就知道自己设计出来的东西有多么大的问题了。可惜的是，他们常常高高在上，不屑于去聆听使用者的声音。
 
    说了这么多，就是想强调，提高测试人员的责任感和素质，对于提升产品质量是很重要的。测试人员越早加入软件开发流程，越是能提高软件的质量。测试人员不仅仅是测试的执行者，更是理解需求，审查需求分析，讨论软件架构，寻找系统瓶颈的重要参与者，更是用户的代言人。对于测试人员的要求是很高的，也应该更加重视测试人员的反馈和意见。
 
    在很多公司，测试往往是最薄弱的一环。我们可以看到国内很多产品，花哨的功能很多，可是用起来很不爽，质量也不过关，这都是只重视开发，不重视测试的结果。一个公司要想长远地发展，必须重视测试，培养优秀的测试人员，给予测试人员更多的责任和权利，才能让自己的产品更稳定，更好用，更加符合客户的需求。