敏捷项目的质量保证

上一篇 / 下一篇  2007-11-28 22:16:04 / 个人分类:其它

何谓敏捷?

敏捷在一定程度上是一种思维方式。它鼓励个人与团队的融合,崇尚快速响应变化,抛弃繁杂的文档。这些从敏捷的宣言可以看出:个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。(见www.agilemanifesto.org

c,N,x&nN&g iY2N0

 51Testing软件测试网.@!L!p?$K6w

敏捷的开发方式与传统软件开发方式存在很多的不同。例如,比起传统的开发模式,敏捷方式更注重人与人之间的沟通和交互;通过区分优先级并专注于尽早发布来对待进度压力;要求顾客紧密合作并参与到项目中来。

;B8G x b2LC0

 51Testing软件测试网6W8M7b7wp_}*v4|(MU

越来越多的人意识到传统软件开发模式的不足,越来越多的人开始拥抱敏捷。

/ypY bU{0

质量保证在敏捷项目中的角色定位

敏捷把我们的注意力转移到精简的项目组、小步快跑、迭代发布的过程模式中来。那么实施敏捷项目管理的团队是否意味着不需要文档、不需要测试、不需要质量保证了呢?51Testing软件测试网2_f9CG!RF

 51Testing软件测试网 EH3a%g2l$BW

在回答这个问题之前,我们需要考虑质量保证在敏捷项目中的角色定位问题。

_Zk,|c9d4HI0

 51Testing软件测试网8E"abFVN

抽象的思想与能工作的软件是不一样的,因此软件需求文档不能代表充分地代表软件。敏捷方法鼓励通过合作和面对面的交流来获得文档不能替代的信息沟通。那么就意味着我们传统软件工程中的对于需求的质量保证工作的方式不再合适了。

/k2c+t6|*~o0bH*GK0

 

!Bn{c4i'I&m8a0

在敏捷项目中,软件测试也需要敏捷。Brian Marick分析并指出了敏捷测试与传统测试的很多不一样的地方。敏捷测试抛弃了旧有的关于测试人员沟通方式的观点。就像需求和设计文档的不充分一样,测试计划和测试报告也是不充分的。敏捷测试要求测试员与开发人员、用户充分交流和沟通,面对面的沟通。那么就意味着我们传统软件工程中对软件测试的质量保证工作不能从检查文档、评审文档出发了。51Testing软件测试网7nC;Fa9H

 51Testing软件测试网"qX*HpJ[ ~f!oG

传统的软件测试作为质量保证的控制手段,起到质量把关的作用,测试人员站在顾客的角度来批判产品、检查产品质量是否达到要求,测试的服务对象是顾客。但是敏捷测试的服务对象有所改变,测试的服务对象是开发组,帮助开发人员减少由于产品的不确定性而带来的损失。(参见http://www.testing.com/writings/purpose-of-testing.htm)也就是说,质量保证的控制手段-软件测试也有所不同了。51Testing软件测试网)F!}au|!P0? o&k

 51Testing软件测试网+ebC~!x&f%o

因此质量保证工作在敏捷项目组中的角色定位可能要发生一些改变,我们也许不再是抱着一堆文档在评审,追着开发人员要文档的QA;我们也许不再是指责产品不过关,要求返工的QA;我们也许不再是要求项目组拿出与顾客充分沟通的证据来的QA

L^3L5to0

敏捷对质量保证的提示

目前,虽然敏捷项目管理方式逐渐兴起,但是观望的、浅尝即止的人多于实践的人,尤其是关于如何在敏捷项目中开展质量保证工作的实践还比较少。因此很难准确说明敏捷项目中的质量保证工作会有哪些改变,但是我们能够从敏捷的原则和开发方式中得到几个有用的提示。

r:k;HXB0

1、 程序员开始被测试所感染。51Testing软件测试网:H js@Dzyy

感谢BeckGammaJUnit单元测试工具,现在,测试驱动开发被大部分的开发环境所支持。敏捷项目中的程序员更具单元测试意识。51Testing软件测试网i$d+fJ;\8w

 51Testing软件测试网Ae2n KX,Pv

2、 增量的开发方式

Z4`5I.Y$za5n0

很多小的产品版本发布,而不是一个唯一的计划好的版本发布。51Testing软件测试网,Rj)NJ!JE N~

 51Testing软件测试网iJx;w3m*CJ0s$U)|R4}y

3、 FITFramework for Integrated Test

@Ag1n'{:z0

FIT允许用户使用简单的Word文档或HTML文档来定义他们自己的测试。FIT能产生用例子描述业务的文档。51Testing软件测试网-Kh4E1f+@"rP

 51Testing软件测试网.Ftl/w*w

这些给我们的提示是:51Testing软件测试网 AMaeWRo

1、测试工作不仅仅由测试人员担任,其他项目组成员也承担了部分的测试工作。那么对测试的质量度量模式可能就要发生改变了。51Testing软件测试网F7A2f-v#jp]oR

 51Testing软件测试网7H,A,sn.r#^y

2、沟通仍然是项目组不变的主题,但是沟通的方式更多地侧重在口头、面对面方式的交流。那么对沟通的质量度量模式可能就要发生改变了。51Testing软件测试网Qpd4s;y}"h

 51Testing软件测试网#a9^9X/{,ZR B)B5W

3、迭代、快速发布、重构等软件开发方式对如何进行配置管理的控制提出了新的要求。51Testing软件测试网,j`:sX \

总结

敏捷项目管理代表了一种软件开发思想的回归,软件的本质是为用户提供价值,为用户解决问题。所有软件工程的活动都是围绕这个核心思想来进行的。极限编程、测试驱动、SCRUM等等,都只是为了突现软件活动中的某方面的重要性而提出的,但其核心都一样。51Testing软件测试网[;r0Gz C

 

&DEp ~Zx0E0

个体和交互、能工作的软件、顾客合作、快速响应变化,这些原则毫无疑问会使传统的质量保证工作方式发生改变。很多质量保证的手段和方式可能要发生剧烈的改变,但是至少有一样东西是不变的:质量保证的目的仍然是确保交付产品的质量。

B"M#O9zh \dn0

参考文献

www.agilemanifesto.org

cP`3~f8nb0

http://www.testing.com/writings/purpose-of-testing.htm51Testing软件测试网&[V!i!\c^!?N

Quality Assurance on Agile Processes - Pete McBreen

|E{y!TbY&}][(W6t$K0

Agile Testing Directions - Brian Marick

+`"uQ1R2k l&Z XX|)b'q0

 51Testing软件测试网7o&X\ p9B'|"PT&rA


TAG: 测试管理 质量保证 敏捷开发 QA 其它

Testing is believing 引用 删除 陈能技   /   2007-11-30 21:32:02
敏捷测试是目前实践比较少的一个领域,Brian Marick在这方面有一些见解:
http://blog.csdn.net/Testing_is_believing/category/333219.aspx
比较狠的测试间 引用 删除 qiguojie   /   2007-11-30 00:15:57
敏捷开发虽然是软件工程发展的后一阶段,但是实际上不停的迭代过程对于软件质量的影响是很大的,这个不需要讨论

在进行质量保证的过程中,抛弃部分浪费时间的文档过程是必要的,但是关键的过程控制仍然不能简化,特别是测试这个阶段;

需求和设计文档的不完整性,可直接导致测试需求的不完整性,这样浪费的沟通时间会更多,造成成本的增加;而且直接沟通对双方的表达能力以及其他的一些能力有较高的要求,否则会适得其反。

目前国内有很多公司招能在敏捷开发的项目中进行测试的测试工程师,是一个挑战哈
 

评分:0

我来说两句

Open Toolbar