SpecDD过程追溯:需求驱动下研发过程完整可追溯性
  • 量化需求,以驱动开发
    • 需求分解:需求先被分解为Epic需求面(大致需求)
    • 需求量化:进一步分解为Spec需求点,并可使用Spec去关联需求文档和设计文档
    • 需求分配:Spec被分配到开发空间中,生成多个Story和 task进行实现,且每个task可以含有多个QA测试子任务
  • 开发工作被分解到开发空间、里程碑和各个冲刺迭代中
  • 需求与产品Backlog相整合:产品Backlog是一组待处理的Story和开发任务列表。Story需要进一步分解为多个开发任务,代表了团队在开发周期中承诺的待开发任务。
  • QA测试用例在开发迭代周期内被定义,QA团队既能够独立工作,同时又能与回归测试相整合

了解更多 >

SpecDD 开发迭代

Sprint工作量来源于产品负责人选定的一组候选功能和缺陷列表。功能以Story的形式分配到Sprint,每个Story包含一些细分的开发任务。缺陷通常以独立存在的开发任务(不与Story相关联)分配到Sprint。

随着任务负责人对各自工作进展的推动,每个开发任务经历初始状态、中间状态,到最终完成状态。使用一个简单的敏捷工作流,常常能够帮助团队管理任务的生命周期。SpecDD框架下的任务工作流,往往包含以下几个状态:待分配,处理中,QAFloater验证和完成任务。随着任务负责人每天的进展,剩余工作时间理想情况下,将从最初的估计值不断减少直至为零。伴随开发团队自我管理,自我驱动地完成所有承诺的开发任务,生成的燃尽图报表(如图)最佳地展现了团队Sprint工作量的进展。

了解更多 >

SpecDD Sprint质量模型

Sprint工作量由一组待实现的Story、开发任务和缺陷组成。在Sprint开始时,为开发人员估计每个工作项的工作量,可以使用剩余时间或点数。那是否需要创建与开发任务同级别的QA测试任务,并作为工作量的一部分?

一个常用的,但并不合理的做法是为所有的开发任务创建同级别的QA测试任务,使用同样的办法,为QA测试任务也设定具体的剩余时间,从而驱动QA测试任务的进展。对于一个开发任务,估计剩余时间是可能的,并且能很好地激励任务负责人,在估计的时间内努力完成工作。

而对于QA测试工作来说,在Sprint开始时,将所有可能需要的各种测试任务创建完毕,并且估计剩余时间,实际上是不可能的。更为重要的是,对QA测试总时间的估计,阻碍了建设一个自我驱动的团队。不包含QA测试时间,对于Sprint的总剩余时间,团队总是可以自我驱动的,并将它作为要达成的动态目标。而包含QA测试时间,它只会损害一个自我驱动的开发团队,在他们估计的时间内,努力完成所有开发工作的积极性。

在SpecDD模型中,通过为开发任务建立子任务来表示QA测试工作。对于功能性开发任务,可以基于开发任务所对应的父级需求,生成相应地测试标准。随着需求被充分理解并文档化,团队可以为需求Spec和Story创建测试用例,来准确表达质量标准。对于缺陷修复任务,测试子任务可能并不会与测试用例相关联,因为缺陷描述本身往往就保留了QA测试的标准。右图说明了基于QA测试子任务的SpecDD Sprint质量模型

了解更多 >

SpecDD 回归测试模型

在QA floater和测试子任务模型下,一个理想的SpecDD Sprint将能够交付一个没有缺陷的可执行软件。但现实中往往是,在多个Sprint迭代后,相互集成的产品,势必会有一些缺陷。没有一个稳固的回归测试实践,多团队参与的大型项目,无疑将缺乏质量控制和可扩展性。

SpecDD使用测试用例,并与运行时的环境变量相结合,正规化表达并量化产品的质量。QA测试计划为产品的发布指定了测试标准。为了更加灵活高效地执行测试计划,常常使用测试周期来表示较小的测试迭代,一个测试周期可用于覆盖QA测试计划可能产生的所有任务的一个子集。

一个测试周期包含一组测试任务,测试任务是基于测试用例与运行环境变量排列组合下产生的具体实例。可以手动或使用自动化测试工具,来执行这些测试任务。左图反映了开发迭代周期与QA 测试周期的关系。正如您所见,QA测试周期的规划和执行,不一定同步于开发迭代周期。当您想将新发现的缺陷分配到当前进展中的Sprint时,敏捷开发方法会要求测试团队只能将缺陷提交到产品Backlog中。QA回归测试团队负责提交缺陷,但他们并没有权利决定何时修复这些缺陷。拥有一个独立的测试团队,更早地发现缺陷,并在产品Backlog中对缺陷进行优先级排序,实际上有助于创造一个更加灵活的敏捷过程。

了解更多 >

了解更多SpecDD 专题介绍和文章

售后服务平台登录

用户名:

密码:

登录