imicman的个人空间 https://blog.eetop.cn/1518355 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

验证与设计之间的接口管理

已有 608 次阅读| 2016-4-8 21:33 |个人分类:验证杂谈


存在的事实是,验证需要等设计代码出来之后才能实施验证。

接口是待测代码。

令验证人员头疼的问题就是,设计代码的缺陷率。

当然,验证人员无论接手什么缺陷率的代码,都要保证代码验证之后0缺陷。

事实上,验证人员保证代码的0缺陷是很难的,在逼进0的过程中要付出很多时间和精力。

如果设计经过自测,缺陷率低,且缺陷都是很隐蔽的功能的缺陷,那么验证后续的努力是很有效率且有意义的。

如果设计简单自测,深知随意测一测,就丢给验证,验证人员在短时间内提了很多张bug单,花了很多时间和精力在定位和解决例如笔误等bug,势必在缺陷归0的过程中,花费更多人力和时间。

因此,设计和验证之间的代码接口需要很好的管理。

要定义好一个度或者界限或者标准,在达标之后代码交给验证。

达标之后,再出现很多问题,如何惩处。

从管理上看,很难定义这个标准,并在标准之上采取措施。不惩罚不行,不然会滋生设计人员的懒惰,导致验证耗时更长,最终影响的是进度。惩罚太重也不行,搞的设计人员战战兢兢,是否也会为了道标,始终不把代码交出去。且这个标准怎么定,是定百行代码的缺陷个数,还是从模块的大小复杂程度来定缺陷数,一旦定了标准,设计人员是否还会推卸写代码的任务,因为不写代码就不会有缺陷。

烦此种种,很难管理。 我看只能是具体问题具体分析。

在交给验证之前,需要从规则上定义,必须自测充分。
交给验证之后,需要有人关注对应模块的缺陷的趋势,并根据趋势,找到对应负责人了解情况,并决策是否需要再次回到自测阶段,这个时候需要谈话,找到负责人,提出这样多的缺陷率,让我们怀疑设计人员你的能力,就算不追究能力,这么都的简单的问题,让验证人员怎么看设计人员,面子上也过不去,总之,以理服人,设计缺陷多,且简单的缺席很多,设计本身就不占理会被其他人瞧不起。

在代码验证成熟之后,并锁定版本之后,如果出现 bug,这个时候就需要严惩,之前不能惩罚,因为惩罚会带来很多之前讨论的问题。


总之,这个事需要有人管理,应该是项目经理,开发经理,验证经理组成的委员会时刻关注缺陷率,并在合适的时间点采用上述策略。设计的问题,开发经理来谈,验证的问题,验证经理来谈;


一个原则,设计人员应对bug负主要责任,不然呢?放纵设计,如果验证再漏验了,就真是个问题了,如果设计本身就不出错,就一定不会有错误泄漏出来。





点赞

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 1

    粉丝
  • 0

    好友
  • 8

    获赞
  • 34

    评论
  • 访问数
关闭

站长推荐 上一条 /1 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-3-29 10:38 , Processed in 0.017351 second(s), 11 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部