SAP成都研究院郑晓霞：Shift Left Testing和软件质量保证的一些思考

时间 2019-11-19

标签 sap 研究院 shift left testing 软件质量保证一些思考栏目 SQL 繁體版

原文原文链接

今天的文章来自Jerry的同事，曾经的搭档郑晓霞(Zheng Kate)。郑晓霞是在Jerry心中是一位颇有实力的程序媛，2011年从西安某软件公司跳槽到SAP成都研究院。当时，成都研究院的CRM团队刚刚成立，Jerry和郑晓霞都在一个大组。正则表达式

2012年夏天，咱们接到任务，要把SAP Customer Briefing这款已经发布的iOS应用移植到Android平台。由于只有1年的期限，老板组建了一只特殊的开发团队，由Jerry, 郑晓霞和另外两位男同事组成。是的，由于需求很清楚，就是把iOS版本上的功能移植到Android平台，因此这只团队没有产品经理，没有架构师，郑晓霞担任了开发人员和Scrum Master的双重身份， UX也是项目中后期从上海找了一位同事远程加入项目组。因为咱们4位之前都没接触过Android开发，所以也是边学习边干活。这个微型团队的学习气氛很是好，一我的遇到困难，其余三位都会积极热心参与讨论和提供帮助。编程

Jerry印象最深的一件事是，当时我负责实现一个company profile的功能，即客户能够从一个下拉列表里选择一个企业，从而进入该企业明细页面，显示该企业的概述，包含文字简介，企业人数，财政收入等等。概述信息经过消费wikipedia提供的Restful API，传入企业名称，返回响应，其中须要显示在明细页面里的关键信息得经过编程人员本身写正则表达式提取出来。安全

Jerry当时的想法是，把iOS版本里解析正则表达式的Object C代码直接改为Java代码，由于不一样编程语言里使用的正则表达式，其语法虽然稍有差别，但语意是相同的。但当我阅读了一段时间iOS代码那些操做正则表达式的Object C代码后，已经头昏脑胀了，个人Java代码写好后进行测试，发现并不能保证对全部测试输入的company, 都可以用正则表达式正确地解析出关键信息。session

而后Jerry说，算了，我不参考iOS代码，我直接本身从头写吧。写完后测试，发现仍然不能保证对于全部的测试数据都能正常工做。架构

看到Jerry陷入进退两难的境地后，晓霞同窗像女神通常出如今我面前，说：“我来试试”。一个下午过去，晓霞同窗提交了一段代码到perforce上，那是一段结构清晰，而且可以完美使用正则表达式完成关键信息解析的Java代码。我使用了一百多个company进行测试，所有工做正常。实际上，直到最后发版，晓霞同窗这段代码也没有发现任何bug。编程语言

当时晓霞同窗在Jerry心中的形象和这位潇洒的警察同样：ide

这件事让Jerry今后对晓霞同窗另眼相看，一直到如今。工具

下面是晓霞同窗的正文。性能

你们好，我是郑晓霞，如今是SAP成都研究院Hybris Enterprise Commerce Platform开发团队的质量工程师(Quality Engineer, 下文简称QE)。今天我想和你们聊聊我在这个岗位上工做一段时间以后的一些心得和体会。单元测试

在敏捷开发模式下，团队须要有持续快速的交付能力。那么在持续交付过程当中，如何保证产品质量呢？你们的答案多是自动化测试。

可是自动化测试是否足够、有效，即便足够、有效，就能说明产品质量好吗？测试结果只是一个指标，这个指标表明的只是在当前的测试环境下，现有测试实例的运行结果，是咱们保证质量的下限。

软件质量不是测试出来的，而是在开发过程当中创建起来的。控制开发过程当中的质量有助于提升产品的质量上限。

Shift Left Testing，通俗理解就是把位于传统软件开发流程中最后阶段的测试往前提。提到哪一步呢？开发？设计？需求？我我的的理解是越往前越好。这意味着在整个开发周期内须要持续测试，持续关注质量，这一切都是为了提升质量的上限。

这会带来什么好处呢？

1. 减小测试和开发的成本, 提升投入产出比ROI(Return On Investment)

在软件开发的整个过程当中，越早发现问题，修复的成本越小。

试想在所谓的集成测试阶段发现一个bug，花时间部署测试环境，准备测试数据，执行测试，重现bug，跟开发人员沟通，将bug分配给开发人员后，他/她们可能须要从新部署开发环境，从新开发，从新作代码审查，最后再走一遍测试流程。若是能在代码审查或者单元测试阶段发现这个bug，得节省多少时间？

2. 提升测试效率

若是能在需求，设计阶段能发现并阻止bug，能够节约不少开发生命周期的反复，同时在理解需求、代码的基础上进行测试，能够更有重点和针对性地面向业务和风险测试，而不会陷入测试细节，有效提升测试效率。

3. 提升质量

