测试在敏捷团队当如何?

Dev(Developer)  :开发

TE(Test Engineer)    :测试

PM(Product Manager)    :产品

 

敏捷:快速的响应客户(需求),高效的完成开发,不断的追求完善。

 

TE在敏捷中应该做些什么呢?

 

流程1-故事分析

角色:

Dev、TE

内容:

需求交接前夕,PM将需求上传到文档管理区并邮件通知,Dev、TE分析需求

初步制定测试策略与测试计划

初步安排测试任务

输出:

测试策略、测试计划

测试工作量初步评估

流程2-故事计划

角色:

整个Team(PM、Dev、TE)

内容:

需求交接(宣讲),了解更多细节

确定测试工作量

更新测试策略各测试计划

考虑环境和并着手准备

输出:

测试策略、测试计划

测试工作量评估

 

流程3-Story Kickoff  

角色:

Dev、TE

内容:

TE与Dev一起理解分析故事

列表疑虑点

Dev拆分task,并思考设计思路

TE列出测试要点

TE各Dev一起就以上各点对PM和Dev进行反串讲(用例与设计评审)

输出:

测试用例

 

流程4 -故事开发

角色:

TE、Dev

内容:

TE与Dev结对、实现自动化测试

输出:

自动化测试

PS:关于这点,没有自然语言自动化体系支撑,无法达到实行标准

 

流程5-Desk Check

角色:

TE、Dev、PM

内容:

Dev本地运行系统,准备数据自主UT

TE对此环境做快速测试,检查各流程功能是否开发完成,并反馈问题

PM 全程评价是反馈问题

输出:

Desk Check 问题记录

PS:Desk Check尚处于developing阶段,发现问题或者开发方向错误,Dev能快速修复,这样才能保证功能进入下一个阶段。

 

流程6-探索性测试、SIT

角色:

TE

内容:

执行测试用例

执行探索性测试

提交缺陷并及时验证修复问题

不能解决问题及时与PM沟通

每日进度反馈,并思考接口安全与性能测试

输出:

测试报告

 

 

流程7-UAT和产品验证

角色:

PM、TE

内容:

TE辅助PM验证功能

PM反馈问题

输出:

问题清单

 

流程8-上线

角色:

整个Team

内容:

TE上线线前回归验证

TE、Dev上线生产环境部署

TE、PM生产功能验证

验证反馈

输出:

上线验证报告

 

 

敏捷源于理论、而高于理论:

1、敏捷团队应该是怎么样的呢?

团队拆成小组作战方式,小组共6~10人,其中TE  1~2人,具体人数按实际情况拟定,选出组长。

组长需要分配工作,组织每天的晨会,收集问题,解决问题,总结反馈。

需求按照模块、共性、特性分配给小组,各组负责一部分需求,全组员协作、交接需求、分析需求、拆分任务、评估时间、制定计划、完成开发测试。

晨会(重要),所有人都必需讲真话、讲短话、讲实话。讲话内容应该是昨天的完成进度、问题、阻塞、风险、建议和今天需要做的事情;整个过程应该控制在5~15分钟内完成(更快、更精准、更高效)

版本周期中小组之间可以交叉协作,此点看重组员的综合实力。敏捷很考验综合实力,也是能更快的提升综合实力的。

能力强的Dev与TE可实现结对开发,完成代码UT。

 

2、分析需求、评估时间:

分析需求:

需求管理是以特性、故事、任务为框架管理。以故事为单位来评估时间汇总到特性。所以PM的需求文档,应尽量以特性为一级标题、故事为二级标题、内容须包含所有需要的UI、数据字段、功能逻辑、权限控制、三方对接等。以便在交接(宣讲)需求时,Dev与TE第一时间响应需求,折分故事。

需求交接(宣讲)完成。小组长带头,将本组负责模块需求拆分故事在便签上写出来,一个故事一个便签,列两个时间:Dev评估时间、Te评估时间。由对应Dev与T马上完成这个工作,然后小组长分析统计反馈。评估时间尽量在一小时内需要完成,半小时达优,达到敏捷。

2、用例与功能:

敏捷的要求在需交接(求宣)后,评估时间前,TE应该在纸上将所有需求测试点都逻辑出来。须简洁明了,即省而优,方便后面用例开展。

1、周期较快、需求较小、功能不重要的,写测试点

