文章

敏捷测试的启示

最近,好像整个软件开发界都在讨论和实践敏捷方法,做什么事情都要敏捷,开发要敏捷,测试也要敏捷。

什么是敏捷?

敏捷宣言:个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。-

敏捷开发是递增式的、迭代的、不断调整的开发模式。在敏捷开发中,工作被分解成“故事”,也叫特性或用例,组合成任务分派给不同的程序员。敏捷开发讲求合作,结对进行编程,避免个人拥有专门的知识,代码属于项目组共有。在敏捷开发中不存在回退,讲究持续地集成,单元测试(通常使用测试驱动的开发方式),持续地进行回归测试。

敏捷测试是指在敏捷开发模式中的测试。敏捷测试包括单元测试(通常由程序员完成)和可接受性测试(通常由测试人员完成)。 Read more

成功组建规范敏捷交付团队的 5 大技巧

简介

敏捷宣言(Agile Manifesto)自 2001 年发布以来就定义了敏捷方法的核心精髓。最近,IBM 以 “规范敏捷交付” 之名提出了一组最佳实践,帮助较大型软件开发团队取得与较小型团队在过去 10 年使用敏捷技术所取得的相同成就。这不是说现有的常用敏捷方法是杂乱无章的;事实上,大部分敏捷方法都需要比传统或临时的方法更加规范和严格。但是,并不总是有处理复杂企业环境中的大型敏捷项目的指南。

DAD(规范敏捷交付- Disciplined Agile Delivery,是 IBM 提出的一组实践,旨在帮助较大型软件开发团队像较小型团队一样成功实现敏捷开发) 提供了一个混合框架,将来自各种现有的成熟敏捷方法(比如 Scrum、XP、Crystal、FDD 和 DSDM)的最佳指南结合在一起。尽管这些方法中的每一种都有价值,但每种方法在各个方面都是不完整的,因为从业者通常会将来自不同方法的技术堆叠起来,获得某种相对集中的产物。来自 IBM 的敏捷/精益 IT 首席方法学者 Scott Ambler 收集了来自多种方法的最佳指南,并得到了 DAD 框架。我非常幸运能够与 Scott 合作,并能够在我自己的项目中使用这些实践。

DAD 还为常见的敏捷方法补充了企业指南。例如,DAD 会向团队展示如何将 “积压” 等主流概念带到下一个层次,让它们更适合更大规模的企业环境。它可帮助您与直接开发团队以外的企业权威合作,比如企业架构师或数据库管理员。一些开发人员错误地认为,采用敏捷方法后,您就不再需要处理这些个性特征和准则。事实不是这样的。大部分敏捷团队都必须放眼于团队外部,尤其是在参与其他项目和与组织中的其他权威人员合作时。

基于我个人作为大量敏捷项目的开发人员和团队领导的经验,我提出了以下建议,帮助您思考与敏捷开发原则指导下的项目相关的大型团队管理问题。这些只是在组建拥有 20 或更多位开发人员的敏捷项目团队时要考虑的部分因素,但它们可帮助您朝正确的方向发展。

技巧 1:欢迎通才专家

传统方法倾向于假设一个拥有非常专业人员的团队会为客户带来更出色的产品。事实上,我们发现事实正好相反。在许多情况下,参与项目的人员越专业,他们会越想尝试生成完美的文档、完美的代码和完美的模型。此外,如果团队依靠只拥有自己专长技能的专家,则效率就会降低。例如,如果团队中只有一个人理解数据库,那么不仅该团队的工作会延误,而且将有效的解决方案交到利益相关者手上的整个过程也会延长。

DAD 促进了拥有 “通才专家” 的团队的形成,通才专家也就是具有一项专长,但还对软件开发生命周期中的多个领域拥有基本知识的人。例如,一位分析师可能是需求方面的专家,但还对测试具有基本知识,如果团队测试进度落后了,该分析师可以提供帮助。

