测试人员在敏捷项目中的工作方法和传统项目中是不同的。测试人员必须理解支撑敏捷项目的价值观和原则,以及测试人员如何与开发人员和业务代表一起作为全团队方式的一个组成部分。 敏捷项目成员彼此之间越是在早期和频繁的沟通,越有利于尽早移除缺陷并开发出高质量的产品。
敏捷软件开发和敏捷宣言 2001年,一批专家在对一系列轻量级软件开发中广泛使用的方法进行了讨论之后,同意将一些具有共性的价值观和原则汇集成敏捷软件开发宣言,或称为敏捷宣言[Agilemanifesto]。敏捷宣言包含如下四条价值观: 敏捷宣言认为,尽管右边的项有价值,但是左边的具有更高价值。
个体和交互 敏捷开发是以人为中心的。由人组成的团队构建软件,通过持续的沟通和交互,而不是通过对流程、工具的依赖,来达到团队的高效工作。
可工作的软件 从客户角度来说,可工作的软件比详细的文档更有用和有价值,它提供了向开发团队快速反馈的机会。另外,由于可工作的软件(虽然减少了功能性)可以在开发生命周期的早期可用,敏捷开发可以带来巨大的上市时间优势。因此,敏捷开发特别适用于问题和(或)解决方案不甚清晰的快速变化的商业环境,或在新问题域的业务创新。
客户合作 客户往往很难找到他们需要的特定系统。客户与开发团队的直接合作可以改进理解客户需要的可能。当然,与客户签订合同也是重要的,而与客户定期和紧密的合作可能让项目更容易成功。
响应变化 软件项目中的变化不可避免。业务运营环境、法规、竞争对手的活动、技术进步以及其他因素都会极大影响项目及其目标。开发过程必须适应这些因素。因此,在工作实践中灵活的拥抱变化比简单的遵循计划更重要。
原则 敏捷宣言的核心价值包含以下12条原则: - 我们的最高目标是通过尽早的、持续的交付有价值的软件来满足客户。
- 即使到了开发的后期,也欢迎改变需求,敏捷过程驾驭变化来为客户创造竞争优势。
- 持续地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
- 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
- 敏捷过程提倡可持续的开发。责任人、开发人员和用户应该能够保持一个长期的、稳定的开发进度。
- 作在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交流。
- 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工。
- 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
不同的敏捷方法论都提供了把这些价值和原则付诸于行动的具体实践。
全团队方式 全团队方式是指把所有具备相关知识和技能的个人都纳入团队,以确保项目成功。全团队方式需要包括客户代表和能够决定产品特性的其他业务干系人。团队应该相对较小,根据观察,一个成功团队的人数在3-9人。为促进团队之间交流和互动,一个全团队的工作地点最理想的情况下应该在同一办公区。全团队方式通过每日站会来实施,每一个团队成员重点沟通自己的工作进展和阻碍工作的困难。全团队方式促进团队动力更加有效和高效。 在产品开发中使用全团队方式是敏捷开发的主要好处之一。它的好处包括: 在敏捷项目中,团队中的每个成员都对质量负责。全团队方式的精髓是,在产品开发的每一步中,开发人员、测试人员和业务代表都能一起协同工作。测试人员需要和开发人员与业务代表紧密协作,以保证产品能够达到质量级别。这包括支持和协助业务代表创建适合的验收测试、跟开发人员一起决定测试策略、确定测试自动化方法。通过这样的工作方式,测试人员能够把测试知识传递给团队中的其他成员,从而对产品的开发产生影响。 整个团队需参与产品特性的介绍、分析、评估的磋商和会议。包含开发人员、测试人员和业务代表共同参加所有特性讨论的概念被称为“三驾马车”
尽早和频繁的反馈 敏捷项目的迭代周期短,使项目团队能在整个开发生命周期中尽早和持续的接收产品质量方面的反馈。持续集成就是提供快速反馈的方法之一。 在一般的顺序开发模型中,客户往往只有在项目接近结束的时候才能够看到产品。这时,开发团队再去有效的处理客户的任何问题通常是太晚了。如果敏捷团队在项目进行中可以经常地收到客户的反馈,他们就能在产品开发进程中融入大部分的客户新需求。尽早和频繁的反馈能使敏捷团队重点关注具有最高商业价值或相关风险的特性,这些特性需要首先交付给客户。同时因为团队成员的能力是透明的,这也使得团队管理变的容易,例如,在一个冲刺或迭代周期中我们能够完成的工作是多少?什么能帮助我们进展的更快?什么会阻碍我们继续? 尽早和频繁的反馈能带来以下的好处: - 避免需求的误解。这些误解可能在开发后期才能发现,而那时再修复问题就要花费更高的成本。
- 澄清客户对特性的要求,并尽早的完成特性的开发以提供给客户使用。这样,产品就能更好的反映客户想要的内容。
(扫描上方二维码,关注CSTQB官方微信公众号,了解更多资讯~)
|