2、周期适中、需求适中、功能适中的,写测试点,测试场景

3、测试场景周期较长、需求很大、功能很重要的,写测试点、测试场景、接口性能安全,设计测试数据

测试:

1、Desk Check:敏捷没有三到四轮测试,仅仅一至两轮测试,所以要更早的介入测试,越早发现问题成本越小。

2、探索性测试:精准快速的熟悉陌生的新功能,新软件,方便后续用例测试。

3、习惯使用工具:熟练使用F12、抓包、SQL、postmen等工具与手段快速分解功能与测试用例。

4、良好习惯:缺陷里简单准确的描述出步骤、数据、现象、期望、图片等,方便Dev精准定位问题所在。

5、日清日结:决不遗留缺陷到第二天,Dev改完第一时间验证。

针对第5点举个例子:

上线前一天发现了缺陷,卡了部分流程,Dev需要晚上加班解决,然而TE很早撤退了,Dev解决完提交验证,缺陷只能等到明天来验证。TE第二天缺陷验证不过,吐槽Dev不行。但那部分流程还在卡着,任务无法完成。坚难的上线。

如果TE当晚跟进Dev验证这个问题,发现不通过,Dev及时解决。隔天一来,流程顺畅,测试通过,任务完成。舒服的上线。

4、每日总结:

每日总结:文字记录当天的进度、缺陷、难题、完成了什么、是否正常。明天需要做什么,建议性想法等。当为第二天的晨会准备。

5、冒烟与回归自动化:

好的自动化用例,可以重复利用、减少兼容问题、节约成本、解放人力、提高团队的能力。

自动化测试启动,测试组必须有一个经验丰富的ATE去做下面的事情:

1、首先需要确认项目自动化的可行性,通过历史版本观察,前端变更频繁不适合做UI自动化,后台变更频繁不适合做接口自动化,前端与后台都变更频繁的项目可以放弃自动化。不过并不绝对,分析各模块,稳定的可先实现自动化。

2、设计自动化策略,制定冒烟计划、回归计划:

策略:选择框架、工具、语言

自动化用例具有健壮性、重用性、独立性、维护性等特点,所以需要制定自动化计划。

冒烟计划优先制定,一个系统的冒烟用例不会多,保证主流程的通畅,用例检查点(断言)不用多、一个用例一个即可。

回归计划在冒烟用例完成后可以制定,回归用例与冒烟用例的比率应该在1:50~100。一个用例的检查点(断言)在3~5个,重点:回归用例ATE一个人难做的。需要测试组一起做。

自动化程度越高的项目TE越舒服。

建议:自动化测试的建设一项目稳定的情况下,越早越好,绝不能拖到敏捷开发时候。

6、持续集成:

CI:Continuous integration  持续集成

敏捷不可或缺的一项技术。

自由工具: Jenkins

可持续集成每日按定时任务自动部署,并邮件通知结果。减少了人功的操作,减少了错误率,使流程规范。

1、代码自动检查UT

2、自动编译

3、自动构建

4、自动部署

5、定时执行自动化用例

TE须知道如何搭建,并实战

7、管理工具使用

ALM:application lifecycle management    应用程序生命周期管理

TE须深入了此类工具

不管什么工具,一个TE拿到,在一段时间都应该玩的炉火纯青。故略~

8、版本数据监控:

TL技能,故略~

原文地址:https://www.cnblogs.com/xmLaoTan/p/11688926.html

时间: 2024-10-08 21:14:41

测试在敏捷团队当如何?的相关文章

敏捷团队中测试人员的角色

Karen Greaves和Sam Laing将会在Agile Testing Days 2015上发表主旨演讲,演讲题目为"测试人员正在消亡",Agile Testing Days 2015将于11月9日至12日德国Potsdam举行.小编将会覆盖本次会议报道. 小编对二人进行了采访,关于敏捷是如何影响测试人员角色的,为了缩短测试交付周期,测试人员可以采取哪些措施,敏捷团队中测试人员与其他团队成员之间的协作,敏捷团队中测试人员可以贡献的价值. 小编:我的经验是,敏捷更广泛的普及率正在

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

敏捷团队的规范与准则

