敏捷开发 编码 质量_敏捷开发 编码 - CSDN
  • 敏捷开发模式下的质量管理

    千次阅读 2016-11-04 16:56:56
    主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到...

      前几天,笔者与一位在大型互联网公司从事质量保证的朋友交谈,作为互联网产品质量和测试的负责人,他最近负责的质量管理方面遇到了很多困难。主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到开发团队的认可,离职率非常高;5)质量部门无法收集到数据,不能进行质量度量;6)测试团队也有一批自动化测试专家,但派不上用场…..这些问题可能很多开发团队都会遇到,总结一下,大致是这几个方面:

        

    }        越来越多的企业希望采用,但没有把握

    }        习惯于传统的瀑布式产品开发流程已不满足快速发展需要,但大规模改动不现实

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

    }        技术人员需要观念的转变和方法培训

    }        缺乏相应的质量控制方法

    }        需要经常的和及时的质量度量、测试、决策

    }        自动化测试不能落到实处,每日构建仍是纸上谈兵

    在现在行业中,需求变化太快,不管我们怎么努力去做,发现还是不能满足客户的需要,不管需求搞得多么细,到交付产品给客户的事情,总是有这样那样的问题,这个时候就不得不去修改我们的软件,这是目前很多企业尤其是互联网公司面临的一个挑战,如何解决这个问题?

    笔者先后在华为、阿里巴巴软件质量部门任职,最近也深入研究了腾讯敏捷开发平台TAPD(腾讯敏捷产品开发)和IGD(集成游戏开发)一些资料,对国内敏捷项目的质量管理有很多独到的见解,结合共创力咨询公司多年的项目经验,总结如下:

    1)QA角色的转变

    QA要从警察的角色转变到一个教练的角色。在以前,团队实施CMM的时候,QA更多的是一个警察的角色,他整天拿着一个checklist、报告什么的到处去团队里面看,你是否ok,不ok就要怎么怎么样,整天就干这个活,但是引入敏捷之后,QA就觉得有点失落,都敏捷了,我都不知道该怎么下手了,在著名的通信企业华为的做法是将QA转变了一下,将QA更多的充当教练的角色,充当SCRUM Master的角色,他去指导项目团队该如何去开这个站立式会议,该怎么去做迭代的计划等等指导性的工作,这样QA也觉得挺好,这样他能参与到在不同的团队中去,QA的角色更多的偏向于全过程的敏捷活动指导,以提高产品开发效率和质量。QA在这个过程中也能得到一些数据,如代码缺陷率,版本的不良率,上线遗留问题数,团队成员配合度等等。

          2)要使敏捷团队整体参与

       QA和测试人员也是敏捷团队的一部分,作为敏捷教练,要向他提供支持和训练,以使作们适应开发的快节奏。比如,如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独立定义故事和需求,那你应该主动站出来和团队的其他成员交流,并偿试“三方协作”,即测试人员、开发人员和业务专家。腾讯公司把业务专家称为BA,即

       Bussiness Analyst, BA和开发人员DE、测试人员TE组成了敏捷开发团队,这些成员不仅仅把都在忙着最终的交付而努力,他们还乐于收集和分享信息,与客户或者产品负责人协作以帮助他们充分展示自已的需求,从而得到他们的需要的功能,同时向所有人提供项目进展的反馈。

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

    4)            提供并获取反馈

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

     

     

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

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

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

    灰度发布。这是互联网产品的一个特点,说白了,就是对用户一个逐步放量的一个过程,而且不要求团队要尽早 的将产品包发布出来,也就是不要求马上发布给所有用户,而是会分批的去发布,比如按号段发布,比如在公司内部先体验。发布的时候也有策略,比如发布时如何放量,对用户有些什么样的实验,技术上怎样做一些后台开关,运营上怎样跟进,怎样保证4小时人员的留守,发布完后怎样收集用户反馈等等都会有一些统一的规则。比方实验室某WEB产品的发布,可以同时有多个版本,1.1版可能会有100%的用户在用,1.2版可能只有1%的用户在用,它们是一个交叉升级的过程,目前腾讯采用了该活动。

    每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。笔者在阿里巴巴工作时,就经历过每日晨会,一般主持人由敏捷团队的成员轮流担任,这个时候可以了解每天发生的问题。

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

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

    迭代回顾会议。在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步;围绕如下三个问题:本次迭代有哪些做得好?本次迭代我们哪些方面还能做得更好?我们在下次迭代准备在哪些方面改进?会议需要Team全员参加,气氛宽松自由,畅所欲言,头脑风暴发现问题,共同分析根因;会议关注重点是Team共同讨论优先级,将精力放在最需要的地方(关注几个改进就够了);会议结论要跟踪闭环。

     

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

    展开全文
  • 敏捷开发中的质量

    2019-06-11 21:46:33
    有小伙伴就问,我们都敏捷了,我们是在效率和质量中找平衡,说敏捷开发中的质量是不容易控制的,要回答这个问题,我设计了一个FAQ,内容如下: 敏捷开发是什么? 敏捷开发是以需求为中心,以交付价值为目的,...

    有小伙伴就问,我们都敏捷了,我们是在效率和质量中找平衡,说敏捷开发中的质量是不容易控制的,要回答这个问题,我设计了一个FAQ,内容如下:

     

    敏捷开发是什么?

    敏捷开发是以需求为中心,以交付价值为目的,持续增量交付的一种软件开发方法,至于什么是敏捷,就去问问度娘吧。对于敏捷团队来说,是一个自组织的,有集体目标感的,打了鸡血的理论上的全功能团队。

     

    软件质量是什么?

    简单点说,软件质量就是软件产出的结果与原始需要的相匹配程度,包含的方面包括简装修、正确性、效率、完整性,可维护性,灵活性等等等等。

     

    相对与敏捷开发,传统方式开发中软件质量是如何控制的?

    一般来说,对于软件质量的控制是多角色、多层次的,一般会包含这些活动:

    1、过程管理,一般由QA这个觉得通过一些手段来保证整个软件开发过程的正确性;

    2、评审活动,通常来说,在项目中产生的所有成果物都需要经过评审才能被使用或接收,从需求开始,也包含所有的设计文档,测试用例,还有代码等等;

    3、问题管理,经过评审了,那就不可能不出现问题,出现了问题怎么办呢,那就需要修正、跟踪,当然了,不是所有的问题就是由评审这个活动衍生出来的,也可能是由哪个项目干系人发现的,也有可能是由风险引发的;

    4、测试,测试活动像项目中的其他活动一样,也需要计划、实施、验证,也会包含一些其他的管理方面,包括用例管理,缺陷管理等,另外,测试是分阶段分层次的,要根据需求的双向可追踪性进行测试规划,还有很多的测试策略等等,测试是一门专门的学科,有机会我们再探讨。总之,测试在软件研发活动种是重要的,也是必不可少的。

    一般来说,反映软件质量的指标和工具有比如,代码测试覆盖率,单位缺陷密度,帕累托分析什么的,这些学过PMP的同学都驾轻就熟,我就不多说了。

     

    在敏捷开发中如何保证软件的质量?

    一般在敏捷开发中,提倡的是团队整体参与的做法。也就是说,不只是单单一个质量,所有的事情都是全民参与的。那角色还是那些角色,QA和测试干啥去?其实,在敏捷开发中,这两种角色有更高层次的价值体现,比如说,她们更像是一个团队支撑着和发现者。作为用户的角色参与到项目中,提供交付价值的建议帮助需求提供者确定验收标准,帮助团队搭建测试自动化工具,做探索性测试等等,保证需求和过程的正确。

    在敏捷软件开发中,通常团队会做这些事情以保证质量,并贯穿整个开发过程中

    1、团队中统一的标准和工具,统一的IDE,统一的编码风格和规范,甚至统一的作息习惯,让团队更像是一个整体

    2、静态代码检查,既然有统一的编码规范,这个活动完全可以用机器来解决,不符合规范的无法提交到版本库

    3、持续的单元测试,甚至是测试驱动开发(TDD),由编码人员同时编写单元测试用例和代码

    4、持续集成,持续检查,持续测试,持续发布,在过程中保证代码、需求、活动、业务行为的正确

    5、重构,敏捷是快速交付的,总有些技术债是要还的,代码的改进也是改进的一部分

    6、回顾,事后诸葛亮的事,为项目目标造成阻碍的事件或者是一些典型的缺陷都要彻底分析

    7、与客户合作,只有客户才知道他要的到底是什么(也可能有的时候根本就不知道),只有看见的成果才能有建议,满足客户的需要也是质量的重要部分

    在敏捷中,我们跟关注缺陷或者问题存在了多久,而不是他存在多少,也就是缺陷或者问题的生命周期,这个指标一般我们会定义缺陷的几个状态,比如说,open-fixed-close-reopen等,我们看在每个阶段停留的时间,分别去看看缺陷定位的时间(缺陷是不是描述的竞争),缺陷修复时间(改了多久),改了几遍(改没改对或者引发其他缺陷的)。另外,现在比较火的就是DevOps了,好处就不多说了,在这个过程中,有很多地方都是与质量和业务价值相关的,有兴趣的小伙伴请自行度娘。

     

    经常看到有小伙伴反映因为过渡到了敏捷开发导致质量崩塌的案例,其实我觉得大家都有个误区,不一定我们追求效率了,那一定就会牺牲质量(另外,敏捷绝对不是用更短的时间),只不过我们可能没有找到合适的方法,或者说团队还不是那么的敏捷。所以对于质量这件事来说,不管是传统方法还是敏捷,我觉得企业质量文化对软件产品质量还是最重要的。总是能找到一种合适的方法,把项目质量搞上去。

    展开全文
  • 敏捷开发中QA如何做质量管理?

    千次阅读 2019-05-10 09:15:47
    敏捷开发中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

    展开全文
  • 敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论,敏捷开发是追求高质量软件的方法论和过程。 本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的
  • 我相信这些问题都是推广敏捷开发的企业或者 Scrummaster 经常面对的问题。本 Chat 将重点从代码静态检查、Gerrit代码走查、SonarQube、持续集成与自动化等方面分享我们的内建活动经验,推动开发人员输出高质量的代码...
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  •   敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的代码质量。 Java项目开发过程中,由于开发人员的经验、Java代码编写习惯,...
  • 浅谈敏捷开发

    2020-04-11 14:29:17
    浅谈敏捷开发 敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 章节 ...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    本篇分享的是:【什么是敏捷开发 】 目录: 1.几种开发方法 1.1瀑布式开发 1.2迭代式开发 1.3螺旋式开发 2.敏捷开发 2.1 敏捷开发的诞生 2.2敏捷开发宣言 2.3 敏捷开发 3.敏捷开发方法 ...
  • 当我们熟练的采用了敏捷开发后,不要以为开发人员就是编码就行了,编码前进行详细设计(本文中说到设计都指详细设计)才是保证软件质量的根本,敏捷也是一样要进行设计,只是设计输出相比传统的开发方式要简化,本文...
  • 敏捷开发 vs 传统模式

    万次阅读 2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,...
  • 敏捷开发中的 Java 代码质量保证步骤   回页首 步骤一:统一编码规范、代码样式 规范统一的编码会增加项目代码的可读性和可维护性,但实际情况往往是项目组内的 Java 代码开发人员的编码风格常常各不相同,...
  • 敏捷开发中的测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷中的QA敏捷QA的日常活动敏捷QA与...
1 2 3 4 5 ... 20
收藏数 14,373
精华内容 5,749
关键字:

敏捷开发 编码 质量