敏捷开发 测试介入_敏捷开发时测试的介入时间 - CSDN
  • 敏捷开发测试角色的窘境

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


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


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

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

    测试妹妹:测试完了,有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.免费、开源
    你懂的

    最近自己团队也在做这方面的探索,希望能设计出一个适合程序员自测的专业测试工具与方案。 
    好了,写了这么多点,可能我孤陋寡闻,也不知道是否已经有这样专业的产品,谢谢推荐。
    展开全文
  • 在“敏捷开发过程中,自动化工程师先对哪一部分功能进行优先的用例实现:可以从以下几个方面进行考虑:1.优先考虑数据对比类型的功能,这种功能人工操作比较费眼力和时间 2.优先考虑已经测试出问题的功能,这样...

    在“敏捷”开发过程中,自动化工程师先对哪一部分功能进行优先的用例实现:可以从以下几个方面进行考虑:1.优先考虑数据对比类型的功能,这种功能人工操作比较费眼力和时间 2.优先考虑已经测试出问题的功能,这样可以有效的对bug的功能进行回归检查 3.用户使用比较频繁的功能 4.项目优先级比较高,比较核心的功能


    强调一点:手动测试和自动化测试对于项目来说同等重要,不存在自动化测试人员高级于手动测试人员。如果说一定要说哪个最重要的话,只能是看项目的不同阶段,在项目前中期的时候的时候,手动测试占据了核心地位,在后期的时候,自动化的全面覆盖保证了回归测试的有效进行。


    总结:关于敏捷开发和敏捷测试的一点心得:敏捷现在已经被推向了一个高潮,何为敏捷?太多人有不同的见解,说到最后与敏捷最分不开的一词就应该是“实践”,敏捷是实践出来的,不是效仿出来的,现在太多的公司和团队在盲目的追求敏捷,拿scrum来说,有多少公司在做的只是scrum最最表象的一些东西,安排站会,制定sprint,总结会等等,但是这些真的给你的团队带来了改善了吗?想必答案只有他们自己清楚。我心中的敏捷:敏捷---敏-结,敏就是敏捷,简单的说就是要一个高效率,结:是指项目团队的协作和内部团结,这一点非常重要。看那些成功实施敏捷的团队和诸多的最佳实践团队他们都是团结一心的,整个项目团队都有一个共同的目标和追求,而不是每天项目经理在驱使着大家在前进,每个人都积极上进学习,遇到不懂的问题去总结、去学习,去突破,再去分享,而不是说,“这个问题太难了,这个技术太难了,这个。。。我可做不了”,如果每个成员都采用这种排斥的心里,那么这个团队就永远都敏捷不起来,还有就是在需要协作的时候,两个项目组不要互相“踢皮球”,而是要勇于承担责任,最普遍的现象就是项目出现了问题,然后大家在会上开始掐架。这时候有人会问,自己出来担责任不是傻吗?其实不然,一个明智的老板当然看的懂到底是谁的责任,是否真正的需要人来承担责任。如果这都做不到,证明这个老板也就。。。再谈实践,笔者看来,很难有一个很细致的又可以公用的敏捷方法,即使现在最流行的scrum,也是一个非常抽象的概念,所以才有诸多屡实施又不见成效的团队,最好的推进敏捷的方法就是实践,只有实践才能发现问题,才能解决问题,最好找到一个适合自己的敏捷方法。

    展开全文
  • 通俗地讲,在敏捷开发过程中进行的测试就叫敏捷测试。  它是一套测试解决方案、一组实践或者由一定顺序的测试活动构成的特定的测试流程。是为了顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。 ...

     敏捷测试并不是一种新的测试类型,也不是一个新的测试阶段,更不是一种全新的测试方法论。通俗地讲,在敏捷开发过程中进行的测试就叫敏捷测试。

      它是一套测试解决方案、一组实践或者由一定顺序的测试活动构成的特定的测试流程。是为了顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。

      Wikipedia是这样描述敏捷测试的:敏捷测试是遵守敏捷开发原则之下的软件测试实践,需要跨功能敏捷团队全员参与,并且由测试人员贡献其专业特长,以保证持续、快速地业务价值交付。

      敏捷测试与传统测试的区别

      敏捷测试与传统测试的区别,并不是敏捷测试测得更快,也不是用的时间更少,更不是将测试的范围缩小,或者将质量降低来减少测试任务,而是在计划、阶段划分、文档、记录、沟通等方面的侧重不同。

      1、传统测试强调测试的计划性,认为没有良好的测试计划和不按计划执行,测试就难以控制和管理。而敏捷测试更强调测试的速度和适应性,侧重计划的不断调整以适应需求的变化。

      2、传统测试更具有阶段性,从需求评审、设计评审、单元测试到集成测试、系统测试等,从测试计划、测试设计再到测试执行、测试报告等,但敏捷测试更强调持续测试、持续的质量反馈,模糊了阶段性,而且介入更早。

      3、传统测试强调任何发现的缺陷要记录下来,以便进行缺陷根本原因分析,达到缺陷预防的目的,并强调缺陷跟踪和处理的流程,区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作,强调团队的责任,不太关注对缺陷的记录与跟踪。

      4、传统测试更关注bug,围绕bug开展一系列的活动,如bug跟踪、度量、分析、报告、质量检查等,而敏捷测试更关注产品本身,关注可以交付的客户价值。在快速交付的敏捷开发模式下,bug修复的成本很低。

      5、传统测试鼓励自动化测试,但自动化测试的成功与否对测试没有致命的影响。但敏捷测试的基础就是自动化测试,敏捷测试需要有良好的自动化测试手段支撑的快速测试。

      6、传统测试更强调测试的独立性,将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试中,测试人员需要参与全部开发活动,需要参与整个项目组的所有会议,能够发挥更大的作用。

      敏捷测试中的关键过程

      在一个sprint中,测试人员的工作内容主要分为五个部分:user story分析、测试用例设计开发、测试执行和分析、测试持续集成、回归测试。这五个部分的工作均要持续到sprint结束,只是启动时刻有早有晚,具体如下图所示

      user story分析工作:敏捷测试是不断确认客户的需求得以圆满实现,因此对用户需求的分析、理解需要一直持续下去,发现有偏差及时纠正,及时设置合理的验收点、测试项。

      Testcase Develop工作:设计测试用例,完成测试代码的开发、测试数据的准备,并及时与开发人员沟通软件接口,确保测试代码能够成功驱动业务代码。

      Testing & Analysing工作:执行测试,统计测试覆盖率,分析测试结果,若发现bug,及时沟通,并协助定位bug。

      Continuous Integration工作:将测试代码进行集成,以保证当前功能若被后续集成代码污染是能够及时得到报警,不断地完善软件产品的功能基线。

      RegressionTesting工作:在完成全部user story后,对所有代码进行完整的回归测试,对所有bug修复情况进行确认。

      敏捷测试对测试人员的要求

      优秀的敏捷开发过程越来越重视测试人员,测试人员在其中所起到的作用越来越大,相应的对测试人员的要求就越来越高。一个合格的敏捷测试角色,应当具备以下素质:

      1、良好的沟通能力

      测试人员全程参与所有开发活动,需要与产品、开发、项目经理设置用户进行频繁的沟通,必须具备良好的沟通能力。

      2、换位思考能力

      一方面需要站在产品、用户的角度,考虑产品的功能、性能、易用性等,一方面需要站在开发的角度,思考软件技术方案的可行性,实现的难度、合理性、可测性等,充分考虑到各种情况。

      3、掌握多种的测试手段

      面对不断变化的需求,足够的测试手段储备,是从容应对变化的本钱。

      4、一定的开发技能

      在敏捷开发团队成长到一定程度后,测试与开发角色的界限会变得模糊。在初始阶段,测试人员也应当具备完成单元测试代码编写的能力。

      5、拥抱变化

      “唯一不变的就是变化”,所以,需求的变动是必然的,每次的需求的调整都是将产品开发推向更正确的方向。在接受变化的同时,测试人员应该积极的反馈可能的设计缺陷和错误。

      自动化测试与手工测试

      轻量级增量开发、快速迭代的特点,使得测试人员需要重点关注两个方面的软件质量,一是新功能的需求符合性,二是原有功能的稳定性、可靠性。通常,对新功能进行灵活性高的手工测试,而对原有功能进行自动化回归测试是目前看来最合理的一种手工测试与自动化测试的分工。

      敏捷功能测试= 新特性的手工测试(针对user story验证) + 原有功能的自动化测试(回归测试)。

      总结

      测试人员是敏捷团队非常重要的一环,测试人员的成长对敏捷团队非常重要。从传统测试工作转入敏捷测试工作必然会遇到很多不适,但是只要坚持对敏捷的学习和各种新工具的开发使用,一切都能够适应下来。

      谁都知道,变化,才是永远不变的,敏捷则是我们应对变化的武器。

    展开全文
  • 敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。而敏捷开发离不开迭代,迭代就是我们所说的一个子项目或者一个版本,通常一个迭代是3周左右,每3周进行一次...

    什么是敏捷开发?

    目前互联网行业已占领软件行业的半壁江山,越来越多的企业开始实施敏捷研发。那么什么是敏捷开发呢?

    简而言之,敏捷开发就是一种以人为核心,迭代循序渐进的开发方式。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。而敏捷开发离不开迭代,迭代就是我们所说的一个子项目或者一个版本,通常一个迭代是3周左右,每3周进行一次上线包括需求开发、测试和上线。

    5cf4e06761d7593437.png

    图中就是一个完整的迭代过程中项目经理、PO、研发和测试整个Scrum team的工作流程。首先是PO组织相关Scrum人员进行迭代需求评审,然后是Scrum团队中的研发人员进行研发的过程,这个过程一般持续2周左右;在研发的过程中测试需要完成这个迭代的用例编写;然后是研发人员转测,测试人员执行用例,这个时间大概一周左右,测试人员完成测试工作,PO验证完成这个迭代进行上线。在规划的所有迭代完成之后,会产出一个最终的产品软件,这个时候交付客户,进行线上验证和后期推广等操作。

    在敏捷开发中测试如何工作?

    在互联网企业中,每个测试都要求独当一面。一个人常常负责一个单独的模块或多个模块。互联网发展快的特性使得企业为了快速响应需求,上线要求周期短而且发布频繁。互联网易变的特性使得惬意需求变更成为老生常谈。

    此外,负责的模块会经常变化,负责的需求人员、研发人员及测试人员也会变化,最终导致我们制定或参与的测试计划也会经常变化。在互联网这个大环境下,我们更需要自我管理,自我计划的能力。

    这时候,需要执行测试计划,需要通过计划去管理变化,将风险降至最低,以致于可以将风险扼杀在摇篮中。

    从下面这张图中我们可以看到敏捷开发的核心是拥抱变化和递增变化。

    5cf4e064a2aee93700.png

    在敏捷开发中,测试的工作是贯穿始终的,在需求阶段测试已经介入工作进行需求的合理性验证。在完成需求评审之后,测试需要根据需求规格说明书和原型完成测试计划,然后采用合理的测试策略进行测试用例设计。在开发人员进行研发的过程中,相关测试人员同步进行需求的用例编写,这个过程也是不断了解需求,完善需求的过程。

    一般经过两周左右的开发,在第二周周四左右,测试会提供这个迭代的测试用例给开发人员,研发人员需要根据测试用例的优先级和重要性,将需求中已经实现的功能进行自测,不断完善代码,自测通过之后,将于周五进行转测申请提交,至此这个迭代的工作重心将从研发人员转职测试人员,变为测试为主。

    这个时候测试人员会根据测试计划和项目约定的要求,采用2+2+1的模式执行测试用例。

    这里的2+2+1模式是对于上线迭代的此需求,需要测试进行3轮测试任务。

    第一轮:完成此迭代涉及到的所有需求的测试用例的执行(根据不同项目情况,需要执行的测试分为接口测试、功能测试、性能测试、兼容性测试等)。

    第二轮:完成该迭代的bugs的回归操作,并且保证所有上线功能的bug中等级别以上bug全部修复,bug等级低或者其他UI、易用性问题可以根据项目时间安排尽量在本迭代内完成修复。

    第三轮:第二轮bugs回归完成之后,进行的第三轮则主要是产品和UI验收阶段。

    PO和UI验收完成之后则进行上线发布阶段。这个时候需要邮件通知相关项目干系人进行线上部署、发布以及验证和后期推广等操作。

    一般在项目结束之后,需要项目管理者和PO以及Scrum team人员总结此次迭代中的经验和教训,不断完善、提高整个团队的合作能力。

    至此,在敏捷开发中,一个完整的迭代就这样结束了。这里举例的模式是2+2+1,不同的项目不同的迭代功能需要根据项目实际情况进行合理安排测试的时间,具体问题具体对待。如果说整个迭代的功能需求多,那可能采取的是3+2+1,或者其他更好的方法。

    上面说明的敏捷开发中整个迭代是3周,最后一周需要测试、研发修复bugs和验证验收之后进行上线发布、验证;但是有些情况下,可能整个项目划分了N个迭代,而每个迭代的时间紧,任务重;这个时候可能就没有一个完整的一周时间留给测试和研发人员进行bugs的修复工作,这个时候在第三周开发进行第二个迭代的研发功能,测试执行第一个迭代的用例,需要研发人员合理安排时间进行bugs修复和第二迭代的研发。整个项目计划中必须留出足够的时间给测试人员完成用例的执行,不能压缩测试人员的工作时间;所以这个时候就是考验项目管理者和PO的时候,需要合理安排计划。

    敏捷开发中遇到的问题?

    对于敏捷开发而言,需求的变化、人员的变化会导致出现各种问题。

    迭代需求变更不同步

    前面说了,敏捷的核心原则就是变化,所以敏捷开发中需求变更会很频繁。经常是研发过程中发现某一需求实现和之前的功能冲突,这个时候研发和PO经过协商会更改部分需求,但是变更的需求没有及时同步至测试相关人员,直至测试时才发现这个需求已经变更。

    出现这个问题原因有:整个项目开发团队人员比较分散,如果需求变更比较多,导致遗漏部分变更的需求;这个时候就需要产品和项目经理以及研发和测试人员及时同步需求变更问题。需求变更的源头是产品经理而最终测试必须通知测试人员。所以需要相关负责人建立一套完整的需求变更反馈机制,不能遗漏任何一个环节。

    延迟提测时间

    研发提测时间的推迟,最直接的结果是如果无法延期上线时间,导致测试时间不充分,则软件的质量可能会出现一些无法预测的问题。这里延迟转测可能有以下原因:

    1. 研发过程发现需求缺陷,增加需求或变更需求比较大
    2. 测试用例编写过程发现需求缺陷,增加需求或变更需求比较大
    3. 产品中间插入紧急用户新需求,影响了整个迭代的开发进度
    4. 线上版本出现bug,紧急修复

    针对问题1和2,则需要PO在定义需求时,更加严谨,而且研发人员在制定计划时,要仔细拆分各个功能点,每个功能点的实现方式做到胸有成竹。

    这样即使再次出现问题1和2,也不会是大的需求变更,相对增加的工作量都在可控范围内。

    针对问题3,我们需要建立一套适合的用户反馈需求的机制。项目经理和PO需要根据当前迭代的任务量适当处理用户的紧急需求。

    针对问题4,对于线上版本的bug修复,需要根据bug的严重和影响程度以及修复成本,确认是否修复。对于影响和严重级别比较高的bug,则必须马上修复。所以如果出现此类程度的bug则需要测试人员自查,确认bug产生的原因是漏测还是环境配置造成的问题,需要测试人员在以后的测试中关注此类问题,避免再次出现此类bug。

    需求理解不同导致上线延迟

    产品提出的需求可能描述不清晰,导致研发和测试执行过程中没有发现此类需求功能缺陷,直到产品验收时才发现此需求实现有问题,没有达到产品的预期,这个时候的修复成本就比较高。

    这里就需要产品在评审时明确需求说明书和原型中的每一个功能点,而研发和测试在评审和研发以及测试执行过程中有任何疑问都要及时提出来,不能想当然。

    管理工具使用不同步造成时间成本增加

    目前使用的项目管理工具是JIRA和confluence,通常产品的需求在confluence上会有一份功能点说明和原型图链接地址,而在JIRA上是各个功能任务详细说明和开发分配拆分的子任务。而变更需求只会在JIRA中标记,confluence中又不会出现变更的需求功能点。而测试和开发人员又是以confluence为主,JIRA对于开发人员而言就是拆分子任务和关闭分配的任务的工具,对于测试人员而言,在提交bug时会使用JIRA。

    实际上这也是导致需求变更不同步和延期的一个原因,增加了产品、开发和测试的沟通成本,所以在项目开始时需要根据情况确定项目的使用工具,以免出现此类问题。

    沟通问题

    在敏捷开发中,项目经理、PO等Scrum team需要明确自己的工作职责,项目经理和PO要做好各方面的沟通协调工作,使得测试更集中精力执行测试工作,而开发则专注于研发工作,提高工作效率,降低无效沟通。

    以上就是整个敏捷开发团队中所遇到的问题,对于项目管理、PO整个Scrum team团队而言,需要不同维度协调提高团队协作能力。敏捷开发团队每个人都要有主动沟通和协作的意识,测试要树立正确的敏捷测试观念,整个团队要以积极的心态拥抱变化。

    部分内容摘自慕课网

    转载于:https://www.cnblogs.com/LOVEYU/p/10969498.html

    展开全文
  • 参考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 ...
  • 敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。因此测试变成了整个软件开发过程中非常重要的环节。敏捷测试包含了具备专业技能测试人员在内的跨职能团队,这使得这种组合式的团队能更好的...
  • 提起敏捷软件测试必须要提及到敏捷软件开发,敏捷软件...为了适应敏捷开发的特点,敏捷测试应运而生。 作为一个传统的互联网公司,我们接触敏捷这个概念还是相对较晚的。但是通过对敏捷概念和敏捷宣言的理解,发
  • 敏捷测试-测试流程调整

    千次阅读 2018-10-31 17:45:21
    前段时间接手一个使用敏捷开发的项目,从产品设计到第一版上线的时间只有2个月的时间。这让原有的测试流程饱受打击。如何快速的面对敏捷制定符合自己的测试流程,更好的服务于项目成为团队的首要任务。  通过思考...
  • 于是敏捷开发,敏捷测试的概念流行开来。所谓敏捷,说白了就是没时间。在敏捷模式下,团队几乎没有时间写文档。在不断强调质量之后,研发团队又被要求一快再快。那么作为测试人员,如何“敏捷”的完成自己的工作呢?...
  • 通俗地讲,在敏捷开发过程中进行的测试就叫敏捷测试。 它是一套测试解决方案、一组实践或者由一定顺序的测试活动构成的特定的测试流程。是为了顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。 敏捷...
  • 本文综述了嵌入式系统敏捷开发(Agile Development),敏捷宣言,敏捷的原则,很多的敏捷开发的实践习惯,敏捷开发与瀑布开发流程的区别,敏捷的任务stories划分,并行开发、敏捷的时间安排,敏捷的通信交流方式等等。...
  • 敏捷开发团队管理系列之二:程序与测试团队I

    万次阅读 多人点赞 2011-12-29 23:16:45
    这是敏捷开发团队管理系列的第二篇。(之一,之二,之三,之四)几个真实案例这几个团队都是我自己亲身经历的团队,从质量的角度来分析敏捷团队的工作方式。第一个是一个较为大型的团队,约有25~30人,研发一个单一...
  • 敏捷模型是在互联网的快节奏下应运而生的,也是当前最为主流的开发测试模型。 在V模型中,描述了基本的开发过程和测试行为,它的优点在于,非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了测试各阶段...
  • 敏捷开发知识体系笔记

    万次阅读 2015-11-06 10:08:55
    敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 通俗地讲,在敏捷开发过程中进行的测试就叫敏捷测试。它是一套测试解决方案、一组实践或者由一定顺序的测试活动构成的特定的测试流程。是为了顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。敏捷测试...
  • 敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此...
  • 敏捷测试过程中的自动化目前在国内来看基本上还只是停留在概念阶段,据我所知,目前不少公司也都在尝试过程中,而实际的实践中能取得比较理想成果的,极为有限。而国外不少同仁也都对此持观望甚至抵触的态度。比如...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 在现在互联网发展浪潮中,敏捷被应用于越来越多项目中,随之而来的“敏捷测试”与“自动化测试”也成为一个大家经常探讨的话题,那么在敏捷测试中,如何应用自动化测试?又如何去推行最有效的自动化测试呢?本文在此...
1 2 3 4 5 ... 20
收藏数 2,692
精华内容 1,076
关键字:

敏捷开发 测试介入