首页 >> 知识库 >> 软件测试 >> 正文

全功能团队——没有QA的团队

发布时间:[2012-9-6]     来源:51testing     作者:     点击:

  在胡凯近期组织的新任PM/TL经验交流会上,提到了什么是合适的leverage模型。碰巧Mike Gualtieri最近一篇文章中提到了没有QA的团队,让我觉得,没有QA的团队,不但靠谱,而且没准会有奇效。

  没有QA,缺少了最后的保障,软件质量是否会一降千里?不会的。没有单独的QA,并不意味着没有人去做测试和质量保证,而是让每一名dev承担测试的责任。很多人的经验表明,开发过程很常见的一个问题是,Dev匆匆忙忙做完story,就认为任务已经完成,剩下都是QA的事情,即使出了问题,也是QA测试不周。在心理学上,这是一种典型的心理依赖。由于认为自己只承担开发责任,Dev会用很大的精力追求开发速度,这是导致缺陷过多、质量下降的主要原因。在没有QA的团队,Dev要100%对质量负责,这种责任的转移,让Dev去掉了侥幸心理,从而会重视每一个Story的质量。

  另外,敏捷软件开发中,常提的一个概念是“关注交付”。软件被开发完成,没有任何价值,只有上线,并给客户带来价值,才算真正交付。这种说法很多人在很多场合都曾提过,但是“纸上得来终觉浅”,不亲身体验,很难体会其中含义。没有了QA的团队,会创造这样一个“绝知此事要躬行”的条件,让Dev的视角不再局限于开发,而延伸到软件生命周期中更接近交付的地方。这样的体验,会不断冲击Dev惯有的思维,让他们思考并理解交付的真正含义。

  没有QA,很容易实现完全的自动化测试。自己完成的story被别人破坏怎么办?没有Dev愿意每次都手工回归测试,只能是用自动化。而Dev编写自动化测试,具有QA无可比拟的优势。举个常见的例子,很多项目会采用依赖注入机制,不光可以减少代码的耦合,同时可以提高项目的可测试性,非常易于编写单元测试。这对自动化的功能测试同样有效,Dev在基础架构上,在开发中时刻都会关注可测性,从而避免很多问题,比如我经历的一个案例:某Web开发团队,Dev只开发Story,QA则经常抱怨,Web页面非常难于编写自动化测试。

  谈了一些没有QA的好处,我觉得它的局限在于:

  1、某些遗留系统中,对环境的依赖性比较强,很难做到完全的自动化测试,必须依赖QA的手工测试。相反可以从新项目开始尝试,引导甚至强制团队编写易于测试的程序。

  2、大团队怎么办?敏捷中,几十人的团队就算作大团队了,而我认为大团队是反敏捷的,应该拆成十人以下的小团队。小团队更具可控性,对软件质量会有更高的保障。

  如果下半年有机会开始新项目,我一定要做这样的尝试:没有QA的团队,可以交付更高质量的软件。

关键字: