欢迎大家光临思维发条。我们今天请到的是马菲菲和悟空，我们今天讨论的话题是软件研发过程中的测试，这个唉对这个测试的话交给马菲菲。

测试交给我就不是测试交给我了，我们今天就说要聊一聊软件研发中的测试问题，这个问题我了解应该是悟空提出来的对吧？悟空你提出这个问题或者说提出这个专题，是不是有什么故事可以先分享一下，对。

有一个小的故事想想和大家去分享一下，我们在企业里面开始去做敏捷治理方面的一些工作的这个时候，然后从这个产品先给他整完了，然后我们就开始减一些工程效率，有一些质量的问题，我们就会去跟测试的人员去聊这一块的东西，然后他也很努力的想配合我们去做这些东西，又是听课，然后又是做笔记，然后还打开思维啊，搞了半天之后，我们有一个看板，看板上有些测试，他每天在会他就在那个地方愣着，他就说感觉我自己的工作好像也不知道怎么去体现这样的一个流动，然后你跟我说了说好像能流动，我又觉得自己做的事情没啥价值，所以他就当时提了一个问题，我们测试左一左一左到后面，不知道怎么证明我们自己做的这件事情是有价值的，对吧？

我们好像原来接着一些需求就要去拿去测，然后测完也就测完了，发布也就发布了，好像从来没有认真思考过它到底怎么样有价值，后来我们思考了一段时间，发现这个事情确实很难去解释或者去作证，量化上面的一些东西，但是量化又是我们会觉得很会有一些敬畏的方式，所以我今天把这个话题带过来带到给大家，大家我们一起来聊聊，怎么来证明测试有价值之间的事情，或者是可以聊更广泛意义上面的这样的一个话题。

好的，菲菲。

明白了，所以其实今天主要第一个问题就是说咱们这个测试左移它到底到底价值在哪啊，你说到我突然间想起来，有一次我去参加一次分享，应该是应该是乔梁老师的一个分享活动，他那是好多年前了，他在大会上就讲说，他说测试是成本，他就这样他有这么几个测试是成本好像五六个字，我当时印象非常深刻，就是在听到他讲之前，我没有很认真的去想过，就测试活动应该是一个成本，那么如果说呃从测试它本身是一个成本的角度来看，我相信这里面可能也有一些比较有趣的见解，我自己先想到的，这是一个方向，那么也想听听说咱们今天大家都在敏捷研发过程中都比较有一定的实验经验了，像王老师你怎么看待测试左移这件事情，它的价值到底是什么？

这个东西我觉得左移的话，这个东西我觉得我们可能是已经涉及到了一些专有名词，比如什么是左移，让测试的话，尽早的介入整个软件研发过程中，也就是说平常的话一般都是开发或者需求人员写完了，对吧？开发人员折腾清楚了，测试人员的话才把这些东西的详细案例再更详细的东西，然后再开始进行测试。

我们希望的话测试人员的话更早的介入这样的一个过程之中，所以的话叫测试座椅。这个话题的话就马菲菲说的乔梁的一些观点的话，我突然想起来了，之前的话一个好玩的事情是什么？就是说我有朋友的话是测试圈子的，测试圈子的人的话就特别不爽，就成天说你们敏捷圈子怎么成天说你们这个测试没有价值对不对？你们就是觉得自己了不起，对吧？

你要不过来学一学我们测试的认证，然后我就说你给我打个地板折，然后我就去学了这样的一个专业的测试认证，我现在是有证的测试人员，一般我不知道其他的敏捷教练是不是有测试的证，但是我有测试的话，就是说当然了一方面是来自于培训，另外一方面是来自于经验，其实它是由两个责任的职责的。

就说你们觉得的话测试的话有他要做哪两件事情。

我觉得测试要做哪。

两件事情。

对他是职责测试可能太笼统了，对吧？如果再进行细分的话，测试要做哪几件事情或者你们觉得。

我先说说，我觉得事前的话他要去保证设计出来的，这个东西是跟需求方他们是一致的，事后的话就是开发出来的这个东西和我们想要的东西是一致的。这是我的理解也听听非非。

我倒觉得这个问题一下子让我重新回来看，我们在敏捷活动中测测试这类专长，专业人员他们要提供的是什么？

如果我们把所有的敏捷研发活动，它的核心是在于形成一个有效的软件设计，那么我觉得测试它在研发前期提供的也就是产品导入功能导入阶段的，它提供的是一些基于测试视角产生的必要的一些设计活动。

就说我可能有一些设计，我是基于测试角度去完成的，比如说一些异常流，像这一类的就是比较典型的，或者一些我们如果你要做这种呃是长话短说，可能有一些是性能功耗方面的，这也是比较偏测试的，我觉得这是他在早期的，如果他在一个软件研发的偏晚期的活动，常见的就是刚才吴红也提到了，他肯定是要做一些质量收敛的活动。

