缺陷跟踪管理的一个小问题
请问到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？ 由每个阶段处理缺陷的人操作。 a) When a defect is generated initially, the status is set to "New". (Note: How to document the defect, what fields need to be filled in and so on, also need to be specified.)b) The Tester selects the type of defects:
Bug
Cosmetic
Enhancement
Omission
c) The tester then selects the priority of the defect:
Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error
d) A designated person (in some companies, the software manager; in other companies, a special board) evaluates the defect and assigns a status and makes modifications of type of defect and/or priority if applicable).
The status "Open" is assigned if it is a valid defect.
The status "Close" is assigned if it is a duplicate defect or user error. The reason for "closing" the defect needs to be documented.
The status "Deferred" is assigned if the defect will be addressed in a later release.
The status "Enhancement" is assigned if the defect is an enhancement requirement.
e) If the status is determined to be "Open", the software manager (or other designated person) assigns the defect to the responsible person (developer) and sets the status to "Assigned".
f) Once the developer is working on the defect, the status can be set to "Work in Progress".
g) After the defect has been fixed, the developer documents the fix in the defect tracking tool and sets the status to .fixed,. if it was fixed, or "Duplicate", if the defect is a duplication (specifying the duplicated defect). The status can also be set to "As Designed", if the function executes correctly. At the same time, the developer reassigns the defect to the originator.
h) Once a new build is received with the implemented fix, the test engineer retests the fix and other possible affected code. If the defect has been corrected with the fix, the test engineer sets the status to "Close". If the defect has not been corrected with the fix, the test engineer sets the status to .Reopen.. Defect correction is the responsibility of system developers; defect detection is the responsibility of the AMSI test team. The test leads will manage the testing process, but the defects will fall under the purview of the configuration management group. When a software defect is identified during testing of the application, the tester will notify system developers by entering the defect into the PVCS Tracker tool and filling out the applicable information.
AMSI test engineers will add any attachments, such as a screen print, relevant to the defect. The system developers will correct the problem in their facility and implement the operational environment after the software has been baselined. This release will be accompanied by notes that detail the defects corrected in this release as well as any other areas that were changed as part of the release. Once implemented, the test team will perform a regression test for each modified area.
The naming convention for attachments will be defect ID (yyy), plus Attx (where x = 1, 2, 3. . . n) (for example, the first attachment for defect 123 should be called 123Att1). If additional changes have been made other than those required for previously specified software problem reports, they will be reviewed by the test manager, who will evaluate the need for additional testing. If deemed necessary, the manager will plan additional testing activities. He will have the responsibility for tracking defect reports and ensuring that all reports are handled on a timely basis. 关于究竟谁把bug来置为PostPone,Rejected,Duplicate,我想这个问题应该根据公司的具体情况来处理,不同的公司有不同的规定,所以不能一概而论,首先做为Develope,因为bug涉及到他的切身利益,只要有理有据,由他来做这个操作无可厚非,如果公司有特殊的规定,或者说管理规范,实施了配置管理,评审等措施,那么必须在得到CCB授权后才能实施操作, 不错，rivermen 回答的很详细了 没有“到底该给谁”的概念，在企业中各种流程五花八门，各种流程都可能会存在。
关键的是自己要多思考：哪种更合理？为什么别人这么做？
我上课的时候已经说了，从管理的角度建议这些状态由CCB或者PM来指定，这样对于所有testers提交上来的缺陷列表能做一个宏观上的综合评定。
如果developer来指定这些状态可以吗？当然可以，我只是说这样不好。因为由developer来指定这些状态的做法在不少企业中已经做过尝试，结果就是容易导致扯皮，一个流程在tester和developer之间反复流转。
所以我上课的时候提到了ccb这个概念，对于一个bug的修改与否（fixed、rejected、postpone），应当是ccb去把控的，如果公司没有ccb，那么就由PM去做。总而言之，要有这么一个组织或者这么一个人去统一管理所有bugs。
原帖由 gzj_06 于 2007-3-8 16:20 发表
请问到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？
[ 本帖最后由 songfun 于 2007-3-10 19:05 编辑 ]
关于缺陷的优先级和严重级别
原帖由 rivermen 于 2007-3-9 09:12 发表c) The tester then selects the priority of the defect:
Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error
从这篇文章来看，这段英文描述是有问题的——不能说不对，至少不合理。
优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管理的知识。
为什么这么说呢？
因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。
一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的bug，不大会去了解其他tester所发现的bug，那么在这种情况下，他如何能够决定这个bug被修复的优先级别呢？！
这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题更高效。
其实，这在微软内部就叫做“基于风险的测试”，也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。
http://blog.donews.com/images/blog_csdn_net/dev2dev/ms5-1.jpg
以下是微软公司的缺陷流程（不知道现在做微软外包的公司是否也采用这套流程），给大家参考参考。
Bug跟踪过程
在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：
1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。
2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。
3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。
话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！
当然，一般来说缺陷的严重级别也不是tester“主观判断”决定的，如果公司比较规范的话，会由测试经理、项目经理等组织制订这么一份相关的标准文档，文档是关于对应缺陷严重级别的定义。Tester在测试的时候就根据这么一份文档来决定对应Bug的严重级别。
我下面粘贴某公司的一个《缺陷等级标准》的文档，大家可以看到其中的“E类——测试建议”正是我上课所说的Enhancement。
========================
缺陷严重级别定义:
o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
o 紧急---事件非常重要,并且需要马上给予关注.
o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.
o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.
o 低级---事件不重要,可以在时间和资源允许的情况下再解决.
o 建议性缺陷.
更为详细的划分如下:
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志
o 系统处理未优化
E类——测试建议（非缺陷）
===============================
[ 本帖最后由 songfun 于 2007-3-11 11:05 编辑 ] 各个公司应该会有不同的差异，我以前的公司这些东西一般是TEST LEADER设置的。
页:
[1]