敏捷团队的规范与准则 阅读目录 1.序言 2. 敏捷团队的共识 3.Worktile的使用规范 4. 计划会议的规范 5.评审会议的规范 6.代码规范 7.设计原则与规范 回到顶部 1.序言 打造一个金诚所至的敏捷团队,需要大家自发的来遵守以及完善相应的规范.大家在自我约束的前提下,彼此之间互相影响,由下而上推动团队的建设.所以规矩.准则应该是越少越好,通过良好的自我约束驱动团队的成长. 在阅读本文档之前,假设你已经了解了敏捷开发(Scrum)的相关知识,若从未接触过敏捷开发,请先查阅 <敏捷开

多个敏捷团队之间的版本控制

http://www.infoq.com/cn/articles/agile-version-control/ 多个敏捷团队之间的版本控制 如果我们有多个敏捷团队在同一个代码库上工作时,如何将彼此之间代码互相冲突的风险最小化?如何确保每个迭代结束时拥有一个干净的.可发布的软件版本?本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例——这正是我们在<Scrum and XP from the Trenches>中描述的公司所采纳的方式. 本文并非专为版本控制专家所写,实际上这样

曾经成功的敏捷团队为什么失败?

9月份某日,我参加了智联研发每日微信沙龙,讲述了一个团队先搞敏捷成功,后来失败的故事,来自于某知名公司的亲身实例,非常棒. 沙龙后,咕咚老王整理了一篇博文<一个成功敏捷团队的失败历程>,(转载在 http://blog.csdn.net/zhangmike/article/details/40950267 ) 本文试着从我的视角来分析下为什么? 首先来看其前期为什么成功? 1,项目经理首先选用了Scrum,决定实施自动化测试,允许测试落后开发一个Sprint 2,美国老大不满意,要求开发测试必

一个成功敏捷团队的失败历程

昨天通过微信沙龙,分享到了一个案例,讲述的是从成功到失败的过程. 很多人可能疑惑,很多案例都是从失败到成功,这个怎么反了.很多成功背后都有其原因,可能很励志,但从失败中我们能够获取更多.毕竟我们的知识大多源于失败而非成功. 故事是这样的(括号中的是笔者的情绪表达 :)): (在很久很久以前……)某公司成立了一个团队,开发一款全新的产品.产品的开发模式是产品需求获取和开发同步进行,团队构成为:项目经理带领开发和测试两个子团队,每个子团队各有一名Leader.产品经理在开始仅提出最基本需求,根据内部

敏捷团队管理实践纪实(二)

今天的晨会得到确切的数据证实,新入职的同事工作效率极低,一天大约只有100行左右的HTML+JS+CS的结果,并且没有将自己测试的时间和沟通的时间计算进去,导致下午的进度被延迟到了今天上午.这位同事的计划内容是第两小时,做一件什么事情,但是并没有详细分拆事情的细节,该同事的表达能力也存在较大问题. 针对这一问题我调整了策略,要对于新人给予的要求是极其细致的分解其工作内容,引导他考虑到数据库数据变化,构架变化,界面改动,逻辑变更,沟通时间和测试时间的总时间,而过程中需要及时询问,直至他自己可以制定

敏捷开发讲义---如何打造敏捷团队

PPT下载链接:http://pan.baidu.com/s/1bncprTd 敏捷开发分享讲义-修改版 第1页:个人信息 就不做自我介绍了,我的基本信息就在PPT第一页.7月26日,也就是上周六,我和会成参加了一天的培训,关于敏捷开发的.参加这次培训我们俩主动申请的,因为这次培训适合的听众除了中高层领导.项目经理.产品经理之外,还适合有软件经验希望往项目管理方向发展的人士."不想当项目经理或者项目主管的IT屌丝是真屌丝",不想成为真屌丝,所以参加了培训.但这次跟大家分享是被婷姐逼的(

【 腾讯敏捷转型No.4 】为什么敏捷团队不要超过15人

早期,腾讯公司的架构是比较简单的.从上至下分别是:公司--商业单元(BU)--部门--组--员工,每个部门基本上就是负责一个大的产品,每个组都是按照专业进行分工和管理,例如:产品组.终端组.后台组.设计组.运维组.质量组等等. 草拟一个项目需要在每个小组里面抽调人力,部门的总经理就需要和每个小组的组长沟通,经过沟通以后,确定了该项目需要的人力安排,然后就开始执行项目.执行项目过程中的困难,需要决策,例如:人员安排调整,产品需求变更和是否延期发布等等,都需要总经理和组长们开会协调或者私下沟通决定,