但如果我们要从敏捷角度看，我们认为一个自组织的全功能型的研发团队，它应该是质量配件，就测试是我的质量是在我研发过程中保证的话，那么我觉得测试可以在呃更晚期，或者在研发过程中去做一些测试能力的一些活动。

当然我现在可能已经就在讲说我理解中的一个比较好的敏捷组织，他的测试人员在未来的面向未来的情况下，他应该做的事情，所以离开测试本身要做的需求的解读，用例还有验证，我倒觉得它更多的应该是在产品设计阶段，还有测试能力保证，比如说测试工具，这一类的测试能力保证这个方面去做一些工作。

这是我的理解。

对你们刚才说。

回到王老师这儿ok。

也就是说刚才你们说到了的话，测试的话有很多工作，但是听上去测试好像就是一个需求人员。

好像测试确实可以提供一些特殊的需求这方面的视角。

比如说是你要测一支圆珠笔，圆珠笔的话需求人员的话要写，比如我要能在纸上写出字来，需求人员难道就不管了？

他可能要定义一些，比如他希望的话写出的字是多粗的做细的，对吧？他好像的话测需求人员的话好像就差不多了。比如交给测试，那测试的话是不是需要写一些测试案例，test case或者是叫做验收条件，或者叫satisfaction condition对吧？或者叫acceptance criteria这种东西的话，好它会有哪些比如笔有多沉，它是不是能够决断？我们说这些东西是测试案例，但是这些东西是不是需求？你们马克思c悟空你们觉得这是不是需求？是。

我是觉得这一块需求它是属于一个稍微更偏技术方向的一个需求。

对，也就是说我觉得从现状来看，我们现在对我觉得从现状来看，我们确实有些团队他这一类的需求，它确实是由测试人员在保证的，测试人员他所处的视角还有他的专业技能，确保他会从这个角度去考虑问题。对看悟空的悟空是怎么理解的。

我确实是对这块尤为感兴趣是，我想把它给聊清楚，我觉得大家每次聊测试话题会聊到这一个边界是什么？

我看有一些测试他会去写的一些性能，包括一些固定的格式，它是有一些套路的，就写出来的测试压力是有套路的，但是它如何能对产品需求产生一些支持，就是说我为什么要这么去设计？

这些设计上面会对你的交互或者性能上面有没有一些改善？好像测试不是特别关注，例例如说它有一些套路就是什么表单的一些填入的一些字段，然后校验它的一些正伪性，我就觉得这个东西一旦它可以被套路化模板化之后，他做的事情就是重复的一个事情。

你基本上所有的系统，你不管是面向哪一个端的一些系统，你来来去去你做一个系统的底层，你就是这些东西啊。

但你说到了这个东西的话，就是说他是不是测试愿意做这部分的事，我突然想到了一个其实一般的来讲测试我们认为它就是需求，也就是它测试的这些东西，不管是不是技术需求，这些也是需求，那是不是需求的一个关键点的话，客户是不是在意这东西？

比如说我们拿一支笔的来举例子的话，这支笔如果说测试说这支笔的话不能够被轻易被决断，不能被轻易决断这个事情的话，虽然客户没想到，但是他应该算作需求的一部分。如果客户不care这个东西，这个东西就不应该写入测试案例，不应该进行测试，它就不是一个验证点，对吧？如果这么说的话，那测试其实跟需求人员是一样的，只不过限于什么？有很多人的话，尤其测试人员他们的外包人员比较多，人员流动流动性比较大，恰恰是因为这样的一个上下文，所以很多测试人员的话，他没有很多的上下文的这种领域知识的储备，如果有了领域知识非常丰富的领域知识储备的话，其实测试人员他其实要他就是一个需求人员，只不过他比需求人员还能更为了解细节的一些人。

所以从我的角度上讲的话，它前不前置，当然了咱们说的这一个东西就是说刚才说到的测试人员，他就是需求人员，对吧？另外的一个东西为什么要测试前置或者是左移？其实我觉得左移这个词我并不是很共鸣，左的话什么是左看板的？从左到右，人家国外的看板还是从右到左，对吧？一般来说的话叫测试前置，或者是叫做build quality in。

这也就是说我们再做一件事情的话，我们要尽可能一上来就把这件事情想好，而且程璇做的时候别做到一半的话，测试人员跳出来说你这个不符合功能功能要求对吧？这就不是我们希望看见的现象，我们希望的是瞄准完了准确的设计，然后再寻找下一个目标，而并不是打完一枪之后，测试人员跳出来说你这东西不对。

好，他为什么能说这不对，就是因为他前期没有参与过进来，所以的话我们有一个假设是有这样的反复量比较大的情况下，或者是程序员的话，需要有一部分的额外精力去应对这样的一个东西。所以的话我们需要测试前置或者说测试桌椅，但一般来讲的话，现实情况的话，测试人员太多的外包人员了，这种外包人员的话，你让他左的话，他也不愿意去了解更多的业务上下文，对吧？这就是另外一个story。

