51Testing软件测试论坛

标题: 敏捷方法的内容(2) [打印本页]

作者: CSTQB-TMMiCN    时间: 2019-3-15 16:50
标题: 敏捷方法的内容(2)

协作用户故事的创建

大部分项目失败的主要原因在于规格说明的缺乏。规格说明的问题可能来自于用户缺乏对他们真实需要的了解,或者是缺乏对系统的全局观,以及在沟通过程中传达了不需要的或不一致的、甚至是错误的特性。
在敏捷开发中,用户故事用于从开发人员、测试人员和业务代表的视角来捕获需求。在顺序开发中,这种特性的共同价值观是在需求编写完成后,通过正式评审来实现;在敏捷开发中,这种特性的共同价值观是在需求编写过程中通过频繁的非正式评审来完成。
用户故事必须处理功能和非功能性特性。每一个用户故事都包含这些特性的验收准则。这些准则通常是在业务代表、开发人员以及测试人员的共同协作下定义出来的。它们提供给开发人员和测试人员对业务代表将要确认的这些特性额外的了解。当一系列的准则满足时,敏捷团队就可以宣称一个任务完成。
通常,测试人员具有独特的视角,通过识别遗漏的细节或非功能性需求帮助改进用户故事。测试人员通过向业务代表提出开放式问题,提出测试用户故事的方法并确认验收准则来帮助改进用户故事。
以作者的身份提供用户故事协作,可以通过采用头脑风暴或思维导图等技术进行。测试人员可以采用INVEST技术:

根据[Jeffries00]提出的3C概念,一个用户故事是以下3个元素的有机联合体:
敏捷团队有不同的方法来文档化他们的用户故事。不论采用哪种方法来文档化用户故事,文档内容应该是简洁的,充分的以及必要的。

回顾
在敏捷开发中,回顾是指在一个迭代结束后举行的会议,该会议讨论哪些是成功的、哪些需要改进以及如何在未来的迭代里整合这些改进并继续保持成功。回顾会议的主题通常包括:过程、人员、组织、关系和工具。当有适当的后续活动发生,定期举行回顾会议对开发和测试的自组织和持续改进是重要的。
回顾可能会产生关注于测试有效性、测试效率、测试用例的质量和团队满意度等测试相关的改进决定。他们也可能会处理应用程序、用户故事、特性或系统接口的可测试性。缺陷(defect)的根本原因分析可以驱动测试和开发的改进。通常,在每个迭代中团队应只实施少量的改进。这允许以一个持续的步伐来连续的改进。
回顾的时间和组织形式依赖于团队所采用的敏捷方法。业务代表和团队作为参与者参加每一个回顾,而会议组织者则组织并确保会议的开展。在某些情况下,团队可能邀请其他参与人员到会。
在回顾中,测试人员应该发挥重要的角色。测试人员作为团队的一员,在回顾中可以带来独特的观点。测试活动在每一个冲刺(Sprint)中进行,对于成功功不可没。所有的团队成员,包括测试和非测试人员,都可以提供测试和非测试活动的输入。
回顾必须在相互信任的专门环境下进行。成功回顾的标志与在基础级大纲讨论的其他任何评审一样。



关于ISTQB
ISTQB®(InternationalSoftware Testing Qualifications Board)全称国际软件测试认证委员会,是一个注册于比利时的非赢利性组织,是国际唯一权威的软件测试资质认证机构。其主要负责制订和推广国际通用资质认证框架,即“国际软件测试认证委员会推广的软件测试工程师认证”( ISTQB® Certified Tester ) 项目。

关于CSTQB
CSTQB(Chinese SoftwareTesting Qualifications Board)是ISTQB®在大中华区(包括港澳台地区)的唯一分会,成立于2006年。全权代表ISTQB®在授权区域内推广ISTQB®软件测试工程师认证体系,认证、管理培训机构和考试机构,接受ISTQB®的全面的业务指导和授权。

(扫描上方二维码,关注CSTQB官方微信公众号,了解更多资讯~)






欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2