在我现在参与的项目中,开发人员除了传统的编码专长外,还花了大量时间来帮助编写部署和持续集成脚本。结果,他们都获得了有关基础架构和配置管理的基本知识。另一个示例:测试人员在传统上主要负责从黑盒角度测试用户界面和软件工作原理。但敏捷领域中的测试人员日渐需要变得更加技术性,考虑开发人员所做的工作。如果他们能够将测试编写为代码,而不仅是从用户界面测试功能,他们会对团队更有用。

技巧 2:更多地专注于协作技能,而不是智囊团

聪明的人组建的团队常常无法得到预期的结果。一组聪明的人不一定就会组建成一个优秀的团队。只有在这些人朝一个共同目标协同工作时,才有可能成功。我看到过不想协同工作的非常聪明的人,他们更喜欢独立工作。您的组织中可能有适合这样一个人的职位,但在敏捷开发和交付团队中可能没有。

此外,还有一个事实是,我们无法在每个项目团队中都配备超级明星。我们需要学习如何在具有普通、可预测能力的人中变得富有成效,而不只是明星编程人员。所以,我在组建团队时寻找的是既能良好协作,又展现出竞争力和自信的人。他们谦恭有礼,因为他们认识到事实上他们无法知晓全部内容,他们需要彼此学习一些东西。

技巧 3:为手头的项目组建规模适中的团队

DAD 描述了 3 种不同的团队级别:经典的小型团队、中型团队和大型团队。当然,DAD 主要针对大中型团队而创建。对于可能有多个子项目同时处理共享组件的较大型团队,一定要考虑各队人马与其各自团队领导如何协同工作。一个问题是,经典敏捷理论建议组建小型、自给自足的团队,假设他们应该能够自行实现完整的解决方案。但在我们的队伍不断壮大时,我们需要从团队外引入其他具有专业技能的人。

例如,在我当前的项目中,我们将十几项技术集中起来实现一个非常大的系统。我们明确地应用了 “通才专家” 的原则,但事实上不是团队中的每个人都能够了解所有这 12 种不同的技术的每个细节。所以我们为团队补充了一些基础架构人员,比如 Linux 专家、两个数据库权威人员以及安全性和防火墙专家。

在像这样较大型项目中,当您过渡到生产环境时,您将必须与(举例而言)您的 DevOps 团队或企业现代化团队合作。换句话说,您的系统不会孤立地存在。我当前参与的项目将与一个现有的系统相集成。要移到生产环境的所有要素都会受到严格的变更控制流程的紧密控制,所以我们会定期与团队外部的这些人互动,以让这些要素正常工作。

DAD 还包含在启动项目时执行某种初始规划的指南,这可能对于让不同团队协同工作很有用。对于较重的项目,您需要在要解决的商业问题和要得到的解决方案方面获得初步愿景。这个愿景可能包含业务案例的总体概述、提议的技术架构、风险摘要以及其他的摘要信息,让利益相关者相信该项目真正有用。

技巧 4:理解敏捷领导原则和团队组织,灵活处理手头的项目

小型团队的敏捷方法(比如 Scrum)解决了这样一种事实,在软件开发中,领导阶层的指挥控制方式(经理创建详细的工作细分结构、向团队分配任务,并告诉他们每项任务要花多长时间完成的方式)存在问题。敏捷方法从业者认识到,实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务,他们执行自己的评估,他们自愿挑选任务,他们自行分担工作量。在本质上,他们就像一个高效运转、自行组建的团队,没有明确定义项目经理职位。相反,该团队指派某个人作为团队领导,帮助推进整个流程。
DAD 使用了产品所有者 的概念,这个概念直接来自于 Scrum;DAD 事实上完全没有更改这个角色。产品所有者负责确定工作范围、优先级并阐明他们需要完成的工作的需求。作为产品所有者,他们拥有解决方案的产品愿景。但是,参与 DAD 实践的人认识到,对于较大型、更复杂的项目,可能必须向团队增加领域专家来协助产品所有者。

