2019-11-20 09:34:20 qq_44614026 阅读数 47
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5781 人正在学习 去看看 CSDN讲师

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。
    比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解

  • 对不同系统和数据库所用到的技术知识的了解

  • 和不同角色以及客户进行有效沟通

  • 主动验证质量目标并及时说出自己的想法

  • 编写测试计划,列出需要执行的活动并进行估算

  • 自动化测试的能力和对测试工具的基本了解

  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2016-11-16 17:54:06 wildnesswolf 阅读数 1218
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5781 人正在学习 去看看 CSDN讲师


http://bbs.51testing.com/thread-1100977-1-1.html

综述

在敏捷开发模式,往往传统以功能测试为主的测试难以适应新的角色,而敏捷团队也面临着产品质量和快速市场的压力,需要通过快速的迭代抢占市场,但另外一方面质量的问题,又可能导致市场丢弃,这时,测试应尝试调整测试的重心和方法,目标是做到敏捷测试,测试与开发并行,测试的重心更应移到后台的业务逻辑测试,并建立起新的测试模型,特别后端接口的自动化测试,有了自动化测试,我们所说的持续交付才有可能真正实现,在开展敏捷测试时,可以在各敏捷小组之上增加量个角色以保证产品质量和迭代的效率,一个测试开发角色,负责团队基础测试技术如性能测试,安全测试,负责测试工具、测试平台开发,测试实验室的建立;而另一个过程管理角色,则负责提升整个敏捷流程效率,梳理各环节的问题,对产品、开发、测试、运维的工作成果进行审计,促进设计、开发、测试、运维等角色密切协作,倡导3C【Card、Conversation、Confirmation】。
总的来说,敏捷测试的终极目的是为了持续交付,快速向市场交付可靠的产品;在敏捷开发模式下,迭代使得代码量逐步累加,越靠后的迭代我们所面临的整合测试压力、测试任务就越大;敏捷测试需要测试人员能够随时启动自动化回归测试对发布的迭代代码进行快速验证,以确保开发人员在进行新功能开发同时,未对已有的功能进行破坏
2019-09-26 23:39:17 u012088066 阅读数 14
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5781 人正在学习 去看看 CSDN讲师

一.敏捷测试总体介绍

敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。敏捷测试主要的核心内涵有三个:

  1.遵从敏捷开发的原则(强调遵守)

  2.测试被包含在整体开发流程中(强调融合)

  3.跨职能团队

二.敏捷测试的特点

  1.更强调协作

  敏捷开发人员和测试人员工作得更加紧密,喜欢更直接的沟通方式而不是通过邮件文档这种一来一回反反复复的沟通方式

  2.更短周期

  需求验证或者测试的时间不再是按月计算而是按天或者按小时计算。用户验收测试在每个周期的结尾都会进行。

  3.更灵活的计划

   敏捷测试也需要拥抱变化,测试计划不再是一成不变的文档而是会根据情况进行灵活调整

  4.更高效的自动化

  相比传统测试,自动化在敏捷测试中扮演了极为重要的角色。它是实现快速交付确保质量的一种非常有效的手段。

 

2017-03-20 16:22:26 Trinity_Techologies 阅读数 2029
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5781 人正在学习 去看看 CSDN讲师
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。

敏捷开发过程中,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所以项目经理痛恨测试,程序员们也巴不得测试快快放行,让程序好好上线,但我们都知道没有测好的东西是不能硬上的,测试这种把守项目上线最后一关卡的,若没有两把刷子,可能会时常变成项目延迟的炮灰。

为了让测试的效率跟上项目开发的进度,需要抓住两个关键点:
1. 品质是规划出来,非测试出来的
测试在专案的早期就必须参加,熟悉需求,并从测试角度提出各种问题,确保产品经理、开发、测试的等角色的关注点都有备考量到,而测试也会从早期就开始撰写测试用例,在撰写过程中如果有发现任何问题也趁早反馈给产品经理、项目经理,趁早把问题给理清,这样做测试才能把自己的角色提升到为质量负责的角色。

