敏捷开发的人员与角色_敏捷开发 角色 - CSDN
  • 敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的...

    敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的(指一个办公室内坐在一起的),建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

    敏捷开发中的SM即Scrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

    Product Owner(PO)

    Product Owner角色定义

    确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROI(profitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

    Product Owner工作职责

    负责最大化产品以及开发团队工作的价值。主要职责如下:

    1、确定产品的功能;

    2、决定发布的日期和发布内容;

    3、为产品的ROI负责;

    4、根据市场价值确定功能优先级;

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

    6、接受或拒绝开发团队的工作成果;

    7、参与Scrum Planning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)

    Product Owner在团队中的作用

    在junior团队中:主要的需求来源,个人确定需求价值和优先级

    在intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

    在Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

    这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

    一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

    Scrum Master(SM)

    Scrum Master角色定义

    是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

    Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

    Scrum Master工作职责

    确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

    1、保证团队资源合理利用;

    2、保证各个角色及职责良好协作;

    3、解决团队开发中的障碍;

    4、作为团队和团队外部的接口,协调解决沟通中的问题;

    5、保证开发过程按计划进行,组织Scrum Planning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

    Scrum Master在团队中的作用

    在junior团队中:主导和控制

    在intermediate团队中:引导和教导

    在Senior团队中:辅导和协助

    一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    案例分享

    某Team在Plan Meeting会议中,邀请了PO参加,但PO因会议时间冲突未能参加,在讨论Sprint  Backlog的时候,因需求有变动,团队未完全按照product  backlog上的优先级去拿,选好Sprint  Backlog 后,Scrum master详细讲解了每一条Sprint  Backlog应该如何拆分及理由,最后给出了每个task的评估工时。

    问题一:PO未参加计划会

    应与PO提前协商时间,若PO没有时间需调整时间,PO一定要参加;

    问题二:未按已排定的优先级做

    如果不按照product  backlog上的优先级去拿需要和PO一起决定;

    问题三:SM一个人完成需求拆分和工时评估

    任务的拆分及工时的评估需要和团队共同确定,不是Scrum master一个人说了算。

    在敏捷开发团队内部,PO和SM角色是非常重要的,基本决定了团队是否可以很好的执行敏捷开发这种模式,因此这两个角色一定都要十分熟悉敏捷开发的整个运转流程,带领和引导团队一步一步的往敏捷的方向迈进。很多时候PO和SM的不专业,很容易使团队偏离敏捷的模式,因此决定一个团队能否完全进入敏捷开发模式时,这两个角色很关键。

    展开全文
  • 敏捷开发中的PO即Product Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品...

        敏捷开发中的POProduct Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

        敏捷开发中的SMScrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

    Product OwnerPO

    Product Owner角色定义

    确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROIprofitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

    Product Owner工作职责

    负责最大化产品以及开发团队工作的价值。主要职责如下:

    1、确定产品的功能;

    2、决定发布的日期和发布内容;

    3、为产品的ROI负责;

    4、根据市场价值确定功能优先级;

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

    6、接受或拒绝开发团队的工作成果;

    7、参与Scrum Planning MeetingsSprint计划会议),Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)

    Product Owner在团队中的作用

    junior团队中:主要的需求来源,个人确定需求价值和优先级

    intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

    Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

    这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

    一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

    Scrum MasterSM

    Scrum Master角色定义

    是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

    Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

    Scrum Master工作职责

    确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

    1、保证团队资源合理利用;

    2、保证各个角色及职责良好协作;

    3、解决团队开发中的障碍;

    4、作为团队和团队外部的接口,协调解决沟通中的问题;

    5、保证开发过程按计划进行,组织Scrum Planning MeetingsSprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)。

    Scrum Master在团队中的作用

    junior团队中:主导和控制

    intermediate团队中:引导和教导

    Senior团队中:辅导和协助

    一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    展开全文
  • 敏捷开发中测试角色的窘境 先说说敏捷开发中码农哥哥测试妹妹的一段恩怨情仇: 测试妹妹:需求文档在哪里? 码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲...
    敏捷开发中测试角色的窘境


    先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇:


    ------------------------------------------------------------------------------------------------------------------------------

    测试妹妹:需求文档在哪里?
    码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲一下吧。
    测试妹妹:好吧,懂了,那我开始测了。

    测试妹妹:测试完了,有5个bug,我都提交了,你看看吧。

    码农哥哥:好的,还有一个新需求,再和你讲一下。

    测试妹妹:终于测完了,全部测试通过了,恭喜啊
    码农哥哥:sorry,刚我改动了一个小点,你再重新回归测试一次吧,这次应该OK了。
    测试妹妹:终于回归完了,又发现一个问题...

    产品经理:客户反馈了一个bug,你赶紧看看
    码农哥哥:不可能啊,这个功能我都测过的,我看看
    码农哥哥:真晕,线下测试是好,线上有问题,有个配置错了,另外这个客户的数据比较奇怪,测试也没有验证过这种场景
    产品经理:XXXXXX,客户已经提故障了!
    码农哥哥:下次线上发布一定要叫上测试妹妹仔细回归

    码农哥哥:今天晚上12点产品更新,到时要你来回归验证啊
    测试妹妹:好吧
    测试妹妹:你们发布完了吗?都凌晨2点了,我什么时间可以回归验证啊?
    码农哥哥:再等等,还有一个小问题在搞。
    测试妹妹:现在好了吗?
    码农哥哥:sorry,没搞定,发布要回滚了,今天不需要回归验证了,你先回去吧
    测试妹妹:你妹啊!!!

    ------------------------------------------------------------------------------------------------------------------------------

    故事讲完了,以上就是一些项目敏捷开发中很常见的问题。

    敏捷开发强调的是快速迭代,通过快速迭代发布并验证产品是否满足用户需求来减少产品风险,而不是像传统软件一个花一年甚至几年才发布。敏捷开发在互联网行业里非常流行,大型网站基本每周都会有发布,甚至一周发布几次,超大型网站的应用都是分布式的,一天都可以发布上百个feature。
    互联网的需求变化很快,有些产品也是实验性的,所以更需要快速迭代,这也会导致许多产品在一些小的需求都没有需求说明书或者设计文档,全是靠产品经理与研发同学沟通需求,然后就快速发布上线了。这种模式在传统软件里是不可能,传统软件都会有很强的产品版本概念,并且会对每次升级都要制定详细的设计、开发、删除与发布计划。 

    面对互联网这种快速迭代,并且还有时缺少需求与设计文档的背景下,我们测试同学如何跟上节奏。如果按传统模式,测试与研发是不同的人员负责,那么必需要有清晰的需求设计文档,否则测试基本靠感觉。并且产品经理与研发同学还要与测试同学沟通需求,沟通项目计划与资源协同。第二,今天互联网的研发同学普遍比测试同学多很多,有些产品甚至是10:1以上或者是没有测试角色,这样的团队测试同学根本来不及了解需求细节,只能做一些核心主功能验证,对于边界测试没法顾上。总体看起来独立测试角色在敏捷开发里有点力不从心。

    经过几十年的发展,测试类型也细分成很多种,有白盒测试、黑盒测试、灰盒测试、单元测试、功能测试、集成测度、性能测试、压力测试、自动化测试、回归测试、灰度测试、安全测试、恢复测试等等概念。 当前业界的测试工具眼花缭乱,有QTP/UTF、LoadRunner、JMeter、Selenium、TestDirector、QACenter、Rational系列等知名产品,也有很多JUnit、TestNG、RobotFramework、gtest等测试框架,还有更多如网络、数据库、硬件等专业领域的测试工具。

    这些产品,除了JUnit、JMeter这类程序员可以轻松掌握的轻量级产品框架外,其它产品在敏捷开发中都感觉力不从心,主要原因是大部份产品为测试角色开发的,研发角色有学习成本,并且研发同学更喜欢白盒测试。

    如果测试的工作由研发来完成,这会更符合敏捷开发思想,大大减少沟通成本。但是问题来了,研发同学并不擅长使用各种测试工具,研发同学更多只会完成单元测试。如果能有一个专门面向研发同学的测试工具,岂不是很爽,那一个面向研发同学的测试工具应该是什么样的呢?我先说说程序员自测的一些现状:
    1.单元测试:目前JUnit、TestNG加各种Mock基本还能应付,就是测试代码写起来很多
    2.功能测试:这个很头疼,如果软件有界面,可以通过软件操作来完成核心功能测试,如果没有界面,就自己模拟软件对外API接口规约来模拟测试
    3.性能测试:这个要么使用JMeter这样专业工具来完成,实在不行,要不就自己再单独写一个程序或脚本来压测
    4.回归测试:不好搞,面对各种运行环境,人工回归太不靠谱了,真心需要一个全自动化的工具
    5.安全测试:太专业了,估计搞不定
    6.边界测试:写各种边界值来搞死自己,想到的就试试,没想到的就当不存在了
    7.bug管理:都自己测试了,还提个毛bug啊,自己老老实实把屁股擦干净

    从上面看起来,要是交给程序员自测也不靠谱啊,完全是靠感觉,凭经验测试了。

    如果有一款面向程序员自测的专业测试工具,它会是什么样的呢,我列了几点:
    1.学习成本低
    上手很容易,如果是框架,不要超过JUnit这样的难度吧,如果是产品,那应该有一套简单易用的界面,并且不要冒出很多测试概念,不要动不动就来1GB的安装文件,最好能免安装了。
    2.功能测试用例编写简单
    编写功能测试用例,不要只是简单的像bug管理那样写一堆文字描述,测试用例应该是可以运行的,编写完后就能直接运行、验证
    用例编写的语言应该非常简单易学,或者是直接用程序同样的语言(如JAVA、C、Python等),不要让我去学习一套新的语言或规范
    测试用例的代码应该很短,不要是我的业务程序写了100行代码,结果测试用例写了300行代码,这会很奔溃,可能会导致我花了大量的时间在调试测试用例脚本是否正确,如果测试代码小于程序代码的1/5就挺好。
    3.功能测试用例能同样显示测试代码覆盖率等信息
    单元测试可以比较简单的看到测试代码覆盖率,查看未测试到的代码。这个很有用,功能自动化测试希望也能看到这个,这样可以确认哪些地方没有测试到位。
    4.可重用,可扩展
        有些组件是已经写好的,测试用例应该能直接复用,比如java中一些标准jar包函数,或者是自己产品里封装的组件。这样对于编写测试就更高效了。
    扩展性要好,自己也可以封装一些测试组件,供别人使用或者模块公用。
    5.可以自动化回归测试
    面对各种环境:开发环境、测试环境、预发环境、生产环境A、生产环境B,自动化回归测试太重要了,最好是功能测试用例编写完后可以直接用在回归测试里,不要又单独写一套回测试用例。
    6.能自动造测试数据
    造测试数据很花时间,有时还需要造各种随机数据,另外各种边界数据也能自动化最好了,靠人想有时不靠谱的
    7.能支持UI自动化测试
    现在UI测试基本靠人工,Selenium之类的产品IDE比较简陋,语法也需要重新学习,学习成果不低,而且有点地方写起来很难受。需要能有更高效的UI自动化测试支持。
    8.调试方便
      编写测试用例脚本要有方便的调试功能,用例运行过程希望能显示详细的输出日志,特别是在用例运行失败的情况下,不然找问题很花时间。
    9.免费、开源
    你懂的

    最近自己团队也在做这方面的探索,希望能设计出一个适合程序员自测的专业测试工具与方案。 
    好了,写了这么多点,可能我孤陋寡闻,也不知道是否已经有这样专业的产品,谢谢推荐。
    展开全文
  • (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导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
    展开全文
  • 敏捷开发3种角色

    2019-08-21 11:04:29
    在Scrum角色中包括:产品负责人(Product Owner,PO)、ScrumMaster(SM)、开发团队(Team)。 角色:产品负责人(PO) Scrum团队只有一个产品负责人,他负责在限定期限内拟定可能的最有价值的产品。这是...
  • 在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发.     通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正...
  • Scrum敏捷开发角色

    2014-02-22 23:56:44
    在Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们的职责分别是: 产品负责人(Product Owner) 确定产品的功能和完成时间;对产品的收益负责;根据市场需求确定产品功能的优先级;...
  • 通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster. ...
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 概述:主要就敏捷开发模式中对用户角色建模的方法指引。 用户角色建模的目的 敏捷项目中,PO通过编写用户故事,以用户为中心来体现产品的需求内容。所以在编写故事前识别用户角色和虚拟人物,对用户角色进行建模就...
  • 敏捷开发之PO

    2016-07-26 07:55:43
    讲到敏捷开发,那么在每个team里面,都会有一个叫做PO(project owner)的角色.在敏捷开发中,PO这个角色扮演了很关键的作用。首先讲讲PO都会干些什么: 1 PO是开发team客户之间的桥梁,他负责客户沟通,并且...
  •  不同传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 【互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?】 前言================================================ 1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。 第一...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。 一、Scrum的定义和目的 Scrum是一个用于开发和维护复杂产品的框架,是一个...
  • 敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP… 为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum...
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
1 2 3 4 5 ... 20
收藏数 21,316
精华内容 8,526
关键字:

敏捷开发的人员与角色