DAD 还有另一个类似于产品所有者的角色,称为架构所有者。团队拥有天才开发人员固然很好,但同样重要的是,让某个人 “拥有” 交付解决方案的架构愿景和负责关键技术决策。架构所有者也可以与团队外部的重要权威人员协作,比如企业 DBA 或企业架构师,以确保开发团队所做的决策不会与企业整体的标准和指导原则相冲突。他或她是项目的技术专家,定期与这些利益相关者合作。

作为自己团队的领导,我大量依赖于架构所有者。我目前的情况是,在一个房间里拥有 25 个工作人员。这是一个比经典敏捷项目人数更多的团队,但这是将一个项目升级为 DAD 项目的不错示例。紧挨着我左侧的是架构所有者,所以我总是可以向他咨询问题,比如:
我们是否有合适的人在参与合适的任务?

我们是否减轻了技术风险?
哪些团队成员需要帮助?我们是否为他们安排一个搭档,以便他们在执行任务时可获得帮助?
企业中是否有现有的技术资产或模式可供我们使用?

作为团队领导,尤其是在像这样的大型团队中,我很难详细地了解每个开发人员是如何工作的。所以我选择架构所有者作为我的搭档,帮助提高团队效率。
从另一方面讲,架构所有者也很重要。架构是项目风险的一个巨大的潜在来源,因为存在超越项目边界的依赖关系,比如生产环境、业务需求、遗留数据、旧有系统等。架构所有者确定要在早期迭代中实现哪些工作项,以尽可能早地减轻这些风险。这种 DAD 实践称为 “风险价值生命周期”,它不同于其他仅依靠商业价值来确定工作优先级的敏捷方法。架构所有者帮助团队理解关键技术风险,以及必须捕获和满足哪些需求才能减轻这些风险,在项目后期,修复这些风险可能非常困难且成本极高。

技巧 5:提防自行组建的团队,尤其是如果团队缺乏经验

自行组建的团队是一个非常美妙的敏捷概念。团队成员最了解如何自定义他们的流程,以保持最高效率。他们可以协作,是因为已学会了如何协同工作。例如,Hal 知道他是否可向 Julie 发送电子邮件,或者他是否需要面对面地讨论以提高效率。在理想情况下,团队拥有他们履行构建所需软件任务所必备的技能。在实践中,自行组建的团队非常适合技术牢固、透彻理解软件开发最佳实践且对敏捷方法有一定了解的人。

对于较新的或更年轻的团队,可能不具备这些条件。他们可能不理解如何针对架构或需求建模解决方案。或者更基本来讲,他们可能不熟悉敏捷方法,不理解不同的实践。

因此,在自行组建团队时,您需要考虑技能和经验成分。技能和经验的缺乏可能导致混乱且散漫的团队环境。还有一种个性特征成分。一些团队成员不习惯于决定他们应该执行哪些任务或按何种顺序执行。一些人可能实际上更喜欢采用更加传统的方式。如果您是团队领导,您必须对这些态度和习惯产生警觉,理解某个人何时需要诱导或引导他们的日常活动。

此处传达的基本信息是,自行组建的团队可以运转,但团队领导让团队自行管理的程度取决于团队的成熟度和能力。优秀的团队领导不会简单地相信团队,全权委托权威专家来完成他们想要的任何事情。相反,优秀的团队领导应该了解团队的进展,密切关注以确保他们朝正确的方向发展。

最后的思考

主流的敏捷理论在向客户交付具有较高商业价值软件方面奠定了牢固的基础,但它可能有点理想化。它并不总是代表 Scott Ambler 和我每天在较大型项目中的经历。我们的目标不是推翻前人的成果,重新发明敏捷方法,因为如果正确实现敏捷方法,那么这些成果是很有用的。我们只是尝试填补所存在的一些空白。

毋庸置疑,对于 DAD,我们没有打算规范化。例如,尽管我们更喜欢在工作项列表中通过用户案例来表示需求,但如果您希望应用用例场景,完全没问题。DAD 是一个框架。您应该选择其中最适合您的敏捷项目需求的技术。

结束语

