敏捷开发中的测试qa团队_敏捷团队中qa - CSDN
  • QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷... 质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中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也提出了更高的要求,需要做到:

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

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

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

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

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

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

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

      持续提供并获取反馈

     

    展开全文
  • 敏捷开发中测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷QA敏捷QA的日常活动敏捷QA与...

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

    敏捷开发团队介绍

    我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 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导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
    展开全文
  • 敏捷开发中QA如何做质量管理? 经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过...

    

    敏捷开发中QA如何做质量管理?

    经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过两年多的PQA,在中兴通讯的敏捷转型中也遇到过这些问题。

    先总结一下敏捷转型中遇到的问题吧,QA的工作也是要围绕这些问题展开的:

    1. 很多公司希望采用敏捷,但是又没有把握

    2. 传统的瀑布式开发流程在公司已根深蒂固,虽无法满足快速发展的需要,但大规模改动又不现实,老板也不愿意花太多的成本

    3. 缺少敏捷软件开发专家和人才

    4. 研发人员需要观念的转变和方法培训

    5. 缺乏相应的质量控制方法

    6. 需要经常的和及时的质量度量

    7. 自动化测试不能落到实处,持续集成发挥不出作用

    8. 人员水平参差不齐,有人支持有人反对

    笔者也先后参加过多次华为、腾讯、平安科技等公司的敏捷推行者的分享活动,也参加过Thoughtwork、康仕诚、ScrumCN等专业机构的培训,对国内敏捷项目的质量管理有一些想法,结合笔者这几年的质量管理经验,总结一下:

    1)QA角色的转变

    QA以往主要还是作为警察的角色,从事各种审核活动,要从警察转变成教练。传统项目里,QA习惯拿着事先准备好的检查单,对项目一条条做审核,发现问题开不符合报告,给团队的感觉就是一个监工。虽然笔者自己也不喜欢人家这么说我,但确实我们给项目成员你的印象就是监督。

    中兴通讯从2014年开始,各研究院都大力推行敏捷转型,刚开始觉得有点失落,都敏捷了,都不知道该怎么下手了,审核不能叫审核,要叫观察,审核报告也要叫观察记录。经过几个月基本上适应了,QA、项目管理员都往敏捷教练的方向上转,在外界专业教练的指导下,引导项目开展各类敏捷活动。

    比如该如何开站立会议,该怎么去做迭代的计划等等指导性的工作,不过以前的项目团队划分成十多个特性团队,一个人要跟十几个PO、SM打交道,对于QA的沟通能力增加很多,每天奔赴各个团队。

    2)QA参与各项活动,如需求梳理会、计划会、早会、持续集成看板、演示、回顾会等,各项持续集成结果也都推送到QA,这样便于及时获取团队的信息,也便于QA输出各类观察记录、报告。

    3)自动化回归测试。敏捷团队没有自动化会成功吗?可能也会成功,但我们所知道的成功团队都依赖于自动化回归测试,如腾讯和支付宝公司的Selenium框架,阿里巴巴和淘宝网的QTP框架。笔者咨询认为,敏捷开发利用测试来指导开发,为了编写的代码使测试通过,需要快速而简单地运行测试,没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。

    4)提供并获取反馈

    反馈是敏捷的核心价值,敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转,测试人员则通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里拿到了预期行为的正确示例?你怎么知道编写的测试用例正确地反映了这些示例?开发人员通过查看测试用例能够理解应该编写什么代码吗?QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求并是否能够指导编码,询问客户是否理解质量标准,应花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。

    5)构造核心的敏捷实践活动

    软件行业有一句老话是:软件质量是设计出来的。对于敏捷开发也是如此,笔者认为没有一些基础的实践活动,无法产生出高质量的软件。

    1. 持续集成:持续集成(CI)是一项软件开发实践,其中团队的成员经常集成他们的工作,通常每人每天至少集成一次,每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决,降低缺陷修改成本;将集成工作分散在平时,通过每天生成可部署的软件;避免产品最终集成时爆发大量问题。QA可以关注这些持续集成发现的问题分布情况、解决情况、构建周期,及时度量出相关数据。

    2. 看板:最便宜的敏捷工具,可实现价值流、可视化、拉动、限制在制品、找出瓶颈等多个作用。用户故事可以用看板,QA自己的任务同样可以用看板管起来,便于QA之间互相沟通、对齐信息。

    3. 自动化测试:持续集成的前提是有自动化测试用例,以及代码静态检查、代码行覆盖率、代码复杂度等各种工具,如果这些没做起来,只是持续构建,并没有太大意义。自动化测试属于防御性测试,把所有的质量风险用穷举法列出测试用例,然后测试用例提前写好,然后写代码帮你执行,预防缺陷的泄露。但是成本同样非常大,是否能推行起来,就看领导的魄力了。

    4. 每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。一般主持人由敏捷团队的成员轮流担任,这个时候可以了解每天发生的问题。QA可以参加晨会,根据自己的观察提出问题。

    5. 结对编程:两位程序员在一台电脑前工作,一个负责敲入代码,而另外一个实时检视每一行敲入的代码;操作键盘和鼠标的程序员被称为“驾驶员”,负责实时评审和协助的程序员被称为“领航员”;领航员检视的同时还必须负责考虑下一步的工作方向,比如可能出现的问题以及改进等。有助于提升代码设计质量;研究表明结对生产率比两个单人总和低15%,但缺陷数少15%,考虑修改缺陷工作量和时间都比初始编程大几倍,所以结对编程总体效率更高,同时结对编程能够大幅促进团队能力提升和知识传播。不过这个实践也是最难推行的,往往只有进度不紧的时候才会尝试。

    6. 用户故事:用户故事是站在用户角度描述需求的一种方式;每个用户故事须有对应的验收测试用例;用户故事是分层分级的,在使用过程中逐步分解细化;典型的描述句式为:作为一个XXX客户角色,我需要XXX功能,带来XXX好处。用户故事的好处是:用户故事站在用户视角便于和客户交流,准确描述客户需求;用户故事可独立交付单元、规模小,适于迭代开发,以获得用户快速反馈;用户故事强调编写验收测试用例作为验收标准,能促使需求分析人员准确把握需求,牵引开发人员避免过度设计。QA可以引导项目团队如何编写用户故事、验收标准。

    7. 迭代回顾会议:在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步。会议需要Team全员参加,气氛宽松自由,畅所欲言,头脑风暴发现问题,共同分析根因;会议关注重点是Team共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。QA同样可以参加回顾会议,引导团队如何召开,并跟踪改进事项。

    总之,笔者认为,质量是整个敏捷团队的职责,团队中的每一个人都应该关注手边的一个任务或者故事,敏捷模式下的质量管理更具有挑战性,但与传统瀑布模式相比,其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于交付有价值的软件,一直到客户满意为止。在这个“快鱼吃慢鱼”时代,要想交付好而快的产品,不防用敏捷模式试试。

    (为偷懒,本文有些内容为网上抄袭)

    

    展开全文
  • 参考1 https://www.sohu.com/a/128624542_177747 参考2 https://wenku.baidu.com/view/b9080553ed630b1c58eeb564.html 参考3 https://www.cnblogs.com/mikeyond/archive/2011/06/30/2094274.html ...

    敏捷开发&质量管理

    一、质量管理

    1.1 什么是质量管理

    百度词条的解释如下:

    • 质量管理是指确定质量方针、目标和职责,并通过质量体系中的质量策划、控制、保证和改进来使其实现的全部活动。
    • 为了能够在最经济的水平上并考虑到充分满足顾客要求的条件下进行市场研究、设计、制造和售后服务,把企业内各部门的研制质量、维持质量和提高质量的活动构成为一体的一种有效的体系。
    • 质量管理是“在质量方面指挥和控制组织的协调的活动”。

    1.2质量管理革命

    • 质量管理的第一次革命是建立专门的QC部门。
    • 第二次革命就是建立专门的QA部门。
    • 第三次革命是将所有QA工作转交给所有职能部门(生产、采购、物流、营销等)。
    • 第四次革命就是消灭专门的质量部门,或者说这就是质量管理的4.0。

    1.3 质量管理4.0–消灭质量部门

    传统的质量管理中QA有三大核心工作(审核、跟踪、总结)与四大角色(律师、警察、医生、老师),但是质量管理4.0则发生变化QA人员角色要从保姆变为教练, 从关注产品质量到关注流程质量。这就会产生一个良好的循环

    • 当QA人员不再直接参与解决产品质量问题时,开发部门一定会主动承担这样的角色,按照逻辑讲, 开发人员应该比质量人员更知道问题所在。
    • 而当开发主管也开始关注优化流程时(QA的角色),质量部门的QA就可升级到QM的角色,即关注质量管理体系的框架设计是否合理,是否需要对各个体系进行整合。

    质量人员的使命就是消灭质量部门,这似乎是一个悖论,但实际结果就是这样

    当产品质量控制由生产人员承担,业务流程的优化是由各个职能部门负责,那质量部门就该寿终正寝,这需要质量人清醒认识到这一点。

    二、敏捷开发&质量管理

    对于敏捷开发不在此进行讨论,有在另外一篇中进行分享

    首先需要理解不论是敏捷开发还是瀑布开发,质量都是一个研发团队需要关注的,质量管理也都是要进行的。任何一个不关注质量的团队,是没办法长期发展的。

    2.1 敏捷开发与质量管理的关系

    • 敏捷开发关注敏捷,快速响应变化,减少互联网发展带来的影响;
    • 质量管理关注质量,确保产品质量,带来长期效益。

    两者表面看起来是没有什么关联关系的,但是其实两者之间是一个互补的关系。质量管理为敏捷开发提供敏捷基础,敏捷开发为质量管理提供文化传播。怎么理解?

    1. 敏捷开发关注快速响应,但是长久的敏捷才是真正的敏捷!

    如果为了实现敏捷闷头迭代向前冲刺,一段时间之后就会发现有很多瓶颈。例如:新类型的需求系统架构不支持,需要系统重构;为了快速响应、迭代上线,开发忽略了单元测试、测试忽略覆盖率,线上问题很多。质量管理就是为敏捷开发提供基石,让敏捷开发长期的快速前进。
    2. 质量管理的重心思想是消灭质量部门,将质量变为所有人关注的问题

    敏捷开发是需要所有人参与的,通过敏捷开发将所有人召集,对于贯彻质量管理的思想无疑不是一个更好的途径

    2.2 敏捷开发中如何做质量管理

    上面提到质量管理4.0的时代已经开始,需要将敏捷开发与质量管理4.0结合
    这里我想起之前整理’测试左移‘时的两点“质量上限、质量下限”

    如果将敏捷开发看作“车”,质量管理看作“路”,那么团队要做得事情就是”把车开到目的地“

    1. 确定并遵守质量下限
      明确质量下限就意味着,无论事情做得多糟糕只要满足质量下限,就可以认为产品是合格的。
      跟敏捷开发结合起来就是,严格遵守质量下限的基础上快速响应,即提高了响应效率又保证合格的质量。就像只要“路”存在,“车”就可以跑起来。
    2. 不断挑战质量上限
      挑战质量上线,就是通过更好的方式让产品的质量输出更好
      跟敏捷开发结合起来就是,提高质量上限就像把“石路”变成“柏油路”再变成“高速路”,这样“车”就可以换成“跑车”,让敏捷变得更敏捷。
    3. 质量管理不要成为敏捷开发的累赘
      为特定的“车”提供合适的“路”即可。团队的精力是有限的,既要“开车”又要“修路”,当”车“还是”奥拓“的时候没有必要为他修一条”高速公路“,如果把精力全部放在”修路“上反而没有精力去”开车“,毕竟”车到达目的地“才是重点
    4. 敏捷团队的所有人都要参与质量管理
      ”车“和”路“都有了,但是把“车”开到”目的地“还早,小心“路上有坑”!
      敏捷开发提供了快速的工具,但是它毕竟只是工具,真正的完成目标还需要注意过程。

    2.3 敏捷开发中质量人员的角色分配

    传统质量管理角色(QC、QA和QM)
    img

    根据质量管理4.0的终极目标“消灭质量部门”,是不再需要质量人员的。

    但是实现这个终极目标是需要进行很大的前期工作的,所以QM、QA、QC人员在这个阶段仍然是不可或缺甚至说很重要的,他们需要向着“消灭自己”持续奋斗

    • QM职在建立敏捷质量体系,需要真正理解质量管理、敏捷开发,定义质量体系结构。必要时QM可以扩充为一个组织(包括boss、总监、各级主管)

    • 跟质量上限是一样的道理,QA人员通过质量文化传播、不断改进等方式为团队带来质量上线的不断提升。

    • 同样QC人员通过功能测试、探索测试等方式为团队提供质量下限

    其实敏捷开发中的质量人员角色,相较于上图的角色定位都向前迈出了半步。QC需要做一些QA的工作,QA需要掌握QM的基础,QM由部门走向全员组织。而最基础的QC检验即将被淘汰,所以说敏捷开发中

    • 如果你将自己钉在 传统QC的位置上,基本上死定了。
    • 如果你将自己盯在 QA,那么可以提升自己的系统思维方式,让你对质量有比较清晰的认识。
    • 如果你将自己定在 QM上,你将是质量体系的组织者

    三、敏捷开发&QA

    3.1 敏捷开发&QA

    敏捷开发需要团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。敏捷中的QA可以是参与敏捷开发的所有团队人员,而并不一定是特定的专职的测试人员。但是当没有团队人员主动负责时,仍然需要有人带头进入这个角色,测试负责人是最合适的人选。

    那么QA人员在敏捷开发中可以做什么?

    协同确定质量下限

    1. 协同确定敏捷流程
      敏捷开发并不代表着没有流程,只是将很多效益很小的环节变为面对面沟通,减少大量不必要的时间浪费。QA需要做的事情就是参与整个敏捷流程的制定,识别必要环节进行保留,保证过程质量
    2. 协同确定各环节输出标准
      (1)敏捷开发可能会使产品人员去掉MRD文档,但是PRD文档是不可或缺的,对于PRD的输出还是要有一定标准,保证产品环节流入研发环节的质量
      (2)敏捷开发提倡TDD、BDD等开发模式,目的就是因为开发人员更了解自己的代码,通过让开发人员自测的形式提高提测的质量,以达到适当减少集成测试时间的目的。通过对单元测试覆盖率、通过率等标准的制定,保证开发环节流入测试环节的质量
      (3)测试人员作为产品的最终守护者,是面向用户前的最后一道质量防线,更要有严格的准出标准满足产品的合格。
      (4)运维人员作为部署者,需要执行系统包的上架、数据库的割接等等事项,面向服务器的直接部署同样需要上线标准较少人员失误带来的部署问题

    保证质量下限

    1. 对于制定的一些标准仍然需要监督遵守,毕竟人总是喜欢偷懒的,没有一段时间的监督是没办法让所有人自觉遵守的。所以QA要监督团队的质量下限遵守,让所有人慢慢养成习惯才可以
    2. 必要的时候QA需要充当Scrum Master的角色,参与敏捷流程各个环节引导团队成员正确前进,以达到提升质量的作用

    发现风险,提出关键建议

    1. QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的。也更容易发现各个环节潜在存在的风险,提出并持续关注
    2. 参与整个开发流程,对于产品、开发、测试、运维环节的计划等,站在质量人员独有的视角提出一些关键的意见

    传播质量文化,鼓励挑战质量上限

    1. QA参与整个开发流程,不可必然的需要同每个环节的人员沟通交流,QA需要在这些交流中不断的传播质量文化
    2. QA需要在传播质量文化的同时,也要鼓励团队人员挑战质量上线。

    数据统计,持续改进

    1. 数据统计,这是QA必须掌握的一项技能。要主动寻找统计对象,通过不同的统计数据进行分析,发现敏捷开发、产品等等存在的问题
    2. 持续改进,将参与开发流程、数据统计发现的问题,组织进行持续的改进,让整体质量不断提升

    3.2 敏捷QA,你需要具备哪些素质

    1. 不爱说话?别做敏捷QA了
      如果你之前是安安静静专心找软件缺陷的工作模式,那么进入敏捷团队你可能会经历很长时间的不适应。因为敏捷QA不能被动地等待软件完成交到你手里再做测试,不能发现缺陷后不管不顾等着开发人员自发地去修复。你需要从软件的源头开始介入,在软件的整个生命周期中全程参与。
    2. 心态不好?趁早放弃
      不知道你是否经历过这样的场景,在某些小餐厅等位严重的情况下,你需要站在某个快要结束用餐的客人边上等空位,而有些人却可以在用餐结束后无视旁边焦急等待的人群一直占着座位专注地聊天。虽然这种行为不是很好但也无可厚非,换个角度想,这种人的心理是非常强大的,因为很少有人能够不顾及别人而我行我素,而这种“能力”对敏捷QA是非常有用的。
      如果处处顾虑别人的想法,会让你左顾右盼、思前想后直接影响你的判断和决定。
    3. 对PM、业务、代码、架构没兴趣?敏捷QA不适合你
      敏捷QA需要对整个系统以及业务足够熟悉,这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分。
      另外如果可以具备一些编码能力,对于做敏捷QA也是非常有帮助的。当然,术业有专攻,并不要求每个QA都会写代码,但是要对代码有一定的兴趣,愿意听开发人员讲解他们的逻辑和实现,并通过提问题了解他们的思路。
    4. 不会管理工作的优先级?做敏捷QA很难
      敏捷QA最大的挑战是,每时每刻都同时工作在很多事情上,敏捷QA需要全程参与开发流程跟很多人进行沟通,时刻关注风险等等。管理自己的工作任务、划分优先级是必备素质

    四、敏捷开发&测试

    敏捷开发与测试的关系,不得不提到敏捷测试,
    敏捷测试的理解建议阅读你确定你懂什么是敏捷测试

    4.1 敏捷测试&测试

    敏捷测试中测试人员需要做什么?
    分析用户需求,代理PO(产品负责人)
    在敏捷开发中PO责任重大,但是PO也会有繁忙、遗漏的时候,敏捷测试人员必要的时候要充当PO代理,帮助产品负责人补充、细化需求、完善用户故事等。
    测试人员面向的对象是产品,想要真正保证产品的质量,对于需求的理解是最重要的。

    不仅是编写测试用例,测试需求(定义质量)
    敏捷测试不仅需要编写测试用例,还需要测试能否完整理解产品需求,根据产品需求转化为测试需求,根据产品需求点转为为测试点。
    对于测试进行需求化管理,站在研发的角度转换测试需求,更利于业务需求的澄清,让开发、其他测试人员对于需求有更深入的了解。
    同时测试需求的转化,也是对于质量的定义。在测试需求转化过程中必定会加入测试要求,这不就是对于需求质量的定义嘛

    保持质量视角,参与过程评审
    敏捷开发流程中会有一些必要环节的评审,例如需求评审、设计评审等等。作为敏捷测试人员不仅仅是要参与这些环节,而是要保持质量的视角发展问题,例如需求是否不闭环、概要设计是否不完善、需求是否不清晰、设计是否不可测等等。

    与客户和开发者紧密合作
    根据工作性质,作为团队第二位对需求最了解的人,测试人员需要定期或经常与客户(业务)沟通合作;并且作为需求二次转化者,你同样需要跟开发者紧密合作。
    发布演示(UAT验收)等环节,建立了一条让测试人员与客户(业务)沟通合作的通道,要好好把握沟通渠道,直接的沟通可以让你对需求更加了解
    测试需求的评审、开发过程需求的问题,都需要测试人员与开发者进行紧密的合作,让需求讨论、问题定位变得快速简单

    提供快速反馈
    敏捷开发提倡快速沟通反馈,对于测试人员也是一样的。快速反馈系统存在的问题,以便于图啊对快速做出应对。
    例如重视冒烟测试,快速验证系统是否可执行,避免测试工作无法进行浪费时间;根据更为详细的测试需求,快速检查验证是否有开发遗漏,尽快进行补充;测试遇到的问题,快速反馈进行解决;测试进度快速反馈,提醒运维人员提前准备介入等等

    用测试策略规范测试
    前面对于敏捷开发中质量人员角色的定位,测试人员要保证质量下限。那什么方式可以让测试人员保证质量下限,人员素质是一个重要因素,但是你并不能保证所有测试人员的素质都可以快速提升,这个时候规范的测试流程就是最根本的保障。
    测试策略是一个很大的课题,推荐阅读刘琛梅老师的《测试架构师修炼之道》,对于测试策略有较深入的讲解,我对于这本书也有进行过一次阅读分享

    测试者和分析者角色融合
    敏捷测试中需要测试人员将测试者与分析者融合,站在测试角度分析需求合理性、站在测试角度分析系统可测性等。
    分析者习惯将问题解剖,而测试者会带着“挑剔”的眼光审视问题,两者的融合不就是将问题解剖发现内在的“缺陷”嘛

    掌握探索测试(合适的探索性测试)
    首先需要理解探索性测试,探索性测试简单理解就是在功能测试完成后,根据系统逻辑不断探索边界,逻辑的边界、部署环境的边界、系统的边界等等,去发现更多的问题。
    合适的探索性测试,探索性测试并不是没有规律的盲测,它一样需要规律条件刘琛梅老师的《测试架构师修炼之道》也有提到这一点。
    不要陷入探索性测试,你的底层基本功能都还没有测试完成就去探索,那将没有任何意义

    自动化回归测试
    敏捷开发提高的是效率,而对于测试人员而言一样的需要提高效率,将大批量的旧版本旧需求的回归自动化,不久节约了大量的时间可以用来进行新功能、新需求的探索性测试了吗?但是请记住敏捷开发中的自动化测试同样讲究的是效率。
    而对于UI自动化,建议跟前端配合将页面元素id规范化,共同制定一套id规范才有利于UI自动化的维护,PO模式确实也是是很好的选择
    相对于UI而言,接口可能更适合先进行自动化,同样可以借鉴UI的PO模式管理,减少维护成本

    BDD(题外话)
    很多公司会引入TDD开发模式,先写单元测试在写代码;如果在TDD做好的情况下,可以继续进入BDD,针对于业务需求白盒可能比黑盒可能更能发现问题,毕竟直接调用内部函数比调用整个系统发现的问题的可能性更大。

    参考1 https://www.sohu.com/a/128624542_177747
    参考2 https://wenku.baidu.com/view/b9080553ed630b1c58eeb564.html
    参考3 https://www.cnblogs.com/mikeyond/archive/2011/06/30/2094274.html
    参考4 https://segmentfault.com/a/1190000019268535
    参考5 https://www.jianshu.com/p/d5496e5247c7

    展开全文
  • 读者将从该书收获测试人员如何参与敏捷开发测试人员和QA经理如何适应敏捷团队敏捷测试人员的招聘要求是什么如何从传统模式迁移到敏捷模式如何在短期迭代完成测试任务如何利用测试指导开发如何克服困难实现测试...
  • 敏捷团队中QA由来

    2019-08-12 01:24:10
    QA,全称为Quality Analyst,即质量...敏捷项目QA日常都做什么事情那?可能一大推问题都会冒出来。别急,跟着我这篇文章来一步步的回答这些问题。 假设现在有一个保险公司,他想找一个软件公司做一个...

    QA,全称为Quality Analyst,即质量分析师(有些称为Quality Assurance,即质量保证师)。为什么它总跟质量扯在一块?感觉这个角色明明做的都是测试的事情,为什么不直接叫做tester那?敏捷项目中的QA日常都做什么事情那?可能一大推问题都会冒出来。别急,跟着我这篇文章来一步步的回答这些问题。

    假设现在有一个保险公司,他想找一个软件公司做一个在线卖保险的系统。那么这个系统从开始到完成至少需要三个角色。

    Business owner -> developer -> end user

    • Business owner即保险公司的人,也是我们的需求来源,由他来提出业务需求。
    • developer即软件开发工程师,根据客户的需求做出客户期望的产品,最终交付给客户。
    • end user即产品的最终用户,在本例子中即有意愿在网上买保险的人。这个系统到底好不好用,他们最有发言权。(有的时候end user和business owner有可能是同一批人,比如开发的是一个内部公司使用的OA系统)。

    只有这些角色能够顺利、成功的完成一个产品吗?实际操作中肯定会遇到很多问题。这些问题会集中在两个地方。

    第一个问题出在Business owner和developer。在沟通需求的时候他们彼此会发现太费劲了。Business owner张口就来的quote、premium、policy这些名词软件开发工程师不懂什么意思,因为他们没有保险行业的背景知识,而软件工程师喜欢说的MVC、BDD、Java之类的,Business owner也搞不懂,并且人家对这也不感兴趣。那么软件开发工程师想,如果有人能即懂得保险行业知识,又具有IT背景,那么分析需求肯定会顺利不少。这样的人在敏捷团队中就叫做BA(Business Anslyst,业务分析师)。BA会理解并挖掘客户的需求,然后将需求转变为具体的AC(验收条件,Acceptance critirial),再交由开发工程师来实现。同时他也可以将业务知识最大化的传递给开发工程师,保证开发工程师能够准确的理解需求(为什么不让Business owner直接将业务知识传递给开发工程师那?原因很简单,人家可是一秒钟几十万上下的主,那里有这么多闲工夫。)

    所以系统从开始到完成变成了这个样子。

    Business owner -> BA -> developer -> end user

    另一个问题就出现在了developer和end user之间。开发工程师完成的系统能够直接拿给最终用户用吗?如果你说能,要么你是对自己的产品信心十足,要么就是盲目乐观。我想大多数情况是后者。因为开发工程师在将业务需求转换为编码实现时,一方面由于理解的问题,实现或多或少可能会与需求有所偏差。另一方面由于自身思维的局限性,会导致系统隐含了一些缺陷。假如最终用户在使用系统时,发现在线支付有问题,或者页面在自己所用的浏览器下不能正常显示,你觉得他们还有兴趣使用你的系统吗?这就相当于把最终用户当做系统的测试者,人家不收钱还帮助我们发现bug,那里有这好事?系统的问题要尽可能的避免暴露给最终用户。那么在软件开发工程师和最终用户之间应该再加一个角色,就是tester。tester的主要职责就是按照AC,对系统进行功能性测试,确保功能的正确性,另一方面是针对一些非功能性测试(比如安全性测试,性能测试),保证系统的健壮性。

    Business owner -> BA -> developer -> tester -> end user

    做到这些的tester还不能称之为QA,因为它的角色更像是软件质量的看门人,最终把关者,还达不到测试分析的要求。

    现在新的问题来了,到底tester什么时候该开始对软件的测试那?

    一个极端情况是等developer把所有的功能完成以后,再交给tester来测。这样会造成很多问题。

    1. 如果开发者需求理解有偏差,需要重新返工。
    2. 软件中发现了bug,该功能是很久以前开发完成的,developer定位和修复要花很长时间。
    3. 有太多的功能需要测试,tester要花很长时间,developer又要修复发现的bug,这段时间不可预估,虽然是属于项目上线的最后时刻,但是整个系统始终处于一个不稳定的状态。

    大家都知道在软件工程中,需求变更发生的越晚,bug发现的越晚,会软件开发的影响会越大。这种极端情况的做法是不可取的。

    那么应该怎么做那?我们可以将整个系统的功能细分成很多小功能点,每一个小功能点都是独立可测的,那么一旦开发工程师完成此功能点,tester立马就可以拿去测试。每一个小功能点就是敏捷中所说的用户故事(user story)。

    一个user story的典型的生命周期是这样子的。

    • backlog -> BA将刚建好的story卡放置在backlog list里
    • Analyse -> BA细化story卡,完成验收条件等内容的编写
    • development -> 开发人员进行开发工作
    • testing -> 测试人员进行测试
    • UAT -> 用户验收测试,Business owner会对功能进行确认
    • Production -> Business owner准许后,将功能发布到生产环境

    如果只是实现这样的流程,那么这个团队还不算是真正的敏捷团队,这里的tester也不算是真正的QA。因为业务需求通过Business owner到BA再到DEV到tester,是一个衰减的过程。小时候我们玩过一个游戏,老师让一群人排成一排,他会给第一个人说一句悄悄话,然后让第一个人偷偷讲给第二个人,第二个人再原封不动的讲给第三个人..直到最后一个人把这个悄悄话讲出来和老师的原话比较,我们往往发现最后一个人的话很难和老师的原话保持一致,甚至意思会大相径庭。那么这就意味着tester在做测试的时候他不一定能够真正了解业务的实际需求,所以在测试时难免会出现纰漏。这样的卡最后让business owner确认时,很难避免给business owner “惊喜”。

    所以为了解决需求衰减的问题,tester要尽早的介入到的story的前期工作。在BA分析故事卡的时候,tester就可以根据卡的内容准备测试策略、测试环境,甚至准备测试数据。在开发人员领取卡的时候,tester可以从测试的角度给开发人员提供一些建议。而在开发人员开发卡的时候,tester可以和开发人员一起pair编写自动化的测试用例。开发人员开发完毕后,tester可以在开发人员的本地环境中快速验证其是否满足所有验收条件,必要的自动化测试是否已经完成等。在UAT环节,tester又可以帮助business owner进行sign off。

    这个时候需求的传递已经不是一个简单的链式的行为,测试人员作为连接器把需求良好地串联了起来。测试人员的职责范围已经超出了我们通常所理解的范围。这个时候再用tester这个称呼已经无法涵盖该角色的职责了。所以就有了QA(质量分析师)这一角色。可以看出在敏捷团队中QA并不是质量的最终把关者,而是在项目开始就参与到了质量的控制当中,一直贯穿到所有环节。

    如果想了解敏捷团队中QA的具体职责,可以参见我司的同事的文章《敏捷中的QA》. 如果你想知道自己适不适合QA,请参见我司另一位同事的文章《敏捷QA,从入门到放弃》

    转载于:https://www.cnblogs.com/huang0925/p/6230776.html

    展开全文
  • 敏捷开发与敏捷测试

    2013-02-26 16:05:50
    随着软件开发方法的不断演进,敏捷开发方法在各软件企业和团队中应用越来越广泛。传统的瀑布式方要求有详细的项目计划和文档,部署、QA测试和交付过程严谨。而敏捷方法的优点则体现在能够快速迭代,更多的强调人员在...
  • 敏捷开发QA面临的10个挑战 敏捷开发QA面临的10个挑战 1.没有MRD,如何管理好需求? 2.没有需求评审,怎么保证需求质量? 3.研发模式变更,怎么把握进度? 4.没有详细设计如何保证设计没有问题? 5.没有测试设计...
  • 敏捷中QA

    2019-04-09 11:00:27
    说到QA,通常指的是质量保证(Quality Assurance)工程师,但...\ 质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队...
  • 敏捷开发,到底需不需要 QA?” 答案是……当然是需要的。 只是期望 QA 能从传统的专注在 “流程质量”,转而与团队在一起,共同专注 “产品质量”。 所谓专注 “流程质量” 指的是:只关注团队 “有没有” 搞持续...
  • The basic idea behind testing测试背后的基本思想 Common types of testing常见的测试类型 Black box testing黑盒测试 White box testing 白盒测试 Acceptance testing验收测试 Automated testing 自动化测试 ...
  • 十招玩转敏捷测试

    2019-07-05 10:16:32
    随着敏捷转型的深入,与敏捷开发相匹配的 QA 活动引起了业界的思考和探讨。 一般来说敏捷转型共分三步走,即: 第一步:玩熟敏捷管理; 第二步:保证敏捷自动化测试效果; 第三步:确保一体化管理和工具平台各就...
  • 如今互联网行业,每天有无数的公司倒下,同样也有无数的公司站起来。 越来越多的人将「敏捷开发」搬上台面...我在好多论坛或者交流群也见过有人问关于自己的团队适不适合「敏捷开发」的问题。 所以今天,我来说说
  • 这篇文章本该几个月前就发,实习这么久来,实习的第一份工作是传统的大瀑布模型的项目,但是团队也是在搞敏捷迭代开发,所以也算是敏捷团队吧,那么这篇文章就聊一聊敏捷。 为什么要搞敏捷? 这就要说下传统的大...
  • 敏捷开发中团队成员认领的是任务还是用户故事?
  • 敏捷项目QA日常都做什么事情那?可能一大推问题都会冒出来。别急,跟着我这篇文章来一步步的回答这些问题。 假设现在有一个保险公司,他想找一个软件公司做一个在线卖保险的系统。那么这个系统...
1 2 3 4 5 ... 20
收藏数 4,798
精华内容 1,919
关键字:

敏捷开发中的测试qa团队