开发”让团队交付正确软件.pdf

三步实践“验收测试驱动开发”让团队交付正确的软件葛锋测试自动化教练诺基亚西门子杭州研发中心揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 摘要�案例背景�如何做到的�ATDD的几个常见问题�三sprint实践ATDD揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 三步实践“验收测试驱动开发”——让团队交付正确的软件a)案例背景（问题解决前的糟糕状态）：在每次迭代开发开始之前，团队均会召开会议商讨开发的内容，以及相应的测试用例。但真实情况是，貌似大家都已经讨论清楚的内容，实际上并没有达成统一性的理解，因而就存在了过度开发或开发不足的问题，最终导致在迭代结束的时候团队并没有交付完全正确的特性或软件；更胜的是我接触过的一个团队因此原因导致整个迭代的直接失败。b)此案例实施后达到的目标：让团队掌握实施ATDD的实践方式，以此对需求达成统一共识，最终构建出正确的软件。揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 怎么做到的（思路）�理解人性，从团队愿意采用的方式切入，降低抵触情绪�适当经历曲折与错误，帮助团队摄取经验与教训揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ ATDD的几个常见问题揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 1.验收测试用例讨论与编写的时间我：你们是在什么组员：Sprint开始之时候讨论和编写的前的grooming会议验收测试用例上讨论，会后编写完成GOOD揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 2.验收测试用例的数据与存储我：这些用例是以组员：我们放在什么样的方式存Excel表格中，基储，含有测试数据本都是描述性的吗BAD揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 3.验收测试用例的维度我：你们是不是在组员：我们开始不一开始压根就没有觉得性能是个问考虑过性能的验收题，不想最后会成这样BAD揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 4.验收测试用例怎样执行我：你们是怎样执组员：当然是测试行验收测试用例人员，一般采用手的，谁来执行的？工的方式BAD揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 三Sprint实践ATDD揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 第一个Sprint揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 讨论并设计完可测的关键测试数据之后，我们都知道了特性的scope。随后我们准备将验收测试进行自动化，但紧接着问题就来了谁来负责编写验收代码？用基于关键字的框架还是纯脚本语言？揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 关于谁来编写验收测试代码开发：我的开发任测试：功能都没有务很重，很难有精实现，怎么来编写力还要写验收测试验收测试代码揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 既然各有难处，且都没有相关经验，我决定作为一名测试开发人员的角色帮助他们实现验收测试代码，以帮助他们认识到可行性和积累相关经验。揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 用基于关键字的框架还是纯脚本语言我：验收测试代码开发：当然是纯脚后续是交付给你持本的语言，编写更续测试维护的，你类似于高级语言觉得哪种你更擅长？揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 验收测试代码片段揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 我和开发人员配合得很愉快，在验收测试代码基本完成后，我将所有权传递给了开发人员，每次他有小的代码改动都会运行一下验收测试脚本，如果没有问题就交给测试人员。这做到了开发自测，并且测试效率很高，开发和测试都很happy揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 一切看起来似乎都很好，但问题在sprintreview会议上出现了揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 当PO看到测试脚本的consoleoutput不断打印着输出时，一脸疑惑你们是怎样设计测试的？测试数据在哪里？这些不断输出的内容是什么？揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 我们让团队满意了，但没有让PO满意，PO并不关心测试实现揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ PO喜欢怎样的实现呢我：你喜欢怎样的PO：是的，因为测试结果展示呢？那样可以让我清楚RobotFramework看到测试需求和数那样的方式吗？据揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 第二个Sprint揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ �团队开始自己实现验收测试代码�我们在设计和编写测试代码的时候，注意上下层次分离，即测试需求和实现分离。�在reviewmeeting前，针对PO的需求，我们采用robotframework替换python展现测试需求和数据，同时也保留python的方式，因为开发倾向于此种方式。揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ PO很满意，同时团队也意识到基于关键字驱动的测试框架更利于展现测试需求，因为它结合关键测试数据、基于自然语言描述，更接近于需求文档。揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 既然大家都认识到这点，并且已经掌握了上下层分离，下一个sprint似乎就不需要上层的python实现了。揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 第三个Sprint揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 我们将关键测试数据填写在RobotFramework的表格中，辅助以下层的python测试实现。揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ �至此，团队已经理解了ATDD存在的意义和价值，以及相关的技能。�Celebrate时刻？�为了让自动化测试用例成为活的需求文档，我们还有很长的路要走！！揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 微博：@葛锋-Roger邮件：roger.feng.ge@gmail.com揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！ 2012-12-20