DAD 可帮助大型软件开发团队成功实现敏捷开发项目。DAD 将来自各种现有的成熟敏捷方法结合到一个框架中,为常见的敏捷方法补充了企业指南。因此,它可帮助具有超过 20 人团队的组织充分利用敏捷开发方法。当组建 DAD 团队时,请记住以下这些技巧:欢迎通才专家,专注于协作技能,为您的项目组建规模适中的团队,理解敏捷团队原则和团队组织,但保持灵活并提防自行组建的团队。

原文来自:http://www.ibm.com/developerworks/cn/rational/agile/forming-dad-teams/

Scrum解析:当西方遇上东方

敏捷的基本观点是以变化的观点看待世界(体现在敏捷宣言中的响应变化)和以人为中心(体现在敏捷宣言中的个体与互动和与客户合作)。Scrum是一个管理框架,流和可能性的艺术。它是东西方思想碰撞与结合的产物。它的三个哲学基础是:
来自中国的王阳明的知行合一学说。
来自日本的野中郁次郎的场理论。
来自美国的Jim Coplien等的模式(源于道德经)。 Read more

让管理层害怕的 8 个敏捷理解

敏捷体系中,有许多种不同的开发方法。各类敏捷开发方法中,较成体系的有 XP、FDD,只说明管理框架的有 Scrum,只说明建模的有敏捷建模,具体的技术实践包括 TDD 测试驱动开发、持续集成、结对工作、快速迭代等等。敏捷涉及面非常广泛,不同的人当然有一些不同的理解和解释。也许由于敏捷开发方法首先发端于程序员,不 少的理解可能来自于程序员。本文试图来整理当前主要的让管理层害怕的敏捷理解,而不论这个理解是否正确。本文所指管理层是指团队以上的管理者们,不包括项 目经理和项目团队领导。
Read more

大型项目开发使用敏捷是否合适?不该问的问题

人们经常问笔者敏捷是否适合大型的项目,或者是否它只适合小型的项目和团队。笔者意识到这是一个很难解释的问题。您可能会问为 1000 个人准备食物,是否和为准备四口之家的食物没有本质区别。当然是这样的,但是您可以看到不同的方法,食谱以及器具。您可能会在一个 20 加仑的容器中混合沙拉,而不是一个小罐中进行的。 Read more

敏捷测试用例设计

敏捷宣言:

个体和交互比过程和工具更有价值;

能工作的软件比全面的文档更有价值;

顾客的协作比合同谈判更有价值;

及时响应变更比遵循计划更有价值。

并非每个企业都能严格按敏捷的相关开发方法进行项目管理,例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓,我认为很多方法、很多地方都可以应用敏捷的思想,实现敏捷的管理。

测试用例的设计是其中一项。

测试用例的粒度

测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等。

测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题。另外,测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。

测试用例写得过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

软件是开发人员需要去努力实现敏捷化的对象,而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则,则关键是考虑怎样使设计出来的测试用例是能有效工作的。

基于需求的测试用例设计

基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的。

要把测试用例当成“活”的文档(Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin),因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。

测试用例的评价

测试用例设计出来了,质量如何,如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样,测试用例的质量保证也需要综合使用各种手段和方法。

测试用例的检查可以有多种方式,但是最敏捷的应当属临时的同行评审。我认为同行评审,尤其是临时的同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例。

除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让他们参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于你怎样定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持,那么顾客显然就是程序员了。

因此,参与到测试用例设计和评审中来的人除了测试人员自己和管理层外,还应该包括最终用户或顾客代表,还有开发人员。

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的,要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现,但是数据则不同,数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

很多时候,测试用例的输入参数有不同的类型、有不同的取值范围,我们需要得到测试用例的输入参数的不同组合,以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛,我们又需要科学地筛选出一些有代表性的数据,以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

可利用一些工具,例如TConfig、PICT等来产生这些数据。

在性能测试、容量测试方面,除了设计好测试用例考虑如何测试外,还要准备好大量的数据。大量数据的准备可以使用多种方式:编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。

工具未必能生成所有满足要求的数据,但是却是最快速的,编程能生成所有需要的数据,但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具,例如DataFactory等。