精华内容
下载资源
问答
  • 敏捷开发测试角色的窘境

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


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


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

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

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

    最近自己团队也在做这方面的探索,希望能设计出一个适合程序员自测的专业测试工具与方案。 
    好了,写了这么多点,可能我孤陋寡闻,也不知道是否已经有这样专业的产品,谢谢推荐。
    展开全文
  • 敏捷开发角色和职责阐述

    千次阅读 2019-05-18 18:58:21
    敏捷开发中的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这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    展开全文
  • 敏捷开发模式下测试策略综述 2 过程管理角色 2 测试开发角色 2 持续交付 3 持续交付,是在产品开发过程……能够以较短地周期完成需求的小粒度频繁交付;频繁的交付周期【2~5周】带来了更迅速的对产品的反馈和改善...
  • 一、迭代角色 1、Scrum Master 1.1 促进团队提高创造力,并努力提高开发团队的效率 1.2 负责消除团队的风险以及困难 1.3 识别 Sprint 中的风险并提供解决措施 1.5 负责召开复盘会议。 组织 Sprint 计划...

    目前敏捷开发、敏捷测试几乎已成为各个公司的通识,但每个公司的方法和流程都有所不同,以下就分享一下我所学习到的内容

     

    一、迭代角色

    1、Scrum Master

    1.1 促进团队提高创造力,并努力提高开发团队的效率

    1.2 负责消除团队的风险以及困难

    1.3 识别 Sprint 中的风险并提供解决措施

    1.5 负责召开复盘会议。 组织 Sprint 计划会议

    1.6 负责跟进迭代进度

    1.7 组织 Scrum 晨会

    2、产品

    2.1  负责迭代需求计划

    2.2 负责编写需求产品设计文档

    2.3 白皮书、操作手册、介绍资料

    2.4 了解市场最新政策、动向、竞品分析

    2.5 公司内部产品培训

    2.6 不定期去客户现场沟通,调研新需求

    2.7 负责管理好 Jira Sprint

    2.8 迭代温馨提示、产品验收

    2.9 积极参与测试用例评审并有效反馈

    3、研发

    3.1 认真评估产品需求,协助产品经理丰富其产品设计

    3.2 根据产品需求文档,对需求任务做合理的拆分并评估其工作量

    3.3 编写有效的研发设计文档并组织评审

    3.4 积极参与测试用例评审并有效反馈

    3.5 积极参与代码评审并有效反馈

    3.6 需求负责人需要积极协调所有参与研发人员一起保证需求目标达成

    3.7 需求有延期风险需要及时反馈给 Scrum Master

    3.8 积极反馈迭代流程问题

    4、测试

    4.1 设计测试用例并执行测试    后期问题跟踪

    4.2 为软件提供产品质量快速反馈

    4.3 负责发布预演

    4.4 识别需求,研发,测试,上线各阶段中可能存在的风险,并且快速反馈

    4.5 发现敏捷过程中流程问题并提出改进意见

    4.6 编写自动化测试用例与脚本

    4.7 测试直接对接生产bug

    4.8 关注系统级别的问题:比如性能、高可用性、安全等

    4.9 鼓励提Bug时,提供更多有价值的信息

    5、Devops

    5.1 负责 CI/CD 

    5.2 负责迭代发布

     

     

     

    二、文档模板

    1、需求文档模板

    包含信息:需求名称、计划上线时间、需求目标、背景和策略适合、设想、需求、用户交互设计、问题、没有做。

    参考示例:

    模板下载:无

    2、测试用例模板

    包含信息:

    参考示例:

    模板下载

    3、研发设计模板

    包含信息:

    参考示例:

    模板下载

    4、发布升级邮件模板

    包含信息:升级开始时间、升级结束时间、升级影响的系统范围、升级可能会给客户带来的影响、客户需要注意的事项、升级期间的客户支持和沟通机制、应急方案和措施、升级原因

    参考示例:

    5、发布看板模板

    包含信息:Zoom 会议室地址、发布站点、数据库变更、ES脚本变更、资源码变更、SQS 变更、apollo 配置变更、上线清单、点检发布时间、点检验证时间、点检测试用例验证、生产发布时间、生产验证时间、生产测试用例验证、回滚方案、保驾安排、发布过程记录等

    参考示例:

    模板下载:无

    6、产品发布说明文档

    包含信息:

    参考示例:

    模板下载

    三、迭代流程

    1、需求

    1.1 迭代需求吹风会(会议)

    1)会议目标:

    • Scrum Master 规划评估整体工作量,提前了解下个迭代的任务
    • Scrum Master 对于下个迭代的任务安排提前进行规划安排
    • 所有成员了解需求
    • 所有成员需求可行性分析
    • 所有成员系统影响分析
    • 明确下迭代目标
    • 明确US是否需要再切分

    2)会议开始时间:上个迭代发布日的前一周。比如:上个迭代的发布日是: 5.20号(礼拜三),则建议会议时间是:5.13号。

    3)会议主持人:Scrum Master

    4)会议参与人:产品经理、研发、测试

    5)会议建议时长:不超过1.5个小时

    6)会议开展方式:

      • 产品经理根据需求和bug优先级安排下个代计划完成需求
      • 研发安排下个迭代技术需求
      • 研发和QA分析判断需求是否合理以及是否能技术实现
      • Scrum Master 控制会议时长,控制问题讨论不要无限扩展,高效达成会议目标

    1.2 产品需求详细设计文档编写

    1)负责人:产品经理

    2)文档编写格式:参考 《二.1需求文档模板》

    3)文档地址:

    4)完成时间:在迭代 sprint planning 会议之前

    5)需求涉及到集成联调的,需提前和干系人(平台集成、属地集成、项目经理等)约定联调时间

    6)需求涉及到跨部门(比如税件)的,需要提前和协作方沟通排期以及联调时间

    7)PRD 在 sprint planning

    1.3 迭代启动会(会议)

    1)会议目标:

    • 定本迭代的主要目标

    • 确定本迭代需要完成的具体需求(包含产品需求和技术需求)

    • 确定迭代投入资源(包含人员和其他资源)

    • 深入需求了解,为研发设计,测试设计提供参考准则

    • 评审每个产品需求、技术需求的合理性并安排研发、测试人员

    • 评估每个需求的 story point 

    2)会议开始时间:迭代开始的第1天

    3)会议主持人:Scrum Master

    4)会议参与人:产品经理、研发、测试

    5)会议建议时长:不超过3个小时

    6)会议开展方式:

    • 产品经理至少要提前2天在会议前提供完整的 PRD 文档,并抄送给全部团队人员
    • 优先评审产品需求、技术需求,bug 直接委派研发或者测试人员,不进行具体的讲解
    • 产品对照需求说明文档讲解,研发、测试提出问题,如果没有问题或者问题能够解释清楚,则该需求评审通过,建议优先由熟悉此块功能的人认领,然后是其他人主动认领
    • 如果需求描述不清且产品经理在会议上也无法描述清楚,则在会议上跳过该需求,由产品经理在当天或者第2天重新组织小范围会议讨论,参会人员包含Scrum Master、研发、测试。如果第2次还是没达成一致,则不列入本迭代任务,将backlog里的任务置换一个到本迭代中
    • Scrum Master 控制会议时长,控制每个需求评审无限扩展,高效达成会议目标
    • 对每个需求进行 story point 估算。基于 Jira poker 投票方式,大家一起估算。story point 估算方式可参考《Story Point 估算方法》

    2、研发

    2.1 迭代需求拆分及估算

    1)需求拆分规则:每个需求拆分包含有 代码评审、测试用例评审、功能测试 3个子任务,有集成联调或者跨部门联调,同时创建一个 集成联调 子任务

    2)需求按照产品视角进行细分,每个细分功能如果前后端都涉及到,则创建2个细分子任务

    3)每个子任务估算“预计评估时间”,“预计剩余时间”

    4)需求的 owner 是整个需求的负责人,负责需求整体的进度、联调工作

    5)在迭代启动会当天要完成绝大部分需求拆分及估算,并在第2天晨会进行确认。剩余需求拆分和估算在第2天完成

    2.2 研发需求设计文档编写

    1)负责人:研发

    2)文档编写格式:参考 《二.3 研发设计文档模板》

    3)文档地址:

    4)需求涉及到集成联调的,需提前和干系人(平台集成、属地集成、项目经理等)约定联调时间并记录在 Jira 中

    5)需求涉及到跨部门(比如税件)的,需要提前和协作方沟通联调时间并记录在 Jira 中

    2.3 研发需求设计文档评审

    1)负责人:研发

    2)参与人:研发、测试、软件构架师(可选,大的需求、架构调整时需要参与)

    3)评审方式:线下自行组织

    4)评审时间:// TODO 

    2.4 测试用例编写

    1)负责人:测试

    2)文档编写格式:参考《测试用例文档模板》

    3)文档地址:

    4)测试用例编写技巧:

    • 等价类划分方法
    • 边界值分析方法:等价类划分的补充,对边界值进行重点测试,通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据
    • 错误推测方法:基于对被测试软件系统设计的理解、过往经验以及个人直觉,推测出软件可能存在的缺陷,从而有针对性地设计测试用例的方法

    2.5 测试用例评审

    1)负责人:测试

    2)参与人:产品经理、研发、Scrum Master(可选)

    3)评审方式:线下自行组织

    4)评审原则:

    • 评审前,优先先进行同行评审
    • 先讲解本次评审用例的需求点
    • 根据需求点对用例进行场景讲解,设计思路,以及业务覆盖
    • 参与人员积极补充场景
    • 用例场景遗漏太多,可以评审不通过,补充后,第二天测试再主动发起评审

    2.6 需求提测

    1)负责人:需求负责人

    2)参与人:测试

    3)提测说明:按照提测规范进行提测,参考《团队最佳实践》中研发提测需求

    2.7 代码评审

    1)负责人:研发

    2)评审时间:每次代码 merge 的时候

    3)参与人:其他研发干系人

    4)组织方式:自由方式

    2.8 下个迭代需求吹风会

    1)参考 三.1.1.1 迭代需求吹风会

    2)执行时间:迭代发布日的前一周

    3、测试

    3.1 FAT 测试

    1)负责人:测试

    2)测试时间:需求负责人联调自测结束

    3)测试开展方式:

    • 按测试用例执行
    • 并标记执行状态
    • 每天汇报测试进度
    • 更新jira任务剩余时间

    4)Bug 反馈:记录到 Jira 需求的子任务下,并标记为 内部Bug

    5)Bug 修复方式:基于 feature 分支修改,然后自己验证通过后,merge 到 develop 分支,发布 FAT 环境

    3.2 代码封板

    1)负责人:后端负责人、前端负责人

    2)封板时间:FAT 测试通过。一般是迭代发布周的上周五下班前。比如 5.20(礼拜三)是迭代发布日,则封板时间建议为:5.15号(上周五)

    3)封板动作:

    • 务必要确保迭代每个需求代码都合并到 release 分支,找每个需求负责人确认代码提交记录
    • 封板直接采用从 develop merge release 方式

    3.3 SIT测试

    1)负责人:测试

    2)测试时间:迭代发布日前3天。比如 5.20(礼拜三)是迭代发布日,则SIT提测时间为 5.18 号

    3)测试开展方式:

    • 发SIT后进行冒烟测试,当天冒烟三次机会,冒烟不过,未达到封板条件。----当天复盘–评估发布风险,是否需要延期
    • 按测试用例执行,并标记执行状态
    • 每天汇报测试进度
    • 更新jira任务剩余时间
    • SIT环境US测试通过,对应的QA人员给产品创建验收task,等待产品验收
    • 最晚迭代发布当天17点前必须通过 SIT 测试,不通过则延期(紧急发布、特殊发布不在这个要求之内)

    4)Bug 反馈:记录到 Jira 需求的子任务下,并标记为 内部Bug

    5)Bug 修复方式:基于 release 分支修改,测试验证通过后,merge 回 develop 分支

    3.4 产品功能验证

    负责人:产品经理

    验证时间:至少提前迭代发布1天进行验收

    验证结果:产品验证有问题,先找测试确认。 如果有问题,测试提 Bug

    3.5 Demo 

    1)无

    3.5 产品发送关怀邮件

    1)负责人:产品经理

    2)邮件内容:参考《发布升级邮件模板》

    3)发送时间:迭代发布当天

    4)发送对象: PSCC  PMO,抄送给团队成员、研发中心负责人

    3.6 迭代看板预演

    1)发起人:迭代测试负责人

    2)参与人员:Scrum Master、产品经理、研发、测试、运维

    3)看板内容:参考《发布看板模板》

    4)预演时间:迭代发布当天下午14:00 ~ 20:00 之间

    4、发布

    4.1 生产环境发布

    1)负责人:运维

    2)参与人:Scrum Master、产品经理、研发、测试

    3)发布流程:按照事先建好的《迭代发布看板预演》流程进行发布

    4)协作方式:钉钉会议

    4.2 生产环境功能验证

    1)负责人:迭代测试负责人

    2)参与人:测试、产品经理

    3)验证结果:

    • 验证过程中发现3级及以下 Bug,不用处理,继续发布,同时将 Bug 记录到 Jira 里面,计划在后面的迭代中修复
    • 验证过程发现2级及以上 Bug,给予1次修复机会
    • 修复完成后还出现问题,取消当晚发布,发起日期第2天在定
    • 原则上发布时间不超过凌晨2点,超过2点,还没有结束,视情况延期

    4.3 生产环境冒烟

    1)负责人:迭代测试负责人

    2)参与人:测试

    4.4 生产发布过程记录

    4.5 紧急发布

    1)SIT 最晚21点前结束

    2)如果21点前没有结束,则

    • 延期 (绝大部分场景)
    • 必须发布:1)找简单可行的替代方案  2)继续当天的发布流程,直至成功

    4.6 发布延期

    1)项目发布延期后,产品经理当晚或者第二天早上发送告之邮件,抄送给:PMO、项目经理等。

    五、复盘

    1 复盘会议(会议)

    1)会议目标:回顾本迭代过程中做的好的和做的不够好的地方。做的好的地方继续保持,形成持续优势。做的不好的地方,提出改进措施,在后续迭代中完善,总体目标是持续不断的提升迭代流程质量和效率
    2)会议负责人:Scrum Master
    3)会议参与人:产品经理、研发、测试
    4)会议举行时间:迭代结束第1天
    5)会议时长:不超过3个小时
    6)会议开展方式:

      • 在 WIKI 上创建迭代复盘页面,每个人提前在该页面编辑本迭代做的好的地方和做的不好的地方,并署名
      • 先分析好的地方,给团队成员打气鼓励
      • 在分析做的不够好的地方,逐条分析,并提出改进措施
      • 对最终形成的改进措施提出 owner,并制定日期
      • 下个迭代复盘时,在来 review 上个迭代改进措施落地情况
    展开全文
  • 简述敏捷开发中的测试流程

    千次阅读 2018-08-14 15:57:51
    需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案; 确认验收标准:为了避免sprint进行中产生的扯皮推诿,应当在需求讨论会上就确定验收标准。 形成...

    对敏捷sprint进程中测试任务的简要描述:

     

    需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案;

    确认验收标准:为了避免sprint进行中产生的扯皮推诿,应当在需求讨论会上就确定验收标准。

    形成开发任务tag:形成测试tag,估算测试时间,形成概要测试计划。

    开发过程中:1.针对开发任务顺序,提前预备环境,数据等。这个过程往往在需求讨论时就已经开展。

    2.验收测试,反馈修改。这一阶段的重点词是“反馈”和 “现场验证”。及时而准确的反馈,是敏捷的灵魂,是开发和测试工作告诉运转的保证;“现场验证”是交付的终点,如果不做现场验证,即使在测试环境中通过也不能算作交付完成。

    3.站立会议。传达测试任务进度,了解开发进度,以便预先配置环境;针对测试任务提出问题/给出建议/寻求帮助;预估风险

    demo前一天:

    不再接受测试任务提交;

    对已通过功能现场回归测试一遍;

    完成次日测试环境数据的准备;

    总结会:

    针对上一个sprint不足,改进测试方法流程;

    发现团队不足,增强协作力。

     

    展开全文
  • 我和敏捷开发的故事--敏捷角色-TEAM

    千次阅读 2015-09-29 23:23:16
    敏捷开发中除了PO跟SM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.     因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个...
  • 敏捷开发

    2020-10-09 11:28:20
    2. 敏捷开发流程中的三大角色: a. 产品经理:和客户沟通,编写产品需求文档,验收开发完成的产品。 b. 技术负责人(leader):技术上负责整个项目的开发流程,管理开发团队,分配开发任务,验收开发完成的产品。 ...
  • 最近CTO组建了一个敏捷开发团队,团队人员包括 PM、设计、开发、测试角色,主要由PM来主导团队走向,因为以前并没有参加过敏捷开发的经验,对敏捷开发做了简单理解后,参考了前人的一些意见,总结出在 敏捷开发模式...
  • 但发现其并没有紧扣敏捷开发测试的特点,这五个约定在传统开发中已经早有实践,也有相关论述。哪么在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践?  从敏捷团队的组建上来说,敏捷团队并没有...
  • 敏捷开发vs 传统开发

    2020-04-20 14:49:17
    今天看到一篇讲敏捷开发挺到位,你确定懂什么是敏捷测试? 摘自里面几点,介绍敏捷开发与传统开发对区别? 1)传统测试更强调测试的独立性,将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的...
  • 敏捷开发个人目录

    2019-08-07 20:59:52
    1. 敏捷开发角色 2. 敏捷开发 — 道具(story/defect/task...) 3. 敏捷开发 — 游戏(自己做一个?或找些玩法过来?) 4. 敏捷开发 — 需求 5. 敏捷开发 — 开发 6. 敏捷开发测试 7. 敏捷开发 — ...
  • 01.精益——敏捷软件开发中质量保证(Quality Assurance,QA)的角色展开,涵盖了许多关键问题  *测试人员的作用是防止缺陷,而不是发现缺陷  *开始做开发周期计划时如何发挥验收测试的作用,以做到在最大限度上...
  • 在国内,2012年到2015年敏捷开发可谓热火朝天。即使是现在,很多软件公司的培训主题也仍然少不了它。即便如此,调查结果却显示超过一半的人并不记得敏捷宣言。如果正在或将要做敏捷项目,建议先了解下敏捷宣言,有助...
  • 读者将从该书中收获测试人员如何参与敏捷开发测试人员和QA经理如何适应敏捷团队敏捷测试人员的招聘要求是什么如何从传统模式迁移到敏捷模式如何在短期迭代中完成测试任务如何利用测试指导开发如何克服困难实现测试...
  • 对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?...
  • 敏捷开发中,我最推荐的工具是 禅道; 敏捷开中主要角色如下,技术管理这块 有些公司叫 项目管理,有些叫研发经理,有些叫技术经理; ok 不管叫什么,他的职能是协调管理,懂技术;我们推荐这个 技术经理 角色...
  • 测试遵循敏捷宣言进行,把开发作为顾客看待。项目的测试采用敏捷方法论。 敏捷测试的原则与上下文驱动测试的原则有交集,例如,上下文驱动测试的七大原则中的第三条:工作在一起的项目组成员是项目的上下文的最重要...
  • 敏捷开发团队中PO和SM角色介绍

    万次阅读 2014-03-28 15:33:48
    敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的...
  • 开发团队协作 敏捷开发 在致力于敏捷和发展实践时,IT团队需要做很多工作。 敏捷团队可能会通过定义Scrum管理员角色 , 添加估算实践并成熟使用敏捷管理工具的方式来成熟和扩展其实践。 Devops团队可能首先实现CI / ...
  • 角色敏捷开发中的,主要涉及到以下几个角色:产品负责人(Product Owner,PO)、敏捷专家(Scrum Master,SM)、Team Leader、开发人员(DEV)、测试人员(SIT);开发人员和测试人员组成了一个相对固定的开发团队...
  • 敏捷开发规范

    2018-09-21 16:49:00
    1 概述 1.1 编写目的 该文档的主要目的是为了在团队中实施敏捷开发,加速产品交付周期,为敏捷开发提供相应的...2 敏捷开发团队中的角色及名词解释 2.1 product owner product owner也叫产品经理,负责整理u...
  • 软件测试思想者 - 敏捷开发中的Scrum术语 Scrum是一种项目管理方式。在Scrum团队中,有3种定义好的角色: 【PO - Product Owner/产品负责人】  在整个敏捷Scrum开发的过程中,Product Owner起着至关重要的...
  • 敏捷测试的特点

    2020-08-26 12:16:54
    敏捷测试就是符合敏捷宣言思想,遵守敏捷开发原则,在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践,这些实践具有鲜明的敏捷开发的特征,如TDD、ATDD、结对编程、持续测试等。和传统测试的区分...
  • 敏捷开发随笔

    2020-06-10 11:55:23
    不同角色如何实践敏捷开发? 产品经理代表用户体验,会每天确认系统。新内容必须是用户可见!可操作(测试)!只说后台做了多少,而看不到的都是无用功! 技术经理代表输入输出管控,必须确保每天有可供体验的...
  • 1、 团队优先 个人觉得,不管做啥,应该把“团队合作”放在第一位。如果团队本身没有凝聚力,没有向心力,那团队就是一盘散沙,有力无处使。...根据木桶原理,团队中只要有任何一个角色不够效率,不够敏捷,那...

空空如也

空空如也

1 2 3 4 5 ... 17
收藏数 337
精华内容 134
热门标签
关键字:

敏捷开发测试角色