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

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

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

这件事让Jerry从此对晓霞同学刮目相看，一直到现在。

下面是晓霞同学的正文。

• • *

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

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

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

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

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

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

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

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的任务就完成了吗可以通过现象，日志等分析问题，定位问题，提高问题的解决效率。

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

回顾之前做的一切和测试相关的活动，从中总结经验教训，做到持续改进。比如上个sprint的test plan实际执行情况如何的test case覆盖到了所有场景吗的测试数据质量如何活动中有哪些方面下个sprint可以做得更好p>

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

下面是我在思考自己作为一个QE在团队中定位过程中参考的一些 站和博客。

• https://blog.testlodge.com/th…
• https://blog.testlodge.com/qa…
• https://abstracta.us/blog/sof…
• https://abstracta.us/blog/sof…
• http://www.thinkinginagile.co…
• https://www.mountaingoatsoftw…

相关阅读

• SAP成都研究院DevOps那些事
• SAP成都研究院姚瑶：软件质量保证工作的变迁

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92624 人正在系统学习中 相关资源：基于单片机的智能灌溉喷洒系统的设计_单片机灌溉喷头-单片机文档…