敏捷项目管理实战之在敏捷开发中引入 Story 演示

发表于:2013-5-17 15:29

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:黄文海    来源:51Testing软件测试网采编

  简介:

  Story 演示活动可以帮助敏捷开发团队提高开发质量、降低返工带来的质量低下与进度滞后的可能性。本文以作者黄文海的实际敏捷开发与管理的经验为基础,分享了具体实施 Story 演示的注意要点以及如何控制 Story 演示的成本。本文分享的不仅是一个具体的敏捷开发实践,更是一种敏捷开发的思想和思维方法。

  什么是 Story 演示

  敏捷开发中往往使用 Story 驱动的方式实现需求。Story 驱动开发的优势在于它体现了“聚焦用户价值”这一理念。聚焦用户价值意味着软件开发过程中的一切活动和取舍都以最终交付件能否为软件的用户产生价值为考量。

  在笔者所带领的敏捷开发团队中,一个 Story 在转测试之前其开发人员要召集相关的测试人员将该 Story 的各个验收测试用例执行一遍给测试人员看。这个过程中,测试人员会判断所执行的各个验收测试用例是否真正通过,并根据用例通过的情况决定相应的 Story 是否允许转测试。这样一个由开发人员执行验收测试用例,测试人员复核用例通过情况并据此决定相应的 Story 是否允许转测试的活动,笔者称之为 Story 演示。

  Story 演示过程中所用的验收测试用例是在开发人员进行编码前由测试人员和开发人员一起根据 Story 所体现的用户价值设计出来的。因此,Story 演示这一活动是在聚焦用户价值这一理念的指导下产生的一种适合于敏捷开发下的转测试控制措施。

  引入 Story 演示有什么好处

  在讨论如何实施 Story 演示之前。有必要讨论下实施 Story 演示有什么好处。或者说为什么要实施 Story 演示。因为这个问题的答案会告诉我们如何实施 Story 演示。“为什么”的问题是“意”的问题,即我们做一件事情的时候,我们的意图是什么或者说我们期望这件事情的完成给我们带来什么收益的问题。用心理学的术语来讲,就是一个动机是什么的问题。“怎么做”的问题是一个“形”的问题,即行为方式或者事物的外在表现方式的问题。“意”会决定“形”,而“形”要遵从“意”。这样,我们所进行的活动才能较好得达到预期目的。比如爬山,如果我们的“意”是体验居高临下的一览众山小的感觉,那么我们可能会比较快得爬到山顶,而忽略沿途的风景。如果我们的“意”是散散心、呼吸新鲜空气、欣赏风景,那么我们可能是慢慢爬,流连在半山腰的风景之中。

  Story 验收测试用例从用户价值的角度定义了 Story 的最低质量标准。Story 演示通过评估这些用例的执行通过情况决定相应 Story 是否允许转测从而保证了转测 Story 的最低质量要求,有效降低了由于转测 Story 质量低下而导致的多次修正代码多次再转测的返工可能性。返工作为软件开发过程中一种最为常见的浪费现象,它不仅阻碍了进度,也降低了质量。因此,从短期角度看,Story 演示的好处在于它能够有效减低返工的可能性,提高 Story 代码的质量。

  Story 演示是由开发人员和测试人员共同参与的。Story 演示所呈现的软件功能作为开发人员的作品,对于往往有着弊帚自珍心理的开发人员来说,他总是不愿看到其作品在他人面前出现缺陷的。因此,Story 演示前,开发人员必须做好充分的单元测试才能避免在演示时当众“出丑”。于是,通过一次次的 Story 演示可以强化开发人员的质量意识。而开发人员的质量意识很大程度上决定了缺陷的数量。毕竟缺陷不是由测试人员“发现”出来的,而是开发人员“创造”了大部分缺陷。

  另一方面,Story 演示过程中,开发人员往往能够自己发现一些在此之前不曾发现的问题,这些由其自身发现的问题往往能给其留下深刻的印象因而有利于其避免下次再犯同样或者类似的错误。这有利于开发人员自身的持续改进,提高其个人能力。因此,从长期角度看,Story 演示的好处在于它强化了开发人员的质量意识,并促进开发人员个人能力的持续改进。

  能够从短期和长期的角度去理解实施 Story 演示的好处非常重要,因为这会影响到我们如何具体实施 Story 演示。

  如何设计验收测试用例

  验收测试用例的设计与选取要从用户或者更切确地说利益干系人的角度出发。验收测试用例定义了 Story 应满足的最低质量要求。比如,对于一个 ATM 机取款功能,我们可以定义如下几个验收测试用例:

  用例 1:

  预置条件:发卡行为本行,账户余额 1000 元,ATM 机剩余现钞 1000 元。取款金额 1000 元,吐钞设备正常,网络正常。

  期望:吐钞设备吐款 1000 元,账户余额 0 元,ATM 机剩余现钞 0 元。

  用例 2:

  预置条件:发卡行为本行,账户余额 1000 元,ATM 机剩余现钞 1000 元。取款金额 1100 元,吐钞设备正常,网络正常。

  期望:吐钞设备无吐款,账户余额 1000 元,ATM 机剩余现钞 1000 元。

  用例 3:

  预置条件:发卡行为本行,账户余额 1000 元,ATM 机剩余现钞 900 元。取款金额 1000 元,吐钞设备正常,网络正常。

  期望:吐钞设备无吐款,账户余额 1000 元,ATM 机剩余现钞 900 元。

  用例 4:

  预置条件:发卡行为本行,账户余额 1000 元,ATM 机剩余现钞 1000 元。取款金额 1000 元,吐钞设备故障,网络正常。

  期望:吐钞设备无吐款,账户余额 1000 元,ATM 机剩余现钞 1000 元。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号