BUG 的生命周期(Bug Lifecycle)!
欢迎大家讨论! BUG从出生到死亡。 Bug状态太简单了吧。 会出现BUG在测试人员和开发人员之间 弹来弹去的问题,咋办? 楼主归纳的不错!基本就是这么一回事。2张表说明问题。如果出现BUG在测试人员和开发人员之间弹来弹去的问题,请CCB(变更控制委员会)进行裁定到底算不算BUG。或者直接测试人员和开发人员进行交流,看谁能说服谁?(不是吵架哦!是说理) 在实际的操作中还要更复杂一些,但是基本的流程就是这样的。 搂主画的不错,但是还有点欠缺。
图中只指明了测试人员与开发人员的关系,在Bug的提交、确认、修改以及最后的关闭过程中,还有其它的相关组人员参加,比如:测试经理、开发经理、配置管理员、变更控制委员会等。
测试经理需要审核测试工程师提出的问题
开发经理需要确认测试部提交的问题是不是Bug
配置管理员需要进行版本的确认,免得出现版本误差
CCB需要进行变更控制 你们学员学到的理论知识倒是不错,但是在实际操作中,有几家公司能够有CCB。
我只是把我们公司目前的BUG流程画出来提供交流。
re:bug
测试经理和开发经理不管你们工作了,流程中没有体现他们的作用呀。 多谢楼主了,也好有个思想准备认为该图目前最大的问题是开发人员单方面的权力大了点,是否修改bug一人说了算。这个有点头大。不知楼主的公司里是不是遇到过开发不认为是bug而测试认为是,而争执不下,最后不了了之的情况?就这一个主要矛盾。另外就是测试人员在确认问题时,做了回归测试吧? 过于简单啦
!!!
非常简单!!!只能适合与很小规模的团队应用。还有几个问题需要关注:
1、问题单 的质量无法保证。
2、问题单 缺乏有效管理、分配。
3、有争议的问题单 最终如何裁决?
4、如何保证开发人员的修改质量 我们的流程是:
Tester登记Bug --> 项目经理确认、分发Bug --> 项目经理与Bug修改者讨论修改方案,同时测试经理与测试员讨论修改后的复查方案-->项目组内修改结果确认 --> Tester复查Bug --> 。。。。。 不能说楼主是错的!
就是BUG确定没写清楚!
我们公司也存在这样的情况,BUG的确定问题!
但最后有个主裁决人确定!我们公司是技术总监定的!
因为我们负责我们测试的是写需求的不买主管帐哈哈~所以最后只能CTO定!
页:
[1]