优品软件培育计划【第八期】—— 敏捷测试 回归本质（上）
2021/01/27
优品软件培育计划百场前沿技术系列讲座直播的第八场邀请到的是Micro Focus资深技术专家陈学锋，他从业18年，在开发，测试，项目管理和运维领域都有丰富的理论和实践经验。对DevOps和Agile有深刻的认识，积极推广自动化领域的技术和测试的AI技术，如：测试自动化，测试AI和RPA机器人等。
现将整场讲座的内容整理出来，供大家继续学习使用。另外讲座现场还有一些问题未来得及解答，已经整理出文字解答附于文末，请需要的朋友拉至底部自取。
敏捷的本质就是一个团队、两个工具、三个角色、四个仪式
开发人员，他们也需要改变思维，从把代码提交了就行了，到我如何帮忙创建可测试的代码。
大家都有deadline的压力，在压力之下，大家都会去借时间，找捷径，这样就会省略很多的事情，这样有一个概念叫做技术贷款。
敏捷团队开发测试配比，就算是12:1，也能做。
如果有条件，我们还是一定要把性能的指标构建到前期的发布要求中。
敏捷测试的大势所趋已经很久了，不知道大家是否还记得敏捷测试的初衷？敏捷测试的本质是什么？敏捷实战中的灵魂是什么？下面是今天议题的大纲，我们会一起探讨软件的变革，聊聊敏捷测试的本质，并以性能测试为例，去聊聊如何落地。
回顾2020年，疫情进一步推动了数字化的进程，大家的习惯也都有了一个很大的改变，几乎是重新培训了一次全民的网络习惯。企业办公方式的改进以及数字化的普及影响了全民的娱乐、生活和工作，数字经济也得到了飞速的发展。大家近期如果有看新闻联播的话，也可以听到大量的数字化的话题。企业通过数字化去重构线上和线下的业务、整合渠道、重组产品的生态，目标其实是降本增效、谋求发展。这种重构其实是线上线下的融合，或者说是数字世界跟物理世界的融合。这个背景就让软件的驱动再次地复兴起来，软件是这场数字化的一个关键。简化来讲就是开发新的模式，客户的价值可以快速地实现。其实我们还需要去简化运营，企业才能赢得竞争。这其中软件质量的高低就起了一个关键的作用。
现代化的软件需求是巨量的，大家都在抢占市场，既要提升对客户的吸引力又要保证保留率，在这里我们可以提炼出几个关键词：巨量、快速、吸引力、保留率。从技术层面去提炼就是：速度、质量和规模。所有的公司都迫切地希望可以快速地交付高质量、高性能且令人满意的应用。我们要去实现速度、质量和规模之间的完美平衡，所以我们今天的重点就是去讲，如何实现这样一个平衡。我们强调说，敏捷不要虚的。我们可以去回归本质。把虚的东西都剥离后，敏捷其实就是团队+角色+工具+仪式。我们展开来跟大家分享一下敏捷的本质，先看团队，敏捷强调的是一个团队，敏捷是真正的团队作战。通常传统意义下，团队是按照角色去进行分工，开发人员只管开发，测试人员只管测试，对于自己职责外的事情，要么看不见，要么觉得“不是我的活，我可以不用去管”， 做好做坏跟自己都没有关系，敏捷恰恰相反，它强调的是Whole Team，是整个团队对外做出承诺，所以团队中的所有人所有的开发、测试、文档等任务负有责任。这也叫角色的模糊，这些都是一些基本的概念，相信大家也都比较熟悉了。
某一个开发人员或者测试人员做的再好也没有用，不能按时交付高质量的软件，就是整个团队的责任。
再看角色的话，我们只需要仅仅抓住这三个角色，就可以抓住敏捷的关键。第一个是产品的拥有者，产品的拥有者代表的是最终用户，他可以去定义价值的优先级、产品的代办项。第二个是Scrum Master，他主要是去做指导和激励团队的成员，确保过程的顺利进行，消除影响生产力的障碍，组织重要的事件跟会议。第三个我更喜欢称其为“交付团队”，原来有很多像QA、开发、架构师、业务分析师这样的角色，因为我们前面提到的，要把角色去模糊化，所以我们可以统一一个称呼，或者统称为一个团队，最重要的其实是“交付”。这个团队会去决定哪些用户故事是sprint的一部分？成员具有专门的技能和重点领域，测试开发，运营，业务分析都在里面，模糊其实只是针对问责来说，目的是为了促使团队成员形成一个当家作主的精神、集体的荣誉感，相互提携，共同进步。再到工具，本质上来说，其实只需要两个工具就够了，燃尽图跟看板。燃尽图的话，在敏捷里面是说，预计何时完成这个工作。看板其实是可视化工作跟进度。说到本质，我们在很多时候就是抓重点，这两个就是敏捷开发最大的两个重点，我们知道要做什么，知道现在的进度，接下来去做很多具体的工作。
第一个，Sprint计划，在这里需要去定义在这个或者下个sprint中，我们需要去处理哪些用户故事？在做计划的时候，是交付团队和scrum master去做这个事情。做完之后，就有一个成果的展示，团队向产品的所有者去展示他们在sprint中交付的内容，所涉及到的角色就是产品的所有者、交付团队和scrum master一起去做这件事情。做完以后，另一个很重要的工作就是sprint的回顾，在sprint之后我们要进行一个会议，以便审核，回顾回顾再回顾以及经验教训的一个总结，这个是交付团队和scrum master一起去做的。另外一个很重要经常要做的就是“每日站立”的仪式，每天15分钟左右，大家站在看板旁，一起看看昨天做的事情怎么样了，今天要做什么事情？有什么障碍？我们中间去交流，又回到刚开始说的，一个团队，出了问题大家可以一起去帮忙。一起去做这件事情。那中间的思维怎么去做转换？在后面的内容里我们会去分享给大家。我们总结一下，敏捷的本质就是一个团队、两个工具、三个角色、四个仪式，我们就抓到敏捷回归本质的要素了。
另外敏捷本质的关键，其实是质量，前面我们也介绍了现在的情况是什么样的，我们要实现真正的价值，关键中的关键其实是质量。我们其实都经历过最终期限的压力，敏捷的本质不是快速，当然我们非常理解，当到家遇到业务上的一个最终期限的压力的时候，其实非常容易就会选择寻求捷径。敏捷要快速，当然也是对的，但是其真正的本质是更加频繁地交付，高质量地交付。这个“高质量”是必须highlight出来的，所以在敏捷团队中工作的时候，我们怎样去落实？敏捷的理论大家都很认同，但是做起来，很难做，所以在这次交流讲座中，也是侧重怎样去落地，有没有一些技巧，方法论去做这样一件事情？有没有一个方向可以让我在平时的工作中做到真正的敏捷？提高敏捷的水平，其实需要从思维的方式、提升技能、整个团队的参与、聚焦质量这四个方面去展开。接下来我们就一起看一下，如何实际落地去工作。改变思路，我们需要开放实时纠正这种思维方式，图片上这个火车，其实有很多办法可以到达终点，我们可以采取许多不同的路径，还没走的时候，我们其实是不知道哪条是最正确的，所以敏捷提倡实时的纠正。我们去实时改变信号，火车才可能真正到达想要去的终点。所以为了提高质量，我们需要不断地回顾，设定目标，进行测试，进行改进。我们有时候可以跟测试人员去聊，你认为你的工作职责是什么？他们常常会说，我需要去找出缺陷，找出bug，或者说看看需求是否得到了满足，或者更极端的会回答，我们就是去把这个系统搞瘫。这些思想从严格意义上来讲，都不符合敏捷测试的思路。不知道大家有没有这样的想法。或者说你的团队是不是也是这样想的？更好的思维是，希望测试人员多问，我能帮助你做什么？这才是协作的一个思路。所以从找茬到帮忙，这是思路的一个很大的转变。但是找茬的工作需要做吗？需要的。我们改变思维的话，只是说，我们从帮忙的角度去切入，这就是一个很大的敏捷思维的改变。其实不只是测试人员需要改变他们的思维，包括开发人员，他们也需要改变思维，从把代码提交了就行了，到我如何帮忙创建可测试的代码。这点不知道大家在工作中有没有去认识到，叫“可测试的代码”，这一定要跟团队里的开发人员去进行沟通，达成这样一个共识，促进他们有这样一个思维的改变。需要补充一点，很多时候开发人员会去测试自己的代码，他们做得非常好，只是有时候针对程序的一些分析他们看不到，因为他们关注的还是自己的那一小部分，而不是大局。如果开发人员从一开始就考虑到测试了，这其实是一种很大的进步了。更贴近整个团队从一开始就考虑测试，大家可以更好地去合作，这个其实是现在也很热门的一种理念，叫测试左移。测试左移在敏捷里面肯定是要的。测试左移就需要测试人员在里面去做到一些引导和培训，或者说跟开发人员来配对一起去做这件事情。总结来说，事情还是原来那些事情，只不过想法不同了，效果就不一样。第二个是说需要提升技术，提升整个团队的技术，今天我们侧重谈的是测试人员需要提升的技能。说起技能，大家也会非常熟悉下图这个模型，叫“T型模型”，分成广度跟深度，在敏捷开发中，我们应该重视的是能力而不是角色，所以从广度上来说，比如说我们有一些编程的语言，可以很方便地去跟开发人员做结对，使得测试更自动化。这个自动化会在单元、组件或者功能的自动化上可以和开发人员一起做结对。如果有数据库的知识，就可以跟数据库的管理员合作。知道的越多，就能考虑到更多原来考虑不到的盲区。深度上就是说，我有专业的技能，像功能测试应该怎么做，要注意哪些东西？测试用例应该怎么样去写，怎么样去关注，性能测试专业知识就能够很容易提升软件性能上面的把握。对于功能自动化测试的钻研，确实能够提升整个团队的测试效率 。
所以广度和深度就是大家要有很广的知识，要有自己比较有深度的技巧，后面一个是叫软技能，会沟通。这里要提到一个现状，很多人都不喜欢听到测试人员说的话，因为测试人员一般只要一说都是比较坏的方面，这里有bug，这里有缺陷，马上要去改，所以要学会如何很好地去传递这些信息。软技能在敏捷测试里面也是很重要，可能大家会比较容易忽略，其实有了这个软技能，大家会协作，后面才会比较顺畅地一起去完成一件事情。所以测试人员应对敏捷，说大了要学习商业语言、业务语言，还要学技术团队的语言，这样我们可以跟业务人员去做沟通，跟技术人员去对话。另外一个是倾听，因为客户也会有很多隐藏的假设，他会觉得，你其实已经知道了，或者你的整个团都都已经知道我的业务的逻辑，但其实你不知道。所以会倾听也是软技能的一个重要部分。第三个是对开发的技能，其实并不是说测试人员要成为编程人员，团队里面已经有编码的人员了，我们前面也说了，我们在做单元组件自动化测试的时候，就可以跟开发人员去做协调、配合，他们做这块有先天的优势，因为他们可以很快的写代码，但是他们也有一个天生的弱势，就是他们可能没有大局观。我们可能更需要业务上的一些逻辑和真正专业的一些测试知识，这个是需要帮助开发人员去做提高的。另外，如果我们能够了解更高级的high lever的系统架构，有利于帮助团队去考虑这些风险。有一个很好的办法 ，在每天的例会上，我们可以找开发人员在白板上把某些阶段系统的构架信息画一画，讨论讨论，这样就很容易能找出软件存在的潜在风险，可以找出哪些是架构上的脆弱点。提升技术还有一个非常重要的点，叫领域技能，不知道大家有没有关注过，这个是可以帮助团队去增加质量上的价值，或者说客户价值的体现，因为我们要实现这个价值，除了代码上，还要放在业务上，如何实现业务目标，怎样才能使业务成功，为最终用户带来价值，这样需要团队里的每个人，特别是测试人员要投入时间去学习这个领域，去了解企业怎么运作，我们开发的这个软件或应用相关的人他们如何去工作，要成为深度的业务域的一个专家，这样才能更好地帮助我们解决业务问题。
这个也是说起来很容易说，怎么落地呢？首先我们还是说，我建议跟业务的客户坐在一起去聊一聊，可能大家也会说，我们的工作模式不可能接触到客户或者说比较少接触到客户，特别是测试人员，如果接触不到，可以尝试去找找公司的客户支持人员，问问他们在支持这个应用的时候，哪些地方会更容易出事情？那这个方面我们后面就需要做更多的测试，更多的回归测试。领域技能是很重要的，如果没有这种环境的话，还是要去创造条件去了解用户是怎样工作的，实在不行要跟产品的owner一起去推进这个事情。
我们再看一下第三点，是团队的参与，敏捷要求整个团队对价值负责，对质量负责。需要全队的参与，在传统的测试中，都是到了一个阶段我们才去做这件事情，敏捷是随时随地地去做。落实全团队的参与的时候，需要在团队设计在设计如何实现功能的时候，在一开始就要去想如何去做测试。每个人都要去想想怎么做测试的story，每个人都要想想，如何让代码能被测试。如何让代码能被测试如果没有在团队中取得共识，开发只是去做自己的事情，那他的代码很可能是很难被测的，取得共识，这个是最大的一个挑战。第四点是，聚焦质量而非速度，这个是敏捷本质的一个关键跟重点，敏捷是快，这是对的，但是敏捷不等于快。敏捷更多的是聚焦在交付的价值上。
大家都有deadline的压力，在压力之下，大家都会去借时间，找捷径，这样就会省略很多的事情，这样有一个概念叫做技术贷款，你最终是要还利息的。“出来混，迟到是要还的”，这些被省略的事情，迟早还是要去做的，越晚去还这个贷款，后期就会越慢。我们总是强调速度第一，后期就会越来越慢。质量第一，后期才会越来越快。