2. 落实自动化
所有重复性的工作都应该被自动化,包含测试,如果你项目大多数的时间都花在基础功能测试,那效率肯定不会高的,所以测试环境、测试资料的准备应该都要有工具能辅助,各种测试用例如果是反覆发生且变动性少,绝对值得你花时间去撰写自动化脚本,而对于后端API接口的测试更是关键,一般的测试可能大多针对功能进行测试,但我们知道很多会露出被用户测到的bug,大多都不是点一点就能测的出来,很多都是因为API在某种情境下出错了,或在某种负载下出错了,这些靠人工非常难验证,透过自动化工具就相对简单多了。

对于敏捷开发项目的测试而言,单元和集成测试是测试策略的关键环节。单元测试是验证最小和独立单元代码行为的过程,比如C++类,C函数,Ada包。这通常在系统测试之前进行。单元和集成测试是构建稳定减少错误应用程序的重要方法,因为它允许测试人员更容易模拟应用程序基本逻辑功能,并验证其是否满足设计需求。

传统的单元测试,通常针对开发人员写的每个软件单元生成测试用例,执行这些用例验证代码功能的正确性。这种模式存在一定风险,因为开发人员在设计测试用例时,很容易受自己实现该代码的思维的影响,从而导致某些情况不能被考虑到或测试到。


自动化测试工具,如:VectorCAST可支持C/C++语言(VectorCAST C/C++)和Ada(VectorCAST/Ada)的单元测试和集成测试。两者都可以自动化地完成单元测试和集成测试的关键步骤。包括测试驱动的生成,测试用例和测试结果的管理,以及自动化的回归测试。

自动化的测试不仅大大提高了测试效率,而且自动化的客观性还能大幅提高测试的准确性。测试的自动化让敏捷开发更加“敏捷”!



2009-06-23 10:34:00 xrqiu 阅读数 1010
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5781 人正在学习 去看看 CSDN讲师

在敏捷开发过程中,项目的开发周期特别短,因此在质量和开发进度上会出现一定的矛盾,最突出的就是单元测试用例的编写。从项目的长期角度来看,单元测试用例对提供团队整理开发效率都有比较大的提升,同时还能提高代码质量、减少程序缺陷。如果我们对测试用例的编写把握不好的话,也会给开发效率带来一定的影响,那么我们应怎样去把握测试用例编写的度呢?下面总结了几点关于单元测试编写的原则:

  1. 为主要的、关键的逻辑组件,关键的逻辑方法进行测试驱动开发

   这样对设计、设计演化很有帮助。

2. 结对编程的方式测试用例让另一个同事来完成。

   更好的发现程序设计及接口设计中的一些缺陷。

  3. 逻辑类似的组件如果存在多个,优先编写其中一种逻辑组件的测试用例

     实践中可能会出现一些组件在逻辑上可能完成差不多的功能(例如类型转换帮助类),可以先只编写其中一种组件的 测试用例以节省时间。

  4. 发现 Bug 时一定先编写测试用例进行 Debug

     在测试和调试之间众说纷纭,最好是先编写测试用例找出这个 Bug,越复杂的系统,测试越发杂,单元测试能更好的模拟参数边界值。

  5. 关键util工具类要编写测试用例

     不要忽视了这些帮助类、基础类的正确性和运行效率。

  6. 保持测试用例与逻辑代码同步

     这里说的“同步”主要包括了测试方法和实现方法的同步;测试用例注释和逻辑代码注释的同步。

  7. 保证测试用例的独立性

     让测试用例独立的可执行,尽量不要依赖其他的测试用例。这样才能让 TDD 与设计保持良好的协作。

  8. 测试过程中,适当的引入Mock 是必不可少的,最好还是提供一个集成测试用例。

     使用 Mock 可以让接口的设计得到快速验证与反馈,也对团队的平行开发提供便利。

没有更多推荐了,返回首页