对。

说我说到这，我一下想到了我们现在在我们现在所在的企业上下文，我们的做法，我们的产品规划这一块其实是有两种主要的角色的，有一部分它比较偏这种技术细节规格型的这块人员，他可能跟产品的战略方向这一类的工作规划工作它是有有差异的，有点像刚才我们所讨论的就是测试这个岗位这个角色，他在一个更潜质的活动，在产品策划阶段，他能做的是一些更深的更细致的输出这一类的跟产品规格有关的这一类的细节，这一部分的内容是可以有助于后续的产品在技术方案的一个设计活动的。所以我觉得有可能我们现在目前看到的现状比较骨感，一个是测试人员他到底的，人员结构是什么样子，另外一个要看的一块就是往往这个岗位它未来的发展方向来看的话，如果我们认为测试人员可以更左移或者更闲置的话，那么它的实事实上他的很多工作其实会去跟产品设计，或者是跟他会跟开发的设计活动比较深入的结合在一起，对。

从这点上的话，对，就有点像一个技术需求人员。对。

我刚才听完这一段我特别的有感触，我就发现这个东西会不会是一个自然而然形成的有一些误区的地方，就是测试有些时候它的发生阶段就太靠后了，然后让我们觉得好像他需要左移，但刚才听到他说完之后，如果把它当成一个需求，尤其是技术需求，实际上它是一个本来就发生在产品需求和技术需求，它是一个并列的阶段，它就在最开始就发生了。

对。

但有的时候的话有可能有些上下文是什么，有可能他之前的这种节奏感的话，它就是在靠后面，所以的话它每一个版本或者是每一个迭代的话，它都就需要在这个时间点介入工作。

它如果你让它往前走的话，它就需要这种用一般的话讲叫倒步，就得倒几下才能够或者是有些工作比较紧张，有些工作要放弃，这样的话才能赶上这种节奏感。

但有的时候他不愿意做出这种东西，因为每一个版本或者每一个迭代的话，给他的压力都很大。

我们在做这个东西的时候，我就发现是什么，他提前做和他往后做，就是说他提前做这个事情，回到这个话题，他怎么去证明他提前做了这个事儿对我们的开发质量有价值，我们做了哪些手段让他能够感受到这种价值？

是。

不是我们其实前面那一派大家都在讨论的到底怎么样的是一个左一，那么接下来其实我们已经进入到了我们这个问题的核心部分，也就是左唯一到底会带来什么价值，这块看看王老师有没有什么有没有什么想法，先跟大家分享一下就就是。

原来的话就是传统的软件工程的话测试更像是一个把门的人，或者他是一个能够去验证，它好像通过了就不通过。

但是现在的这种转型的方向的话是测试人员的话，不光要有这样的单这种是一个坚守或者是保证的一个角色一个黑脸，他还需要去让这个团队的话拥有测试意识，测试前置的话，或者是测试左移的话，就能够提高团队的测试意识。这也就是说什么呢？之前的话有一个我突然想到了一个台湾的测试的专家，那天跟我说，他就说测试人员就像一个体温计，你体温计的话36度5 37度2，你不停地喊温度，其实并不是有助于温度的降低，或者是改变，因为它只是一个温度计，但真正改变体温的是身体本身。

这也就是说如果原来的这种方式的话，全变成了一种保安或者叫什么的，就是门的守卫的这种感觉。

现在的话一方面他们要做这件事，因为的话我们不可能一下就转过来，因为大家的意识也没提升，一方面要有职责，第二方面他要有这种把这种测试的意识能够提前告诉大家的过程，所以的话左移的话或者是前置的话是非常有意义的，这是第一点。

第二点的话是这种往前做的过程中的话，它有助于把需求弄得更清晰一些，这也就是说我们提前就沟通了一些细节的东西，然后我们想到一定程度再往前做。这也就是说你们记得的话需求的三种状态，沙子、板砖、钻石对吧？钻石的话其实就意味着很多细节的技术要求或者是需求测试案例都已经完成了，这样的话可以非常清晰的定义这个东西什么叫完成。开发人员在开发人员，要不然的话开发人员你说怎么能算这个活完了，开发人员认为我做这个做完了，做一支笔，好我随便找一个石头过来的话，这也是一支笔对吧？

这样的话就有助于把这个事做清楚。

你们会不会遇到就是说像测试他平常写案例的颗粒度和我们平时写用户故事的颗粒度，它也不是特别一致的时候，这两者怎么去关联的？

用户故事一般的话要包含测试的案例的这种力度，也就是说它是一个一对多的关系，也就是说一个可能最小单位的可交付的需求的话，可能咱们说用户故事它要包含一堆的测试案例。

是。