在需求层面保证并优化需求以及需求传递的质量，在代码层面保证设计的灵活性，代码的整洁性，在开发过程当中控制质量，提升产品内部质量。

Shift Left Testing是须要整个敏捷开发团队做为一个总体去遵循的。那么在一个敏捷开发团队中，做为一位QE，在整个产品的开发生命周期中须要怎么和团队合做呢？

1. QE做为敏捷开发团队的一员，能够作任何能帮助团队提升质量的事情，没有界限，目的是为了帮助团队发现问题，解决问题，提升产品交付质量。

QE要能作到没有界限地提供质量保证，须要自身作出两个重要的改变：

(1) 全方面地提升本身的技能

若是缺少相关的技能，好比业务能力和必定的代码能力，很难想象QE可以高效地参与到各个开发环节的讨论中，更谈不上能给出建议和意见。固然这不意味着必须让QE成为一名全栈工程师。QE须要去找到学习的平衡点。有些技能可能不是必须的，可是若是具有这些技能，会让QE以更加高效的方式作事。

(2) 深刻到软件开发生命周期的各个环节，紧跟团队的开发节奏

若是不深刻到开发的各个环节，有些质量问题的根源无法找到，那么提早阻止bug也就无从谈起。只带着耳朵听，是无法深刻的。须要思考，从质量的角度去思考，可是若是技能差距太大，能勉强跟上节奏也就不错了，谈不上思考。因此深刻软件开发周期各个环节须要QE自身技能的支撑。

同时，QE在参与的过程当中，须要把握好平衡，能发现问题，也须要让团队各个角色可以各司其责，维持健康的团队工做模式。

2. QE须要培训团队，让团队可以拥有测试技能和质量意识，并可以本身解决问题，同时不断提升质量。

产品质量由敏捷开发团队来保证，常常听到有同事说，”咱们的QE还挺厉害的，测出了很多问题”。在一个敏捷开发团队中，只有一个QE，靠一我的的英雄主义，测这么多问题，若是QE休假了怎么办？能对团队的质量放心？

QE的成就感不在于“我有多么重要，测出了多少重要的bug”，而是“没有我，团队的产出仍然是高质量的”。要达到这个目标，QE的任务就是挖掘团队的质量需求，培训团队，让QE变得愈来愈“多余”，使团队成为一支“去QE化”的敏捷团队。

这两点看似矛盾，实则第一点(帮助团队发现问题)是为了有方向性地支持第二点(如何培训团队本身解决问题)。随着团队愈来愈成熟，这两点也就慢慢地越作越少。

那么质量是否是越高越好呢？质量是要付出代价的，须要控制成本和产出。举个温伯格提到的例子，MiniCozy公司的文字处理软件，在对一整本书进行排版时，会出现漏词的错误，而这个错误确实发生在一个做家的处女做上。可是MiniCozy公司的回应是，在数以十万计的用户中，或许都找不到十我的会把这样大规模的任务用单独的一个文件来组织，修正这个错误可能会花不少时间和成本，而且还有可能引起更大的错误，从而影响到几百甚至是几千位用户。MiniCozy认为他们的取舍是正确的。因此质量不是指毫无纰漏，而是有其相对性。

下面我列出了在软件开发生命周期的各个环节里，QE可以作的事情，可是QE不是必定须要参与，参与的目的是为了发现问题，最终是须要培训使得团队可以具有质量和测试相关的知识和思惟，经过改进流程，行为让团队本身保证质量，并不断改进。

根据每一个组不一样的成熟度和QE技能的高低，事情可能会有所不一样。

为了图表的简化，只列出了事情自己，下面会有简单说明作这些事情的目的。

Before coding - 开发开始前

1. Involve requirement discussion early

在作产品开发前，咱们应该理解需求背后的缘由，客户遇到什么问题，咱们可以帮客户解决什么问题。咱们测试的不只仅是产品功能，更是业务价值。提早参与需求的讨论对决定测试的重心，优先级都有极大的帮助，避免陷入辛苦的测试细节中。这样咱们就能够有效的利用Pareto的20/80原则，提升测试效率。

2. Ask negative questions

每一个人均可能受惯性思惟影响，咱们能够经过问负向问题来优化功能性需求和非功能性需求的测试, 好比产品标准和GDPR(General Data Protection Regulation)等。

3. Collaborate with testable and executable acceptance criteria

Acceptance criteria主要关注的是业务价值，创建user story的功能范围，并能指导开发。经过各个角色合做讨论的方式列出acceptance criteria，可以避免对需求范围的误解，同时参与的每一个人都能很清楚的知道要测什么，要怎么测。

4. Work out test plan in sprint

在敏捷开发的每个sprint内，咱们也须要基于sprint目标制定测试计划，包括哪些功能须要手动测试，哪些功能须要自动测试，哪些功能须要回归测试，是否须要作性能测试/安全测试等。同时还须要计划对以前的测试作维护。这个测试计划会影响到sprint planning meeting对任务的分解和时间估算。

