存在的事实是,验证需要等设计代码出来之后才能实施验证。
接口是待测代码。
令验证人员头疼的问题就是,设计代码的缺陷率。
当然,验证人员无论接手什么缺陷率的代码,都要保证代码验证之后0缺陷。
事实上,验证人员保证代码的0缺陷是很难的,在逼进0的过程中要付出很多时间和精力。
如果设计经过自测,缺陷率低,且缺陷都是很隐蔽的功能的缺陷,那么验证后续的努力是很有效率且有意义的。
如果设计简单自测,深知随意测一测,就丢给验证,验证人员在短时间内提了很多张bug单,花了很多时间和精力在定位和解决例如笔误等bug,势必在缺陷归0的过程中,花费更多人力和时间。
因此,设计和验证之间的代码接口需要很好的管理。
要定义好一个度或者界限或者标准,在达标之后代码交给验证。
达标之后,再出现很多问题,如何惩处。
从管理上看,很难定义这个标准,并在标准之上采取措施。不惩罚不行,不然会滋生设计人员的懒惰,导致验证耗时更长,最终影响的是进度。惩罚太重也不行,搞的设计人员战战兢兢,是否也会为了道标,始终不把代码交出去。且这个标准怎么定,是定百行代码的缺陷个数,还是从模块的大小复杂程度来定缺陷数,一旦定了标准,设计人员是否还会推卸写代码的任务,因为不写代码就不会有缺陷。
烦此种种,很难管理。 我看只能是具体问题具体分析。
在交给验证之前,需要从规则上定义,必须自测充分。
交给验证之后,需要有人关注对应模块的缺陷的趋势,并根据趋势,找到对应负责人了解情况,并决策是否需要再次回到自测阶段,这个时候需要谈话,找到负责人,提出这样多的缺陷率,让我们怀疑设计人员你的能力,就算不追究能力,这么都的简单的问题,让验证人员怎么看设计人员,面子上也过不去,总之,以理服人,设计缺陷多,且简单的缺席很多,设计本身就不占理会被其他人瞧不起。
在代码验证成熟之后,并锁定版本之后,如果出现 bug,这个时候就需要严惩,之前不能惩罚,因为惩罚会带来很多之前讨论的问题。
总之,这个事需要有人管理,应该是项目经理,开发经理,验证经理组成的委员会时刻关注缺陷率,并在合适的时间点采用上述策略。设计的问题,开发经理来谈,验证的问题,验证经理来谈;
一个原则,设计人员应对bug负主要责任,不然呢?放纵设计,如果验证再漏验了,就真是个问题了,如果设计本身就不出错,就一定不会有错误泄漏出来。