我觉得刚才这个讨论让我一下子想到了我最初在软件行业的工作，最早我们所在的团队本身是没有专职测试的，我大概当程序员写了有一两年的代码，我们的领导有一天说要成立测试团队，那个时候我对于软件研发这一块，而技术是没有任何的概念的，完全不知道测试是用来干什么的，对，所以我回到我最初很多年前做软件，当时我的第一反应就是测试到底是用来干什么的，我我觉得从现在回想当时为什么会有测试？

可能一方面就像是刚才王老师讲到，那这个岗位它其实要求有一些跟软件收设计活动有相对来看是有差异的一个专业性，对吧？测试人员的专业性和我们做设计角度，你正向去思考和你站在验证的角度去思考，其实这个专业性和关注点都是不太一样的。

那么另外就是测试它还有一部分专业性来自于说，因为测试它基本上都是场景化的，它有很多是多场景串联的，如果我们从大型系统，比如说我们是这种金融交易类的系统，从大型系统看也好，或者我们是一个比如说我现在一个做手机的企业里面，手机企业它要考虑到集成集合集成的角度来看的话，它的它这个活动不仅仅是一个设计过程的活动，它就是有整多种功能能力整合串联在一起以后，要形成的整体的情况的验收验证。

所以这个专业性还有专业的视角，岗位带来的专业视角，这个都是其他的岗位所没有办法去提供的。我们看软件活动把它当成把它看成为一个工业生产的过程，你肯定要有分工，你才可以提高效率。所以回想当年的话，我们为什么要成立这个测试岗位，测试部门测试岗主要就是为了解决我们的软件，它在集成角度质量比较差的这么一个这么一个情况。

那么回到我们现在好多年过去了，大家现在在谈敏捷的话，我也在想，那么在这种新的情况下，我们想要的测试前置或者左移它的价值带来的价值是什么？还是我觉得这个专业角度这一块还是不能扔的，对吧？

所以测试人员他本身的专业度这一点要求它串联多个场景，它要由集成的角度去考虑问题，我觉得这些东西都是非常有价值的，但是不是所有的都可以说是在不是所有的一验证活动都要那么晚去发生，因为我们都知道软件是一个策，是一个设计工作，那么它应该如果你将来有一天知道你要集成它，你应该在设计的时候就知道从要集成的角度去考虑。

所以我觉得这一块也是我觉得测试它在新的敏捷情况环境下它所移的好处。

所以我觉得我再总结一下我自己到目前为止我的整体的想法，我们从大规模软件产品，比如说手机这样的大规模软件产品来看，测试这一块活动它会比较晚去做。

然后因为那个时候比如说集成活动，它要到比较晚的时候才具备条件，那么从设计本身软件研发的设计活动来看，我们是非常希望说有测试角度的设计活动发生在一开始我们所有事情动工之前去发生的，包括我们怎么去定义我们的验收对吧？

包括我们怎么站在多多场景区域完成整体的设计活动。这个视角是要补齐的是开发人员，他们是基于功能模块划分对吧？我们开发人员一定是基于功能模块划分，基于工作基于它的技术站划分，5期的是这一类的我们的人员上的配置的带来的缺憾的。

所以从这两个角度来看的话，我觉得测试它向左要做的东西是什么？应该是对于设计活动有贡献的，那么它价值很明显的，我们希望去做质量内建对吧？有点quality吗？

我突然想我大概。

是这样想。

对我突然想起一件事，也就是说他为什么尤其在敏捷团队的话，这种快速迭代快速交付的情况下的话，更强调测试前置或者是测试左移，是因为在不停的往前做的过程中的话，开发人员的投入的精力的话，相对是一个平线，也就是说你不管你时间过了多长时间，你研发团队有多少人，基本上你的投入的精力就这么多。

但是对于测试人员的话，在功能多不停的多变多的这种增量的前提下的话，你会发现测试人员的这种投入的精力的话是急剧的往上涨的，在这种只急剧往上涨的情况下的话，如果开发人员做完了之后，就把这个东西的话交给测试人员去测，开发人员说我做完了这块的东西你们去做去，但是之前的那些功能的回归或者是功能的完备性，开发人员有的时候并不是特别在意，但是其实在迭代增量式的开发上，开发就应该在意那些东西，但是因为职责或者划分的话，开发人员可能就在前面，测试人员就在后面，所以有的时候的话测试人员的话就会比较痛苦，尤其是在这种迭代非常频密的情况下，把测试人员往前放的一个好处的话，就是让这种测试意识质量意识，在这种不停的增量的前提下的话，大家都知道提高这种痛苦的话是大家的这样的话开发人员也会持续的去优化自己的代码，或者是提交出一份质量比较到位的一些代码给后面的工序。

这个东西让我也想起我之前的话ThoughtWorks的话，当然了以前就是说如果有研发人员的话，或者是你要做一个项目，你们猜悟空马菲菲你们猜，他如果项目组要一个人的话，会要哪个角色的人？如果这个项目就一个人。

