三步实践“验收测试驱动开发” 让团队交付正确的软件 葛锋 测试自动化教练 诺基亚西门子杭州研发中心.

Presentation on theme: "三步实践“验收测试驱动开发” 让团队交付正确的软件 葛锋 测试自动化教练 诺基亚西门子杭州研发中心."— Presentation transcript:

1 三步实践“验收测试驱动开发” 让团队交付正确的软件 葛锋 测试自动化教练 诺基亚西门子杭州研发中心

2 摘要 案例背景 如何做到的 ATDD的几个常见问题 三sprint实践ATDD

3 三步实践“验收测试驱动开发”——让团队交付正确的软件
案例背景（问题解决前的糟糕状态）： 在每次迭代开发开始之前，团队均会召开会议商讨开发的内容，以及相应的测试用例。但真实情况是，貌似大家都已经讨论清楚的内容，实际上并没有达成统一性的理解，因而就存在了过度开发或开发不足的问题，最终导致在迭代结束的时候团队并没有交付完全正确的特性或软件；更胜的是我接触过的一个团队因此原因导致整个迭代的直接失败。 b) 此案例实施后达到的目标： 让团队掌握实施ATDD的实践方式，以此对需求达成统一共识，最终构建出正确的软件。

4 怎么做到的（思路） 理解人性，从团队愿意采用的方式切入，降低抵触情绪 适当经历曲折与错误，帮助团队摄取经验与教训

5 ATDD的几个常见问题

6 1.验收测试用例讨论与编写的时间 GOOD 组员：Sprint开始之前的grooming会议上讨论，会后编写完成
我：你们是在什么时候讨论和编写的验收测试用例 组员：Sprint开始之前的grooming会议上讨论，会后编写完成 GOOD

7 2.验收测试用例的数据与存储 我：这些用例是以什么样的方式存储，含有测试数据吗 组员：我们放在Excel表格中，基本都是描述性的 BAD

8 3.验收测试用例的维度 我：你们是不是在一开始压根就没有考虑过性能的验收 组员：我们开始不觉得性能是个问题，不想最后会成这样 BAD

9 4.验收测试用例怎样执行 我：你们是怎样执行验收测试用例的，谁来执行的？ 组员：当然是测试人员，一般采用手工的方式 BAD

10 三Sprint实践ATDD

11 第一个Sprint

12 讨论并设计完可测的关键测试数据之后，我们都知道了特性的scope。随后我们准备将验收测试进行自动化，但紧接着问题就来了
谁来负责编写验收代码？ 用基于关键字的框架还是纯脚本语言？

13 关于谁来编写验收测试代码 开发：我的开发任务很重，很难有精力还要写验收测试 测试：功能都没有实现，怎么来编写验收测试代码

14 既然各有难处，且都没有相关经验，我决定作为一名测试开发人员的角色帮助他们实现验收测试代码，以帮助他们认识到可行性和积累相关经验。

15 用基于关键字的框架还是纯脚本语言 我：验收测试代码后续是交付给你持续测试维护的，你觉得哪种你更擅长？
开发：当然是纯脚本的语言，编写更类似于高级语言

16 验收测试代码片段

17 我和开发人员配合得很愉快，在验收测试代码基本完成后，我将所有权传递给了开发人员，每次他有小的代码改动都会运行一下验收测试脚本，如果没有问题就交给测试人员。这做到了开发自测，并且测试效率很高，开发和测试都很happy

18 一切看起来似乎都很好，但问题在sprint review会议上出现了

19 当PO看到测试脚本的console output不断打印着输出时，一脸疑惑
你们是怎样设计测试的？测试数据在哪里？这些不断输出的内容是什么？

20 我们让团队满意了，但没有让PO满意，PO并不关心测试实现

21 PO喜欢怎样的实现呢 我：你喜欢怎样的测试结果展示呢？Robot Framework那样的方式吗？

22 第二个Sprint

23 团队开始自己实现验收测试代码 我们在设计和编写测试代码的时候，注意上下层次分离，即测试需求和实现分离。 在review meeting前，针对PO的需求，我们采用robot framework替换python展现测试需求和数据，同时也保留python的方式，因为开发倾向于此种方式。

24 PO很满意，同时团队也意识到基于关键字驱动的测试框架更利于展现测试需求，因为它结合关键测试数据、基于自然语言描述，更接近于需求文档。

25 既然大家都认识到这点，并且已经掌握了上下层分离，下一个sprint似乎就不需要上层的python实现了。

26 第三个Sprint

27 我们将关键测试数据填写在Robot Framework的表格中，辅助以下层的python测试实现。

28 至此，团队已经理解了ATDD存在的意义和价值，以及相关的技能。
Celebrate时刻？ 为了让自动化测试用例成为活的需求文档，我们还有很长的路要走！！

29

30