5. Join estimation proactively

在sprint planning meeting中，基于制定的测试计划，积极参与对任务的分解和时间估算，包含相关测试的开发、维护和执行时间。

6. Design and prepare test points with good test data including automation test

这些实际是传统的瀑布开发模式须要的测试相关的专业知识，一样也适用于敏捷开发模式。经过各类方法论的使用，设计出测试点，来指导、优化测试执行，提升测试效率。在敏捷开发模式下，QE须要让全部成员都具有这种测试设计技能。

7. Define KPI/Dashboard

团队须要定义如何来度量质量，KPI(Key Performance Indicator, 关键绩效指标)的度量值能直接反馈出团队的外部质量，并能够经过根源分析帮助团队认识问题，解决问题。

During coding - 开发过程当中

1. Join or familiar with design

虽然敏捷开发模式并不像瀑布开发模式那样具备专门的软件设计阶段，可是小的功能点设计在每一个sprint确实存在。不一样的设计有不一样的测试考虑，好比经过事件来触发订单流程，或是经过后台做业来触发订单流程，测试要验证的点确定是不同的。若是采起后台做业方式，还须要验证做业信息和计划的执行时间是否正确等等。

同时咱们须要在设计时考虑可测试性。软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在必定的时间和成本前提下，进行测试设计、测试执行的能力。James Bach 这样描述可测试性：软件可测试性就是一个计算机程序可以被测试的容易程度。

好比，为了测试一个类的方法，首先咱们须要建立这个类的实例，须要引用必须的内部依赖，同时还要隔离外部依赖。有的场景下作到这些并非那么简单，因为开发人员容易局限于考虑本身负责的功能的具体技术实现而忽略了设计的可测试性，而QE参与功能设计则能够提升开发人员对确保其设计的可测试性的意识。

2. Guide/coach/pair to develop testable code and effective test code

可测试的代码是写测试代码的前提条件。测试代码的做用毫不仅仅是用来知足测试覆盖率的，测试代码须要基于测试设计和测试数据来测试软件的功能，因此须要QE能和开发人员一块儿保证测试代码的有效性。一旦发现bug，除了修复bug自己，还须要评估是否须要改进现有的测试代码来覆盖这个bug。

3. Go through code for both functional code and testing code

以QE的角度检查代码，好比需求是否匹配，是否考虑了SAP产品标准等等，从这个角度检查既有助于发现问题，同时能够提升测试效率。好比，代码添加了新方法来获取当前时间，时间和格式是否作了本地化处理？这个新方法是否被调用了？若是都没有符合，那还须要继续功能测试吗？在这些缺陷弥补以前，固然没有必要进行功能测试了。后面咱们还会追溯为何会有这种状况发生。

4. Safeguard DoD compliance

由于咱们是作产品，只有知足了DoD(Definition of Done, 完成的定义，敏捷开发里的一个术语，表示工做是否完成)，user story才能算完成。咱们必需要严格遵循，这样才能持续交付，而且避免技术债务。

5. Utilize continuous integration environments

经过集成各类代码扫描工具，利用持续集成来发现问题，提供质量的快速反馈。

6. Test an uncompleted user story

一般一个user story不会太大也不会过小，在团队还不够成熟的时候，QE仍是须要测试user story。为了避免在sprint末期出现测试的“惊喜”和大量测试任务的涌现，咱们能够和开发商量，讨论出哪部分功能能够先开发。等这部分功能开发结束后就能够开始测试，即便这个user story尚未完成。

7. Provide fast feedback

除了持续集成以外，QE须要对开发的bug提供及时快速的反馈，由于开发人员熟悉业务和代码，可以比较快速地解决问题。另外一方面这也能够做为考虑如何提升质量的on-job培训的一部分。

After coding - 开发结束后

1. Test user story based on business value and risk

在团队还不够成熟的状况下，QE还须要基于业务价值和风险来测试user story，测试的粒度和范围能够根据团队的具体状况进行调整。

2. Hold another bug hunt or other manual exploratory testing session

基于user story的KPI，重要性和风险程度，咱们须要决定是否再须要一轮测试。

3. As problem solver to analyze issue and find how to resolve issue

QE发现了bug，报告给开发后，QE的任务就完成了吗？QE能够经过现象，日志等分析问题，定位问题，提升问题的解决效率。

4. Reflect AC/DoD/Test plan/test case/test data

回顾以前作的一切和测试相关的活动，从中总结经验教训，作到持续改进。好比上个sprint的test plan实际执行状况如何？设计的test case覆盖到了全部场景吗？准备的测试数据质量如何？测试活动中有哪些方面下个sprint能够作得更好？

以上仅仅是我的观点，欢迎共同探讨学习。

下面是我在思考本身做为一个QE在团队中定位过程当中参考的一些网站和博客。

相关阅读

要获取更多Jerry的原创文章，请关注公众号"汪子熙":