架构师吗？

我感觉这个话题抛出来应该是要测试是吧？

要程序员，如果一个项目就需要一个人，你会发现的话要测试干什么对吧？项目经理干什么？对吧？我们最重要的是写代码，谢谢。

这个东西就会比较明确形成研发团队的瓶颈。

好，如果开发人员有一定的量的，你要再进入加入团队一个新的角色，你们觉得要加入哪个。

角色这个要加架构师了。

我我们之前一般你们这是你们是不是有当架构师的是吧？怎么对架构师这么你们不要一上来就想这个东西很大，这个东西的话如果再加一个人的话，他肯定是需求人员。

因为在项目的一开始的话，需求人员开发人员就能hold住这个东西，因为他有完需求之后的话，他自然就自己做了。但是如果项目规模越来越大的情况下的话，需求人员就特别重要了，对吧？因为需求人员的话把前面的归拢有一些思路对吧？再进行沟通，这样的话效率就更高。所以再加需求人员好，项目规模再大，加什么人？

该轮到测试能力，项目经理我告诉你项目。

项目经理这个不会因为项目经理你说他干什么，他管项目，这么两三几个人七八个人八九个人还需要他协调，对吧？不会的还需要写周报。

还有PPT。

你这个卷的不要的真是的加一个助理。

什么玩意都可以成为助理。

帮大家写。

周报再加的话加测试。你会发现的话，这开始分工了的话，开发人员的话在就需要有一个后面的自己hold住测试的话就有点费劲，或者需要有这么个角色就更复杂一些了。

再往后发展才需要项目经理对于架构师的话也是可能项目经理或架构师这样的角色，有的时候架构师去兼项目经理。

这么来说的话，其实在项目一开始的时候，其实团队的对质量的意识和测试的意识就要提高到很大的程度。

但是现在为什么总说测试前置测试前置或者测试左翼，是因为你一上来的话团队规模就很大，很多人的话不知道之前的故事，也就不知道团队的话，你就应该自己把自己的这个事做好。

嗯，是

你这么一说我突然间我突然间发现一个团队里的常见的情况，就是我们的测试同学基本上我以前的经验都会是比较说话比较强势的，为什么？

因为大家都知道测试同学永远都在说真话，而且他们一定会。

因为他是最后一道门。

不管哪个栏对的，所以测试同学往往会是整个团队，大家最想听的就是测试人员说这个东西到底做成什么样子，到底有没有风险，而且他们提出的问题大家都会拼命的想办法去把问题解决掉。

对，所以测试人员他我觉得是不是某种意义上来看，我们特别希望这样的专业的同学们，他们可以更早的去抛出他们的理解，抛出他们的一些人，让我们在一开始软件设计活动中，我们就去避免一些问题，而不是说我们到项目一个迭代要结束的时候才去担心质量不好，然后认真的去听测试人员，给大家组织开会，到底还有哪些霸哥没有解决。

我觉得你说的还是挺典型的。

但是为什么会有这种事情的出现？是因为研发没hold住吗？研发它没有hold住，所以后面那个工序就要hold住。如果前面研发hold住了，测试他很高兴的，但是大部分情况的话是研发这关没hold住，测试人员hold住，但很多时候的话，如果压力没有压到位的话，测试也开始放水了，你知道谁就要跳起来了。

项目经理业务。

或者是项目经理。

产品对。

产品。

业务对吧？真正的受益者对。

你会发现的话一关没有hold住，那就下一关hold住，下一关没有hold住，那就再下一关hold住。

最后的话就到了用户的面前，用户的话就开始骂街了吗？

我突然间发现我我突然间发现有一个观察，就是说我们都知道我们是需要分工合作的，对吧？

因为分工可以让比如说你是前端或者你是后端的研研发人员，你可以在你的专业角度里去深耕，然后让你的技术提升，所以分工很显然是可以带来非常好的我们去提升质量，包括我们怎么去让团队的能力更强，但是另外一方面由分工带来的这些信息的偏差，带来的一些视角上的偏差，我们还是需要有一些机制去弥补它的。

在这个角度我们特别希望说产品还有测试这些，他们站在自己的角度可以跟开发一起去打配合，共同的把这些事情做好。

所以我在整个咱们前面这一块去聊关于测试活动的话，我突然间意识到我们其实好像都更在呼吁测试人员，他们可以去弥补开发从分工角度上这个组织本身的先天不足，然后它可以帮助团队去创造更好的一个产品。

对，突然间有这么一个感觉，觉得还看来我们测试同学的前景还是也非常重要，前景也非常的美好。

是因为他们被逼的对，他如果不透露这个事的话，整个系统就崩了，有可能对吧？这是一。

另外一个从工资的角度上，你知道测试人员的工资吗？测试人员的工资的话，初级测试人员的工资是不高的，但是高级测试人员的话或者是项目测试主管，他的工资是要高于高级成全的。

