敏捷测试(4) 基于story的敏捷基础知识

基于story的敏捷基础知识----需求管理(一)

基于story进行需求管理

(1)使用story模式来管理需求,将庞大的MRD划分为一个个合适粒度,且可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了,易达成一致,且可节省大量的需求评审时间。

(2)要求PM在第i个迭代上线前一天,完成所有第i+1迭代的需求拆分,和RD、QA达成理解一致,且辅助QA一起补充完验收标准,在第i个迭代启动前完成所有story的相关工作。

(3)每个story都有自己的优先级、估点(即预计花费时间),以此为依据判断是否纳入某迭代。

(4)PM随时待命,快速响应,答疑解惑、修改设计不足。

每个story沟通流程

虽然没有需求评审会议,但每个story都是经过仔细推敲和沟通过的

(1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

(2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

(3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

(4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

(5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。

上述每一个步骤都被落实后,不仅需求质量被保证了,QA也成了需求管理的核心。即使有未考虑到的问题,敏捷团队也能够很快消化,在下个迭代迅速优化。

基于story的需求管理方法

更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

时间: 2024-11-05 13:19:58

敏捷测试(4) 基于story的敏捷基础知识的相关文章

敏捷测试简介

时至今日,还讨论这样一个老话题,是否感觉老调重弹?因为两年前(2010年底)时任谷歌中国测试经理的段念先生就 写了一篇文章<什么是敏捷软件测试>(刊登在InfoQ网站上[1]), 就已经谈到这个话题,"敏捷软件测试更多的是一种 理念,而非过程".在2011年,我自己也写了一篇文章<敏捷测试的思考和新发展>,刊登在<程序员>杂志上,谈到"在 BDD.ATDD和TDD最根本的.共同的思想基础上,构成一个全新的.更完善的敏捷测试框架"[

敏捷测试理论以及实践(4)

上面已经谈到了准敏捷测试模式了,离咱们所说的敏捷测试已经无限接近了,但是要了解真正的敏捷测试,还是需要回到敏捷开发上来讲,前面一开始已经说过,敏捷测试严格上来说其实是属于敏捷开发的一部分,所以敏捷开发的价值观也会同样适用于敏捷测试,那么敏捷有哪些价值观呢?总共是五个,分别是简单.沟通.反馈.勇气.谦逊. 光看这五个词,我想大部分人可能会晕乎了,不知所云的,难道敏捷就五个词能概括了?就像电影里出现的武功秘籍一样,一招就一个图,我们看了根本就不知道是啥,人家一看就能炼成神功了. 其实呢,这几个价值观

敏捷测试理论以及实践(6)

2.编码阶段: 完成了需求设计阶段,就要开始进入编码阶段了,虽然说开发与测试需要同步的,但是功能还没做完也没法同步去测吧,不过还是有事做的,就是可以同步开始写测试用例,这个就用到DevTest工具了.DevTest主要用于管理测试用例,以及根据测试用例来进行在不同环境下.不同时间下和不同的范围里进行的手动测试与自动测试,并且可以生成报表供评估测试质量和产品质量. 也许有人有疑问,敏捷测试还需要测试用例?我的答案还是"是"又"不是". 先说"不是"

敏捷测试理论以及实践(1)

前言: 关于敏捷测试这块内容,本来之前一直想写的,但是自己一直觉得还没法归纳得很好,不过最近有个客户到我们公司来拜访时,也提到了他们公司要把测试这块工作弄好的事情,谈了几个小时,相互交流了一下意见,总算双方都有点收获,所以接下来几天想结合我们公司的实际情况介绍一下敏捷测试的一些相关知识,当然咱的想法也并非很权威啦,仅供参考. 正文: 谈到敏捷测试,可能有些人不一定听到过,不过很多人应该听到过敏捷开发吧,其实从广义来讲,测试也是属于开发过程的一部分,测试完成以后开发过程才算真正完成,所以敏捷测试其

敏捷测试(6) 基于story的敏捷基础知识

基于story的敏捷基础知识----需求管理(三) (3)每日站会 开发 story模板"> 站会的目的有三个: (1)周知进度 仅从用户故事和任务的层面周知进度,任务进度只有两种状态:完成或未完成(完成百分比). (2)周知计划 你将会在下次会议之前做哪些工作? (3)抛出问题 哪些东西阻碍你的进度?("没有问题",意味着你能够交付自己当前的任务,而且符合估算的时间范围)如果遇到需要解决的问题,可以在每日立会之后处理. 实现一项目的必要前提: 1.站 2.敏捷项目必须

敏捷测试(3) 基于story的敏捷基础知识

基于story的敏捷基础知识----story编写 为什么使用Story? 软件行业40年多来,需求分析技术已经很成熟了,但是MRD驱动的过程不堪重负.因为往往MRD编写会占去很多时间,MRD评审又会占去大量时间,编码完成过后提测,压力又全部倾注在QA身上,往往临计划上线时间,或者体验还差,或者bug还太多,或者项目延期. 使用story,项目完成时间会大大缩短,上市时间大大缩短.主要原因: A. 采用story模式,将大需求拆为可独立交付的小story,需求清晰明了,节省了大量的需求评审时间.

敏捷测试(7) 基于story的敏捷基础知识

基于story的敏捷基础知识----迭代启动会.迭代回顾会 除需求讲解意外,需要所有团队成员参加的会议仅有两个,分别是"迭代启动会"和"迭代回顾会". (1)迭代启动会 在迭代开始之前,需要召开迭代启动会,目的有以下两个: 明确迭代周期,即上线时间: 明确迭代目标,即以什么样的优先级,交付哪些story. 在明确了迭代周期和上线时间后,按照前面提到的"迭代规划"来开迭代启动会即可,在此不再赘述. (2)迭代回顾会 在每个迭代结束后都有迭代回顾会,

敏捷测试(5) 基于story的敏捷基础知识

基于story的敏捷基础知识----需求管理(二) (1)定期发布 定期发布上线,把整个项目划分为一个个迭代,每个迭代时间大小固定(基本固定),迭代结束时上线交付一次. 开发 story模板"> (2)迭代规划 迭代规划相当于整个迭代的计划,帮助我们管理并保证每个迭代的交付. A.迭代规划的前提: story沟通及验收条件的补充完成. PM给出story的优先级 RD.QA给出story的估点,估点可取范围为(1.2.3.5),若有大于等于5点的story,尽量拆分成更小的story. B

敏捷测试(8) ATDD整体研发流程

ATDD整体研发流程 有了前面的基于story的敏捷基础,接下来来介绍一下验收测试驱动开发的整个流程. 名词解释: ATD,即验收测试设计(acceptancetest design) PM,即需求整理方(product manager) RD,即开发人员(Research and Development) QA,即品质保证人员(quality assurance) 如上图所示,整个流程被分为三个粒度,分别是:项目.迭代.story. 一个项目被划分为若干个迭代: 每个迭代由若干个story组成