序  言

谈起敏捷，很多人并不陌生，可能你的公司依旧在使用瀑布开发模式，可能已经转型为敏捷或者DevOps，也有可能正在处在这个转型期。不可否认的是，这个开发模式已经越来越热，甚至很多在几年前接触到但是抵触敏捷开发模式的公司，现在也慢慢的开始转型。从互联网公司到银行，从欧美公司到国内企业。

本人在上述三种“可能”的公司里都工作过，也帮助过一些公司从瀑布模式转型敏捷，有了一些经验。工作之余喜欢思考，这里就和大家分享一些个人的想法和遇到的事情。希望大家多多指教，互相交流。

如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目  录

序  言.. 1

1   概述... 2

2   测试的价值... 3

3   专业测试人员的价值... 4

4   测试的壁垒... 5

1          概述

笔者最近在TechWell上看到一篇文章-对探索性测试的探索，链接地址：https://www.techwell.com/techwell-insights/2018/09/exploration-exploratory-testing，有些感想，就在这里记录并和读者分享一下，共同讨论。

2          测试的价值

文中首先就提到“无论您是在实践DevOps、持续集成、持续交付，还是在持续进行任何事情，测试始终被认为是交付的主要延迟。大多数人简单地认为开发人员是价值中心，测试人员是成本中心。”

对于这段话，我是深有体会，曾经不止一个人和我讨论过这个话题，就是测试不产生价值，所有的价值都是开发过程中产生的，测试只是帮助寻找Bug，同时增加了时间成本和金钱成本。我曾经所在的团队中，开发人员也是认为功能是他们开发完的，交付的瓶颈就在我的测试这里，如果我能测的顺顺利利的，那么产品就能如期发布。

开发人员认为开发过程中，产品做出来了，产生了价值。可是，如果产品本身带着质量问题的话，它就达不到我们事先定义的DOD（Definition of Done），又怎么说是产生了价值呢？

如果测试的不够好，那么产品带着质量问题到了生产环境，因此产生的修复成本，是不是要算到项目的头上呢？如果你承认这一点的话，我可以说，如果在测试环节发现了这个问题并修复了，那么这个修复成本就是本次测试的价值的一部分。

3          专业测试人员的价值

相信很多公司都是这么做的，“XXX开发工作做得不好，那么将他转到测试组吧，好好做测试。”，或者这么做的“成本不够啊，所以我们没有专门的测试人员，开发人员自己也能测”

现在的市场上，开发人员要求的往往都比较高，小公司的测试人员的要求却在持续走低，比如实习生，或者年限要求短一点的。这都是公司为了节约成本，而降低质量要求的做法。反观一些大公司，对测试人员的要求，一般开发人员可能都听不懂，地位也是不低于开发人员的。曾经一个测试组的同学，根据质量把控要求，将检测到的一个指标告诉开发人员“你的自测试参与度不够，请提高，否则影响你年底的绩效”那么是否是这家公司对测试重视的程度过分了呢？

引用该文章里的一段话“确实：每个人都可以测试。如果这恰好是你的开发人员，那就顺其自然吧。但是每个人都可以测试得很糟糕。”

测试不是简单地去点一点就完成工作了，像前面提到的，这一过程是要产生价值的，所以专业的测试人员的能力不是随便安排个没经验没培训的开发人员就可以去做的。

那么在当下测试“左移”的潮流下，如何让开发人员做出有价值的测试呢？专业的测试人员的价值又在哪里呢？

这里举个例子。有个公司开始实行开发人员在开发阶段做好测试的要求，而专业的测试人员像客户一样去验收产品。读者可能会问“你说的开发人员测试的结果可能很糟糕，既然后面还有测试人员进行验收，那么开发人员自己测试这一过程不就是浪费时间吗？”其实在这个流程的背后，还有一个动作，开发人员会针对验收过程中提出的Bug进行分析，为什么自己当初测试没有发现，并和测试人员沟通讨论，在这个过程中，不断地提高了开发人员的测试能力和经验，这使得测试的“左移”更有意义。

4          测试的壁垒

之前笔者所在团队，也在做开发人员自测试这个活动，通过不断地测试-验收-沟通反思的过程中，开发人员的能力是提高了，那么如果我们只针对手工测试执行这一步来说，开发人员测试总是测不全的根本问题在哪里呢？很多开发也打趣的说“自己开发的东西怎么可能测出问题”

笔者认为，根本在于基于业务的探索性测试。以下为百度百科上对探索性测试的解释：“探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。”

开发人员由于长期的开发工作，导致思维模式想的更多的是如何去实现XXX功能，当其做测试工作的时候，更多的是认为测试，就是执行测试用例；而测试人员聚焦于业务，即时是依据写好的测试用例完成了测试用例的执行，依然会从用户角度，针对产品的使用进行思考和测试，重新探索出问题。这个差别，是我认为的开发人员面临的测试壁垒。如果公司想培养全栈工程师，开发人员自己做开发同时完成测试工作，那么一定要打破这个壁垒。