还真不知道这。

我的认知里面也是吧中级的格式，就中级测试，好像我记得这我们要聊具体的，我记得初级的话，你出来可能就有八九k然后可能中级的时候就已经能超过一大部分的这种。

初级程序到中级。

对，如果你又能够写自动化测试，而且你又有什么样的一个代码的经验的话，你的工资又得更高了。

对他容易翻的。

对，所以从这一点啊。

看来是一个非常好的职业机会。

对的，也就是说它的上升的通道的话是要比程序员的话更加的怎么说指数性的往上走吧，但是你也需要花更长的时间在基层的话积累你的领域知识和具体的技术。

其实我想聊到我聊到这个话题的时候，我在想说，因为身边很多朋友原来也是他的同学做测试，但我发现他们基本上能走到初到中级，这一块就会停滞，会有一个非常大的断层，就很少有人会往上走，很满足于就是说做手工测试，或者说是做一个守门人这样的现状，然后我访谈过一些周边的朋友，不太有这个意愿，往往往前面去探索，我不知道大家的平常有没有遇到这一类。

你别说这个角色了，其他角色其实也不太愿意往前走，谁的话只要弄熟悉的话都不愿意往前走，

对我倒是非常有共鸣，确实我也感觉到我接触到的很多测试同学其实非常优秀的，我们看愿意往前走的这一部分，我觉得他们是非常优秀的。

一个是因为我觉得他们有的时候可能比起开发来讲，它更容易接触到全域的业务领域里面全域的这些信息，这个可能是他所处的岗位的带来的一个优势。然后因为他有比较完整的业务视角，所以他往往他们做出的一些专业领域里的活动，你会看来如果再结合它有一定的自动化方面的能力的话，效果确实是都比较不错的。

所以我倒觉得说我知道这两年好像一搞敏捷很多测试岗位也有一定的压力，但是另外一方面也是想借着今天的我们探讨，我也觉得确实其实测试人员是可以有一个比较好的发展机会发展前景的，可能只是说大家是不是没有那么去很好的去理解他所在的岗位，它本身它的增值活动到底在哪里。

对，特别是为什么要说增值活动，我这里稍微跑好个题，也是在讲说测试价值了。

我以前曾经遇到过在团队的时候，我们有一个专门的独立力的测试团队，然后这个团队是非常痛苦的，需要频繁的向我们的产品真正的总监去证明这个团队存在的价值。

因为所有的软件活动它笼统来看都会倾向于认为测试本身是不会产生新价值的，对吧？当然这也算是扣题，就是到底测试左翼它的战略在哪里？就测试从它本身来看，它确实不去产生新的代码，那么它的价值到底在哪里？它又不像说产品设计产品收益率拿出稿子来之后，这个东西整个活动就可以推动了，对吧？

然后往往测试它又是在一个项目的尾端，万万万一你这个项目时间紧张，测试资源之间又是被压压制的压抑的，如果质量不好，所以人人还要为此买单，所以这个现状也是比较骨感的，我不知道我提这一点的话，我们两两位老师们有没有什么共鸣，或者有没有对于这些方面有没有什么点评？

我很共鸣，我大家还想听王磊老师说说，像我们讲产品的时候，或者说我们讲需求的时候，我记得act里面就会讲你需要提供证据，你做好这件事情了对吧？你做产品你有原型，你有设计对吧？你做开发你代码你能提交，你都有一个很关键的步骤，证明你做这件事情是增值的测试。测试的话，我就知道行业里面原来就喜欢统计你提了多少bug，但是一提bug就容易有矛盾，我们怎么有没有一些新的方式，有一些活动很具体的活动来证明你测试做这个东西就是有价值。

对我很好奇这个就。

我突然想到了就是说测试它，就是说咱们说它有没有价值这个事的话，我觉得从某种角度上讲的话，它的低级的人工的测试，它的价值是不明显的，尤其是在敏捷的增量和迭代的这种上下文下，如果说你这软件做完了之后，咱就永远不改，我觉得手工测试totally fine，完完全全没问题，但是你这个东西的话一遍一遍做一遍一遍增加一遍一遍的话去调整，这样的话手工测试或者是人肉的这种测试的话，就一方面它就容易错。

第二方面的话它就重复量很大，这也就是说为什么要提高更多的自动化的覆盖率，把可测性对吧？覆盖率提高，这样的话自动化的测试的话，它的价值是在于每次提交完代码之后，它都能够运行，它可能运行无数遍，这种无数遍的话就是它的价值，所以的话就强调这个东西，但另外回到刚才悟空说的这个东西，它的真正它的价值的体现的点，有可能的话对于低级的这种刚才再回到一开始说的测试，其实的话刚才好像卖了一大堆关子，其实它有两个目标，第一个的话叫做验证，第二个的话叫做探索。

