业精于勤荒于嬉,行成于思毁于随。

发布新日志

  • bug 严重程度 和 优先级

    2012-02-23 17:21:30

    翻译,原文地址:http://geekswithblogs.net/srkprasad/archive/2004/08/20/9961.aspx

    "Triage" is a medical term. It refers to dividing wounded or sick people into three categories: those who will die no matter what you do, those who will recover even if unaided, and those who will recover only if aided. In a situation where there's too much to do, you must concentrate on the third group.

     “伤员鉴别分类"是一个医学词汇.指的是将受伤的或者生病的人分为三类:无药可救必死无疑的人,无需救治自己就ok的人,还有只有接受救治才能恢复的人。假设除此之外还有许多事情要做,你只有全身心投入到救治第三类人中去。


    Bug Triage Meetings (sometimes called Bug Councils) are project meetings in which open bugs are divided into categories. The most important distinction is between bugs that will not be fixed in this release and those that will be

     缺陷分类会议是项目级别的将缺陷分类的一个会议。最重要的是分清楚哪些缺陷要不需要在当前版本修复,哪些需要。


    There are three categories for the medical usage, software also three categories - bugs to fix now, bugs to fix later, and bugs we'll never fix

    在医学上的分类有三种,在缺陷管理上也有三种:现在就要修复的缺陷,之后要修复的缺陷,和不会修复的缺陷。 

    Triaging a bug involves:

     bug分类包括以下内容:


    Making sure the bug has enough information for the developers and makes sense

    确定缺陷相关信息对于开发人员来说足够详细充分,而且合理。

    Making sure the bug is filed in the correct place

    确定缺陷开启在正确的路径(在bug管理工具中,每个缺陷也有路径的)

    Making sure the bug has sensible "Severity" and "Priority" fields

    确定缺陷的严重级别,和优先级正确,合理。


    Let us see what Priority and Severity means

     让我们了解以下什么是严重级别和优先级

    Priority is Business;

    优先级是从公司运营角度(人力配置,资金投入等)

    Severity is Technical

     严重级别是从技术角度


    In Triages, team will give the Priority of the fix based on the business perspective.  They will check “How important is it to the business that we fix the bug?”  In most of the times high Severity bug is becomes high Priority bug, but it is not always.  There are some cases where high Severity bugs will be low Priority and low Severity bugs will be high Priority. 

     在分类会上,团队会根据公司运营角度设置优先级。他们会考虑“我们修复这个缺陷对公司运营有多么重要?”。一般高严重级别的缺陷优先级别也高,但并不是一直都是这样。有时会出现的高严重级别缺陷有第优先级,低严重级别缺陷有一个高的优先级。


    In most of the projects I worked, if schedule drawn closer to the release, even if the bug severity is more based on technical perspective, the Priority is given as low because the functionality mentioned in the bug is not critical to business. 

     在大多数我参与的项目,如果项目截至日期临近,即时有从技术层面看严重级别高的缺陷,但是优先级却不高,这是由于这个缺陷表明的功能问题对整个项目运作不是最关键的。


    Priority and Severity gives the excellent metrics to identify overall health of the Project.  Severity is customer-focused while priority is business-focused.  Assigning Severity for a bug is straightforward.  Using some general guidelines about the project, testers will assign Severity but while assigning a priority is much more juggling act.  Severity of the bug is one of the factors for assigning priority for a bug.  Other considerations are might be how much time left for schedule, possibly ‘who is available for fix’, how important is it to the business to fix the bug, what is the impact of the bug, what are the probability of occurrence and degree of side effects are to be considered. 

     优先级和严重级别是两个很重要的指标对于项目整个开展过程来说。严重级别是从客户角度考虑,而优先级别是从项目运作考虑。设置严重级别很简单。根据一些指导文档测试人员就可以给出严重级别,而在给出优先级别时却要做更多的考量。另外需要注意是“项目周期所剩多少时间?”,“谁还有空能修复缺陷?”,“修复这个缺陷到底对于项目来说有多么重要?”,“这个缺陷会导致什么结果?","出现的频率如何?“,和”修复这个缺陷可能带来的其他问题”这些都是需要考虑的。

    Read the excellent article Arguing Apples and Oranges

     This article clearly explains the how Priority and Severity of the bug given. 

    Some of the above points taken from this article

     (作者一些观点是从 Arguing Apples and Oranges 得来的,也建议大家看看)

    Many organizations mandate that bugs of certain severity should be at least certain priority.  Example: Crashes must be P1; Data loss must be P1, etc.  A severe bug that crashes the system only once and not always reproducible will not be P1, where as an error condition that results re-entry a portion of input for every user will be P1

    许多公司限定了特定严重级别的缺陷优先级的最低值。例如:系统崩溃优先级为P1(最高优先级),数据丢失优先级P1,等等。一个导致系统崩溃的严重缺陷只出现一次而且不易重现,这样的缺陷优先级就不会是P1了,而一个导致用户每次都要重复输入指定内容的判断缺陷则会有P1的优先级。

    Microsoft uses a four-point scale to describe severity of bugs and three-point scale for Priority of the bug. They are as follows

     微软用四个级别来描述严重性,三个级别来描述优先级。如下

    Severity

    ---------------

    1. Bug causes system crash or data loss.

    2. Bug causes major functionality or other severe problems; product crashes in obscure cases.

    3. Bug causes minor functionality problems, may affect "fit anf finish".

    4. Bug contains typos, unclear wording or error messages in low visibility fields.

     严重
    ---------------
    1,导致系统崩溃或者数据丢失
    2,导致严重的功能错误或其他严重问题;
    产品莫名奇妙的崩溃(不易找原因的问题).
    3,导致较轻的功能错误,影响到了易用性。
    4,包含拼写错误,不易理解的词语或者错误的信息在不明显的区域。


    Priority

    ---------------

    1. Must fix as soon as possible.  Bug is blocking further progress in this area.

    2. Should fix soon, before product release.

    3. Fix if time; somewhat trivial. May be postponed.

      
    优先级
    ---------------
    1,必须立刻修复。这个缺陷阻碍了该模块的进度。
    2,应该在产品发布前修复。
    3,如果有时间就修复。可能推迟到之后某个版本再修复。

    Comments and your experience in giving Severity & Priority for bug are welcome.  

    欢迎大家发表对严重级别和优先级有关的见解。

  • 请不要把测试工具当饭吃

    2008-11-10 09:19:21

    (转载自http://www.51testing.com/html/200811/n96974.html)

       近年几年,无论是行业聚会还是猎头招人。无不体现着这一理念,测试工作越发被机械化Coding化,很多企业招人时也不乏喜欢给自己的员工提些要求QTP/Loadrunner/Winrunner/RTF/Rebot一系列测试化工具被列入正规、精益的代名词。于是我们投入了大量人力物力来实现我们心中挥之不去的理想与抱负,每日Build成了很多测试经理追求的梦想。

      加之行业领袖们的吹捧,行业新兵薪水的大幅提升,一些不明真相的人们正大步迈入这个陷阱。我们做测试工具开发、测试工具应用,根本的意义是提升工作效率,降低产品成本,提升团队的核心竞争力。从目前行业来看,很多用人单位和培训机构鼓励大批新入职的测试人员走向测试开发、自动化职业生涯。我们先不论报酬薪资,单从这种不负责任的态度与做事方式来讲,个人觉得这些是不利于新人成长。

      一个入门的测试人员,他应该先做好本职工作,充分了解系统,充分了解需求,能为后续产品提出新的价值关联,能知晓其它同类产品的特点,本套产品的优势,架构特点等等问题。测试工具并不是解决问题的唯一办法,根据产品的测试策略、测试需求很多产品都不能完全按照第三工具的标准进行开发,这也是中国目前的现状。你需要短期内,毫无计划的提需求,解决这些历史问题也是及不现实的。我们能做的是,给新人更宽的思路,更灵活的思维方式,让他们从工具中受益。而不是盲目的使用工具,把一件事变的更复杂。我们提倡的是效率,提倡的是工作效率,并不是代步工作。

      请不要把测试工具当饭吃,而是真正理解测试工具的思维方式和测试方法。在某种层面来说,只有每一个员工、一个团队乃至一个部门,对这种思想有了充分理解的时候。真正意义上的高效才能体现。流程、工具无非只是我们改进工作过程的一种手段,而不是吃饭的家伙。请正视自己的职业,不要把测试工具当饭吃。

Open Toolbar