然而,在敏捷开发中,整个团队都要对质量负责,而不仅仅是测试人员。Gregory说,如果没有整个团队对质量问题的一致认同,程序员就会将测试员看作是安全保障,从而只在bug追踪系统中与测试员沟通,那么这个团队便无法“凝聚到一起”。training.mypm.net
要改变这种局面,所需要的仍然是测试人员的主动。Gregory指出,测试人员要与程序员建立良好的关系,向程序员展示各自的职业价值,使整个团队对产品的质量负责。项目管理论坛
测试员可以在一些专业问题上帮助程序员,保证能够在迭代过程中进行测试,并解释对于整个团队来说“完成”所代表的意义。在追踪bug时,可以使用需求卡片(index card)。将需求开发中发现的bug写到卡片上并贴到墙上。项目管理者联盟
危险行为4:所有测试都想手工进行pmp.mypm.net
Gregory说,如果所有测试都想手工进行,那么必然赶不上程序员的进度。如果你一直把时间用在重复进行某些测试上,而没有对新功能进行测试;或需要越来越多的测试人员,却无法对部署或设计上的问题产生作用,你就会明白这个问题的重要性。bbs.mypm.net
不对测试进行自动化会导致越来越多的bug,并且无法及时响应新的需求。此外,可能无法注意到以往运行正常的功能已经受损,而测试人员也容易陷入陈规,无法学到新东西。项目管理者联盟
对此Gregory提出以下建议:项目管理培训
用自动化的方法建立回归测试集club.mypm.net
设计时考虑到易测试性blog.mypm.net
使自动化与测试同步(让程序员也参与)项目经理博客
帮助程序员编写优良的单元测试项目管理者联盟
使用对整个团队都有用的自动化工具项目管理者联盟
展示你的技能blog.mypm.net
推广你的工具包项目管理者联盟
危险行为5:忽视大局项目管理者联盟
在敏捷开发中,你必须能够展望全局,而不能被一些片面的东西迷惑。如果你发现一直进行的只有单独的需求测试,在发布的版本中有集成的bug,直到最后才制作报告,而你所做的测试都是程序员告诉你去做,并且只做了探索性测试,那么你肯定是没有考虑整体规划。www.mypm.net
如果确实如此,那么你的业务需求将无法联系到一起,各单元无法集成,业务流程不流畅,并且在编写程序过程中制定的决策也无法与最终目标吻合。Gregory说:“你在冒险,你的最终产品可能并不是所需要的。”项目管理者联盟
如果能先进行验收测试,用面向业务(business-facing)的测试进行有效的开发,充分考虑系统其它部分受到的影响,使用可以反映实际情况的测试数据,以及在编写程序之前将业务需求研究透彻,便能避免这一切。项目管理者联盟
还有一些可以使用的方法,包括:项目管理者联盟
使用电子公告栏进行规划项目管理者联盟
详细考虑业务流程项目经理圈子
进行探索性测试项目管理者联盟
使用实例项目管理者联盟
先进行验收测试项目管理者联盟
让程序员拒绝进行没有测试的代码编写工作项目管理论坛
|