精辟名言

　　当你读一本书，读到某句话或某场景，是否有这种感觉，有很多想说的话，竟然作者替你说了；有很多场景，似曾相识，貌似曾经经历过，一切都是那么的熟悉。心中自然激起一层层共鸣的涟漪，或掩卷而思，或“拍案叫绝”，或许这也就是所谓“书中自有黄金屋，书中自有言如玉”的读书之妙处吧。这样的书，谓之好书。由于每个人的背景都不同，你认为的好书，他人并不一定能找到同感。由于工作原因，读测试专业相关的书籍不少，但让我记忆深刻，并会常常拿出来翻来翻去的好像并不多，不过JW（James A.Whittaker）的<<探索式软件测试>>是例外，主要原因并不因为它是目前市上讨论的焦点之一，而是书中的一些精辟名言让我觉得很受用。

　　例如：最近发生在身边的一些事情，让我一直在反思“测试的价值到底是什么？”，围绕这一主题思考，便又想到JW在书中提到的这句精辟名言：

　　“软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限，思路中的狭隘和技能方面的不足“（托尼.霍尔，1996）“

　　当第一次看到这句话时，正如前面提到的，激起了我思想的层层涟漪，似曾相识，道理亦明，似是心中埋藏很久的一句话，终于有人替自己说出来了。怎么好的至理名言，不敢独享，于是把这句话放在新浪微博上，与圈中朋友分享，见如下截图，自是引来不少同仁的反馈。

　　为什么会激起我思想的层层涟漪，品着这句话，回顾过去。如果说过去我是无意识地去影响开发，那是因为有足够经验的驱使，为了把产品做好，不仅是软件开发人员，还是需求设计人员，甚至是产品开发链的其他成员，我都会主动出击去影响他们（或许这也是一个加勒比海盗学者的特点之一，读<<学习要像加勤比海盗>>后的自我发现）。常常，在面试时我会问应聘者：“做测试工作，让你感到自豪的事是什么？”，大部分人回答的是:“发现Bug，特别是一些让开发难于解决的严重bug，是最开心，最有成就感的事了“。而相反，测试大师们恰恰建议我们要丢弃软件缺陷数量、缺陷严重性、测试用例的多少、自动化代码量等可量化的衡量指标，转而通过观察测试人员提高了多少开发人员的工作绩效来评估。面对这些差距，笔者倒也觉得正常，如同做任何一件事都有一个循序渐进的过程，毕竟软件测试在国内的起步较晚，据去年我做的一些数据调查，基本上晚了约20年。但，这并不意味着我们只能望洋兴叹，站在巨人的肩膀上，我们可以看得更高更远。

　　前行中的反思

　　就测试而言，质量如生命，效率如健康。软件测试人员是质量的最后把关者，守护神，这个我们都谈得很多了。谈到质量，我们会提及很多方法，如黑盒，白盒，灰盒，最近比较流行的敏捷测试，探索性测试等。谈到效率，我们会不由自主提及自动化测试，自动化工具等。测试的使命就是围绕产品的质量、效率转。我们的出发点都很好，但在解决问题的方法上，往往是集中在结果上，即出现了什么结果，再去想办法解决它。对于测试来说，可以理解这个“结果”就是软件的缺陷。我们经常也谈，测试要尽早介入，尽早发现问题，尽早把bug消灭在摇蓝中等。这些说的都是事，而我们恰恰忽视了一个很最重要的东西，就是在整个产品开发链中，产生这些事的人的问题。（注：这里不是谈人的管理问题）。如果我们能盯住人（角色），因为这些问题实际都是由前面的人产生的，我们是否可更加轻松。

　　把我们的眼光放得更宽远一些，锁定可能会出现问题的设计人员或编程人员身上，用心去发现他们解决问题时的方法局限，思路狭隘或技能不足的体现，便能尽早发现问题。下面是案例分享。

　　【案例】用户场景联调

　　说明：故事是真实的，但为便于阐述及机密原因，案例中的人物及相关信息，采用化名

　　人物：

　　D0：软件项目经理

　　D1：Team 1的软件开发工程师

　　D2：Team2的软件开发工程师

　　D3：Team3的软件开发工程师

　　T0：测试负责人