qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

敏捷开发中的测试——SpecDD模型2

下图是一张 SpecDD的基本结构图:

  从图上我们可以清楚地看到,测试是贯穿于SpecDD整个过程的,从需求到开发到大规模测试,无一不显现着测试的影子。

  不过虽然测试贯穿整个过程,但是其实是不同类别的测试,比如需求阶段的叫做“设计测试“,开发阶段的“验证测试”,而产品进入大规模测试阶段叫做“Full Cycle Testing”,而我今天想讲的 Floater QA,即使是属于开发阶段的测试,下面来主要介绍一下:

  从英文上分析 Floater QA的意思大约是流浪的QA,引申开来大致就是这个QA不会去固定做一个工作,而是会参与很多地方的测试,哪里有需要就会去哪里。(以下简称FQA)

  那这个FQA有哪些地方需要去参与呢?

  ● 参与测试用例的编写

  ● 参与功能最初的验证性测试,修改测试用例,并且给出改善建议

  ● 与开发人员与项目经理紧密合作解决所有阻碍下一步测试的问题

  为什么需要有FQA这么一种QA的设置呢?

  因为在实际的软件开发过程中,我们可能会经常遇到一种情况,一个功能或者一个产品给QA去测试的时候,由于开发不可能把所有地方都测试过,所以一旦发现严重的问题,这些问题会阻碍QA去进一步的测试,但是开发不一定每次都是能第一时间去修复它,那也就使得对于这个功能的测试会因此暂停。如果这种问题不断累积的话,我们会发现一个更加严重的问题:开发很忙,因为有很多功能需要去做;而QA需要测试的功能也很多,但是却发现很多没法测试下去。

  所以引入FQA这么一类人,他们跟开发与项目经理合作最紧密:

  1、当功能还在开发的时候,先去写测试用例

  2、当功能开始有Build可以测试的时候,FQA首先去介入测试,他的测试其实是为后面的正规测试做准备,所以要确保该功能基本功能能够工作正常,符合设计文档,发现了问题,需要直接面对面与开发沟通,快速修复,如果这个最初的测试无法通过FQA的测试,那意味着这个功能的开发部分工作还没有结束,无法让正式的QA团队去进行测试。(平常情况下,开发人员为了改进度,可能草草跑了一下功能就说做好了,导致以后发现很多问题,进而影响其他功能,影响整个进度,而FQA的出现,能让这种情况较少出现)

  3、FQA测试完成后,开发人员可以正式把这个功能打到“待测试的状态”,让正轨的测试人员在各种的环境下进行更加细致的测试和性能测试

  4、FQA测试的同时需要根据需要更新测试用例,让之后的正规QA测试可以做些参考。

  所以,用一句话形容FQA的作用就是:帮助开发人员去高质量完成开发工作,帮助测试人员去顺利进行测试工作,帮助产品的开发能够在可控的范围下进行。

相关链接:

什么是SpecDD?

敏捷开发中的测试——SpecDD模型

posted on 2013-06-17 10:19 顺其自然EVO 阅读(999) 评论(0)  编辑  收藏 所属分类: CMMI & QA敏捷测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