一种高效、敏捷的测试团队组织形式

上一篇 / 下一篇  2011-08-28 09:56:11 / 个人分类:测试管理

关于测试团队组织及产品质量,经常看到有人提出类似下面的问题:
1、研发、测试人员比例该多少?
2、研发团队不重视质量怎么?
3、测试人员对项目的设计、实现理解不够怎么办?
4、由于缺乏文档,导致测试困难,怎么办?
5、谁该为项目质量负责?
我们在这几年的多个项目并行的敏捷研发过程中逐渐形成了一种测试团队组织形式(如下图所示),公司上下也逐渐不纠结上述问题了。


【注】
实线带箭头表示:直接上下级,是汇报关系;
虚线无箭头表示:非上下级,是沟通关系;

上述组织形式的优点主要有:
1、研发、测试资源在迭代过程中可以随时调整(迭代任务包括开发和测试两类,有整个团队共同完成);
2、全员参与测试工作,共同提升质量意识及测试能力;
3、专人负责项目过程中测试工作的计划和管理;
4、节省了维护大量中间文档的成本;
5、质量和进度一样,对整个团队很关键;
6、逐渐形成一种良性循环:严守UI规范、编码规范,多数浅显的问题在研发过程就发现并修正。

让其有效运行的一些关键点如下:
1、测试经理和项目经理一样重要,一定要用对人;
2、对测试经理的主要考核指标是:测试计划、测试设计的有效性,测试资产的复用度,测试过程及技术改进;
3、研发工程师在迭代过程中承担研发和测试两类工作,但不要并行;
4、项目质量(释放后缺陷密度等)是对整个项目团队的考核指标;
5、测试经理对迭代是否延期有一定的话语权,如果与项目经理不能达成一致,则有上级仲裁;
6、项目质量相关的反馈路线是:测试经理—>测试主管—>BOSS。但是在向上反馈前,需要先在干系人之间做好沟通。比如测试经理向测试主管汇报某项目质量时,观点可以与项目经理不一样,但要确保事先跟项目经理沟通过(只是沟通的结果没有达成一致而已)。

没有什么经验“舶来”之后就能立竿见影,都需要结合实际情况坚持不懈的不断调整、固化。(这个过程我们用了将近一年半)。
以上,仅供各位同仁参考。

TAG: 敏捷测试 测试组织

 

评分:0

我来说两句

日历

« 2024-05-02  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 17920
  • 日志数: 13
  • 书签数: 4
  • 建立时间: 2011-08-26
  • 更新时间: 2011-09-05

RSS订阅

Open Toolbar