那也就是测试的话，一方面是要验证，第二方面要探索，探索和验证的话，都可能是需求。验证这部分工作的话，他不好去给出价值，因为程序员的话一上来做完了之后，他是不是就得承诺交付一个能够用的东西，没做好是不是程序员的事儿，测试又有什么关系，对不对？可能恰恰是因为有测试人员的一个原因，造成测开发人员不太愿意投入精力，不太care这个东西，对吧？这个东西就不好去证明测试人员的价值。

但是另外一点，从探索的角度上讲的话，你这个产品形态的话，是不是需要探索更多探索，还是需要更多的验证。如果更多的验证你的自动化测试或者让大家主动去写出更多化的更多的自动化测试，而且覆盖了该覆盖的东西，这是第一点。对吧？

第二点的话就是大家的这种质量意识和测试意识是不是有效的得到了提高。整个的项目我们一般来考察的话，要么就更快，对吧？要么就更好或更稳，因为你不可能的话，因为你如果特别快做的特别快，吞吐量对吧？利碳都很高，但是有可能一一堆的bug产生对吧？但是如果你没有bug，有可能是你做的速度不够快，所以我们需要平衡这两个东西。

单独来看测试人员的话，我个人觉得的话也不好去证明测试人员，或者这个东西其实它是一个知识工作就说，你凭什么觉得比如马菲菲的写的文章更有价值，对吧？和悟空的这种文章的价值比，你是看它的点击率还是怎么着，对吧？有的时候很难讲这个东西，它是知识工作者，但是有的时候团队内部其实更知道这个人到底给团队多大的贡献，我觉得去证明测试人员的价值，一方面去听一下团队内部的一个评价，到底这个测试人员怎么样，没了他团队是不是ok，对吧？

第二的话就说出一些他做出的一些具体的东西，来证明测试这块是ok的。因为任何数据都可能造假，这个东西也有可能造假，所以这就造成了什么？我们什么都不能相信，我们既不能相信完完全全没有测试人员的，我们也不能相信的话，完完全全有测试人员，我们既不能相信测试左门，我们也不能相信测试在右门，我们应该怎么办？如果测试都在右门了，我们就把测试往左边放放，如果测试在右边，我们把测试往右门放，如果测试一一堆外包，那么我们就把测试人员的话往少的地方走一走。

如果测试人员太少的话，我们再把测试人员往多的方面走。

这就又让我想起了很多年前的话测试，圈子的话有一个一个调查，就是说你的团队有没有测试人员对你们整个团队的质量意识你觉得是高的？是有测试人员，你们团队质量意识高还是没测试人员，你们团队质量高？你们觉得结果是什么样？

应该是没有测试人员，我也觉得应该因为没有资源。

程序结果是有测试人员。

哈哈哈。

这也就是说你不能相信一切的，你们不要觉得我把测试人员干掉了，开发人员就有测试意识了，不可能有的时候不是这样的。

对，有的时候有一个人在这不停的喊，有可能才对你知道吗？所以的话分久必合，合久必分。

我们强调测试左移或者是前置，是因为测试之前太靠后了，系统的僵化是最错误的，所以我们不要想着敏捷讲的都是对，只不过原来太右，可能是我们现在往左边来点，如果太左了的我们再往右边来点，就这意思。

你刚才对，我觉得刚刚王老师讲的这些，让我一下子有一个有一个想法，也不是想法，因为我在现在我们所在企业里面有一些观察，我发现我们这个企业里面，因为它有大量的产品能力的集合集成的这部分的关键活动，而且涉及到软件和硬件在一起。

所以我观察到我们的这些测试人员，它其实是他在管理意识上，它在这个技术能力上，它确实都是相对来看是非常有敏捷水平的。

也就是说你刚才其实王老师问了个问题，说到底是有专业次人员，还是没有专业次人员团队会更有我的真正的体验确实是有专业的测试人员，大家会有更好的呃这个意识去去做这个质量配件，因为特别是我们的测试专家们，他们是真的非常懂，我跟他们打交道我发现但是他们普遍比我们遇到的架构师这一类的角色会更懂敏结研发本身的内核，比如说他们对于测试左移的理解，包括怎么去定义，前面有一个悟空也提到了，说我总不能定义成桌多少bug，是我的质量，是我的工作有机绩效对吧？

所以我们现在遇到的企业里面实际的情况也是我们的测试人员，他们也在尝试怎么去跟开发一起去定义，甚至是跟产品一起去定义质量，比如说产品你的需求写成什么样的是好的，所以它更多的是不仅仅是站在代码本身，它是站在产品角度去考虑，整个团队协作的角度去考虑我们定什么指标作为度量，我们本身我们一起协作，我们产品开发测试三大决策协作的一个能力，输出的产品功能是好是坏的，稍微举一个个小的例子。

