思步网

标题: 技术评审问题等级定义？ [打印本页]

作者: cecilia 时间: 2008-4-25 10:42
标题: 技术评审问题等级定义？
在技术评审规范中，（评审报告）问题等级的划分、判定标准、确定方法、确定人等，各位有什么看法呢？
目前将问题等级划分为五个级别：致命级、严重级、一般级、轻微级、建议级。
主要是判定标准不好定义，是按问题造成的直接或间接经济损失来判定还是有什么其它更好的方法呢？

作者: sungubbi 时间: 2008-4-25 10:42
技术评审问题、测试发现BUG、故障等级应该是目前最常用的三大类问题定义。技术评审问题针对开发过程中的方案、需求、设计等质量，BUG针对上线前产品质量，而故障针对上线后的产品质量。除此之外，我们还会在一些管理活动上运用到问题等级定义，例如项目问题的识别与管理、计划评审问题、里程碑评审问题等管理性质的问题。

评审或测试的目的是尽可能地发现产品的问题。评审或问题修改的情况决定了是否能够进入下一工作环节。是不是只要存在缺陷就不能进入下一环节？（如果未修复的是一个建议，或者未修复的是一个严重问题呢？）如果进度受限，是否可以放弃部分缺陷的修复？（放弃一个严重缺陷，还是优先级低的缺陷？）从这两个角度考虑，我觉得我们还是需要就什么是缺陷、缺陷的严重程度、优先级别进行定义。

虽然每个公司每个岗位对缺陷的严重程度定义不一样，但至少应在项目组内达到共识吧，严重等级的定义意味着开发和测试就问题的性质达成共识而减少不必要的纠纷。如果一个产品发现了一个严重BUG、十个建议性BUG，你认为这个产品可以发布给用户吗？如果还有20个中等BUG需要五个工作日来修复，但只有两天时间了，我们要怎么发布给客户？什么情况下是严重、一般、轻微或建议，它们的修复优先级，以及如果它们未得到修复，产品是否予以放行到下一环节，都应该得到明确。

技术评审问题也应该要有一定的严重等级，由技术评审小组来确定具体等级和修改要求。依据评审发现的问题，你也许会得到评审的结论：需再次评审、评审通过或稍做修改确认即可。问题的严重性决定了评审的结论。

作者: cecilia 时间: 2008-4-25 13:41
标题: MSN群讨论内容整理
今天早上在MSN群里主要有以下几种观点：
1、缺陷没必要区分严重程度，因为缺陷并不只有这一个属性，还有优先级等。不同的人对缺陷的严重程度的理解不同。比如测试人员认为一个不明确的操作说明会引发系统崩溃，那她就认为这是致命的，但开发人员就认为这只是文档类说明的问题，只是一个提示性的问题，而对于客户来说可能会觉得这个无所谓，因为他不会去看。以上三种情况的发生还在于问题发生的阶段，比如开发阶段、测试阶段以及系统发布后。
2、如果缺陷的严重程度与测试员及开发人员的绩效挂钩，那势必会造成开发和测试员为了一个问题到底是致命还是严重、一般等而吵得面红耳赤。（这里又扯到绩效考核的事了，还是下次专门讨论这个好了。）
3、严重程度的划分应该以缺陷为主，按照缺陷的属性来划分。（每个公司定义BUG的严重级别和优先级别都是不同的）

希望大家能积极讨论，多多发表意见或建议。

作者: cecilia 时间: 2008-4-25 18:28
标题: 问题的分类
在此，只要一提到问题，我想大多数人想到的都是测试过程中发现的BUG，然后再定义其严重级和优先级。
我这里提到的问题主要有以下几个方面的：工作成果技术评审中所发现的问题，公司发生的一些质量事故（可用金额的损失比来衡量），例会安排的事情（作为问题来说可能会不妥，但应该也这么来定义严重级别），还有就是测试过程中发现的缺陷（这个在其它的帖子上也都有描述，严重级及优先级的定义，需按公司实际情况来定义）。
原先主要是按金额的损失比来定义，可是有大部分问题根本就无法预计其损失。这一个问题的严重级别应该由谁来确定呢？是技术评审的主持人还是记录员还是审核员？
希望大家能不断补充，并发表意见或建议。

作者: cecilia 时间: 2008-4-27 17:48
怎么都没人来讨论呢？感觉人气不够旺哦。版主呢？

作者: cecilia 时间: 2008-4-28 11:52
1、在评审会议上对问题的严重级及优先级达成共识，确实可以定义技术评审问题的等级，此时也可由记录员在评审报告上填写（记录员在评审会议结束前将记录的需修改的问题向评审参与人员汇报，避免遗漏，同时寻问其严重等级及优先级）
2、这样的话还是缺少一个规范，根据什么来界定问题的严重等级及优先级，因为每个人对问题的分析都不同，也就会有不同的答案。如果有相应的规范，那大家就都会从这些方面去考虑。比如按金额损失大小，问题本身对项目进度、成本、工作量等的影响等方面进行考虑。

希望大家能多提意见。如何定义问题等级的规范？

作者: Scott 时间: 2008-4-28 12:21
现在无论是用JIRA还是Excel来做，其实对于缺陷管理都没有一个完整的解决方案。这里存在的几个问题，有些东西是重复的，比如从严重性级别看缺陷或者从影响程度看缺陷看到的基本一样；有些东西是没必要的，比如缺陷排除阶段，有的公司是写的不正确，有的是写了没什么作用。

我这里只给大家推荐一个IBM的ODC（缺陷正交分类），感兴趣可以研究一下，当然它要做一定的修改，毕竟当年的ODC很现在可能存在不适用的地方：
ODC official website：http://www.research.ibm.com/softeng/ODC/ODC.HTM
ODC(Orthogonal Defect Classification)简介 http://www.ibm.com/developerworks/cn/java/j-odc/

作者: jiayan2000cn 时间: 2009-1-17 22:47
学习一下！

作者: 奔放洋气吴世勋 时间: 2014-8-14 12:08
向楼主学习

作者: 一个芣咋 时间: 2015-12-22 20:05
我是个凑数的。。。

欢迎光临思步网 (http://www.step365.com/)