比如说因为我们现在是去做一些能力改进，那么我们主线上的质量，我们的持续集成对吧？你应该是你的主干，随时都可以构建出一个潜在可交付的产品，这个是一个非常高级的高端的要求了。

那么我们的测试人员他们就会站在这个角度去定义一些指标，再把这个指标再分解到产品研发的，比如说前期你的设计活动，或者是你的技术设计活动，前面产品设计技术设计活动，最后有一小部分，我们不可避免的验证本身它很难有新的价值产生，但它必须要控控制我的投入，我做很多自动化去降低验证的成本。

对，所以刚才王老师一讲，我就一下子结合到我在现代企业里面的具体的小小的观察了，对。对，悟空你刚才好像要说什么，我打断你了。

没有，我觉得你这个话题也挺好的，例如说延展一下自动化的话题，用问题又来了，测试想要去做自动化的时候，它怎么跨越 Gap？他习惯了自己手工去测，你突然让它自动化，他突然就觉得工作量特别大，而且好像也没有什么意义，这个概括你没有。

我觉得这个的话是可以作为下一期节目的非常好的一个话题。

另外一点的话咱们去关闭一下这个话题，咱们今天这个话题也就是说测试人员的话会有两个专业领域发展，第一个的话就是验证专家，验证专家其实就已经往自动化专家方向看齐了，也就是我们希望更自动化的去验证功能。

另外一个专家的方向的话就是叫领域探索专家，那也就是它是在这样的一个领域的话，它能够探索更厉害的一些东西，它就像一个怎么说，就像个海盗似，它能更好的去找到一些东西，对吧？这是它另外一个方向，而且现在已经比较明确的话，有一种趋势的话，测试和验证这个事的话，逐渐向研发团队的话或者是研发人员靠齐。

所以的话那给测试人员的话要求因为他的职责渐渐的划走了一部分，所以对测试人员的要求会更高。这也就是说测试人员的这种技能短板和人才短板的话会更加明显，我觉得这就是我想关闭想说的这些话，对你们俩好。

悟空也来关注一下，来。

我觉得我又想关闭又想开放，我就不接着开放。

我听王宇老师讲这个东西，我想到一个东西就是职业发展技能术，我觉得绝大部分现在发让他们去做一些或者说引导他们去做一些突破，我会发现很后继无力或者自身感觉没痛点的地方，就在于说他不知道自己未来要往哪个方向发展，然后发展那个方向又需要掌握什么样的技能，我在想是不是有这样的职业技能术给到他们，然后能够很确切的看到有这些方向，你可以去选择它，不至于就困顿于当下的这一种困境之中，然后选择一个方向之后慢慢也就有动力了，有了动力之后，很多事情也就顺水偷偷就成了，否则你告诉他应该这么做，但你又不告诉他发展这个东西，他未来怎么能挣更多的银子，他就会做的比较迷茫。

对，所以我觉得想到这一些是好。

我也来关闭一下，咱们在今天录音之前，我刚好看到朋友圈有人在转发关于阿阿尔法扣的这种人人工智能编程的新闻，其实关于人工智能AI去编程，这也不是什么新鲜事了，我们大家应该都是说对这个东西未来它会到什么程度，心里应该都有数。

所以我其实在我心中，我一直觉得我们要面向未来去工作的话，那么我们作为一些软件行业的从业者，可能未来来看做好良好的架构设计，可能代码确实不会再大量的由人手工去编写，那么我觉得测试人员在这个活动中它具备的专业能力，它能面向一个软件产品提出一个正确的问题，后面可能很多事情其实是要交由将来来看，可能甚至是可以交由AI去实现就好了。

那么我觉得我们所有的软件人员的其实最核心的就是我们需要这一块软件解答什么问题，这个就是我们要提的。

那么我们要提出这个问题的话，可能将来的软件行业甚至可能不会有这么细的分工，有可能我们都是既是产品又是测试。对，所以我稍微有点发散，我觉得从如果说我们今天的一这一期节目主要也是想可以献给我们的身边的这些测试的专家伙伴们的话，其实我是非常尊重他们在这个岗位上付出的劳动的，还有我也非常欣赏他们中很多人这个思维非常的敏捷，然后我也希望说可以借着今天的沟通，说希望有一些在测试行业里面的工作的伙伴们，大家可以更好的去理解未来是什么样子，然后我们一起去把这个事情做得更好。

对的对。

我也想在此机会的话，对这些我遇到过的或者我没遇到过的非常专业的测试人员表示敬意，因为有的时候的话，敏捷圈子很多人的话，有的时候有一些自大，或者是他想用一些口号性的东西的话，我有博出一些眼球来，但是真正做事的话需要一步一步的去做的非常的到位，非常聪明，非常有担当的这种测试人员，我觉得功不可没，感谢你们。

是感谢，谢谢感谢，好。

咱们下次节目见。

今天时时间差不多了，下次节目见，好拜拜。Bye bye。