• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

BUG管理的经验和实践

发布: 2009-9-21 18:02 | 作者: 不祥 | 来源: 转载 | 查看: 283次 | 进入软件测试论坛讨论

领测软件测试网 一. 微软的研发管理分工明确
   研发人员分工明确.主要的三个角色:PM(Program Manager)、Dev(Developer)、Tester三者分工明确,接口清晰,PM来定义需求、书写出每个功能(Feature)特性的设计文档(Spec),Dev写代码来实现这个Spec,Tester来测试Dev做出来的东西是否符合PM定义的Spec,三个角色并无必然的上下级关系,只是分工合作来完成某个功能。

   tuenhai:有一次,tuenhai对项目的需求作了一些说明,PM竟然把我的说明作为需求,就匆匆进行开发……后来实在没有办法,tuenhai只得撤了他。从某种程度上讲,需求比coding更重要。高阶主管参与需求制定是有必要的,但项目经理绝不能因此偷懒,不写需求。定需求要求相关人员交流讨论多次,各方都满意后,才能进行下一步的开发。如果一个PM为了所谓的赶进度,省略需求,甚至省略文档,如此没有大局观的PM,实在是第一天就应该就地免职。

 

  二. Raid 不仅仅是跟踪软件功能方面的Bug,其他各种问题如需求文档的改动,界面上的错别字,帮助文档的遣词造句问题,某项任务指派等等都可以通过一个Bug来跟踪。

   tuenhai:现在公司初创,工作靠自觉,或口头分配,工作过程无记录,工作无法量化考核,这种情况想来就头疼。就一个Bug管理系统,就能提高不少的管理效率。

 

  三. 国内公司对开发这一环节一直很重视,不过需求和测试较弱一点。如果没有很好地对项目或用户需求的真正把握,后面的所有工作都是白费工夫,事倍功半。

  tuenhai:需求的重要,前面已有论述,至于测试,小的团队可能没有专职的测试人员,开发人员有时要兼测试工作。测试有一定的专业性,举一个小例子。开发人员有无测试代码在各个平台各个操作系统的兼容性?有可能开发人员压根不知道要进行这样的测试?没有进行严格的测试,产品怎么可以推向市场,由用户去帮我们测试吗?tuenhai没有正式做过开发或测试,但这些流程还是知道的。种种情况,令人忧心。
   不单是开发,管理上的一些事情也要走类似“需求,开发,测试”的流程。如果把工作不甚严谨的人撤换掉,公司里可能就只剩几个人……

 

  四. 如果你以前没有用过Bug管理系统,那么一开始的时候也许你会觉得这个工具浪费时间,因为一个测试人员要费神把发现Bug的详细步骤记录下来,有时还要贴一张示意图,这一切不如当面说来得直接。
   但是使用一段时间,你们发现BugFree很有用,它忠实地记录着每个问题的处理过程,不断提醒你存在的问题,永远不会丢失和忘记,如果你参与过较大软件项目或产品的研发,就会理解它对软件可持续发展至关重要。

  tuenhai:工作方法和过程比结果更重要。现在公司要以1000w的投入,二年后得到5亿的回报,在做这件大事的时候,如果不重视工作方法和工作过程,tuenhai怎么有信心去做好这件事情。1000w的投入,不是儿戏!公司里不少人因为信任我而加盟,如果我不把公司管理工作做好,又怎么对得起这些朋友的信任?
   公司人虽然比较多,但清醒者有没有?有几个?
   在公司初创期,虽然时间很紧,但不管怎么紧,首先是建立一个高效的管理系统。人有了,管理思想也不缺,但还要一个系统,一个工具来支撑。
   第一步是招人,第二步是管理系统,第三步是做好各种实事。
   web端
Livid,Lexrus碧轩,桌面端yewuyu,明日帝国七猫都是高手,董事长pangshengdong长于商业策划,tuenhai做事还算能抓住重点。作为初创且不出名的公司,拥有这样的人才布局,是相当不错的了。接下来还要引进分类广告的专才和资本运作高手(欢迎与tuenhai联系 tuenhai.com msn:king#tuenhai.com)。
   管理系统,我已经交Livid,Lexus,及BugFree的作者王春生来完成,预计一个月内,他们会给
tuenhai一个完美的答卷。
   管理系统搭建完成后,就要用这个系统高效组织管理。



   五.做好Bug管理,应该是从高层领导到中间层管理人员再到基层人员,都从内心认同其重要性,然后根据自己公司的实际情况制定相关的管理体系和制度,切实执行并逐步形成自己的风格。要实用,不要随波逐流。
  
  tuenhai:我对管理系统的建立是充分认识到其重要性,现在要让所有员工知道我的思考。不可能我一个人去做所有的事情。根据公司实际开发管理系统,更有针对性。可以考虑在BugFree基础上进行开发。或者在员工内部个人Blog上进行功能扩展,加上工作相关功能。

 

  六.当我决定做BugFree时,脑子里很清楚为什么要做,做成什么模样,应该怎么做,做出来后大家怎么用,每个环节都考虑清楚了。这样真正实现的时候就很快了

   tuenhai:也就是需求要非常清晰。对于我们公司现在要做的管理系统,需求还不够清晰。相关人员都都提出自己的方案,然后讨论,脑力激荡。一周或两周的讨论,应该可以定出一个非常清晰的需求。需求定好,项目已经完成一半。

 

  七. 一个好的Bug管理系统要具备以下特征:
   1. 可以完备的记录、跟踪Bug的一生,从出生——创建新的Bug,不断成长——记录相关人员寻找产生Bug原因的讨论过程,发育成熟——找到一个处理办法,同时也允许Bug的复活(问题重现),继续其生长过程。
   2. 方便的查询功能,快速找到你关心的Bug.
  a)最近N个指派给我的Bug
  b)最近N个由我创建的Bug
  c)各处自定义条件的查询

   3. 提供各种Bug的统计信息。比如每个人头上有多少个Bug,到目前为止Bug总数统计,最近一周的Bug曲线图等等。

  4. 方便的项目和模块管理。可以有多个项目,每个项目有多个模块,方便增加、删除和修改。  

  5. 方便的用户管理。作为一个可独立使用的系统,需要能增加、删除用户。

 

  八. 应该用Bug 管理指导原则(guidance)?来替换Bug管理规章制度(rules & regulations)这个词。
  所以我认为Bug 管理就是去制定适合自己团队实际情况的Bug 处理流程和指导原则,制定者(管理层)应该起到真正指导的作用,他们要非常清楚下面这些问题的答案:
    · 我们需要测试什么:哪些软件(网站)、哪些模块
    · 测试人员的分工:什么人负责什么模块
    · 测试工具和环境:巧妇难为无米之炊。你不能安排一个测试人员去测某个模块,而没有给他提供必要的软硬件环境
    · 测试的进度安排:干这一行加班是不可避免的,但是需要有度,人不是机器,长期的劳累谁都扛不住。如果时间很紧,那只能去抓重点,要有所不为
    · 发现一个问题时,如何用Bug 管理工具去创建一个Bug:标题如何写、严重程度、详细重现步骤、错误状况、期望结果、现场附件、这个Bug 去分配给谁
    · 当一个Bug 被处理掉时,测试人员应该如何验证并关闭
    · 当一个Bug 的解决方法有争议时,谁来仲裁
    · 定期的Bug 提醒,比如当前每个人的Bug 情况
    · Bug 状态报告:Bug 数目的变化趋势及我们应该采取的行动
    · 阶段性的总结反馈:哪些地方我们做的好,哪些做的不好,为什么、如何改进
    · … …
  没有这样配套的Bug 处理流程和指导原则,再好的工具都将会是一个摆设、甚至是添乱的工具。就像一个乐队有非常出色的各种乐器,但乐队指挥是个外行(就像成龙电影《双龙会》一个镜头),那么演奏出来的一定会是混乱的乐章。

 

  九. 已经陆续谈过微软的Bug 管理指导原则了,这里系统的总结一下:
    ·管理层要求所有的Bug 都要通过Raid(Product Studio)来跟踪处理。这个看起来很简单的Bug 管理工具是每个员工和其他同事有效协作的重要保证
    ·每个产品都细分模块(Area,SubArea),每个模块都有明确的需求定义者(PM)、开发工程师(Dev)和测试工程师(Tester)这三个角色。一个问题出现了,一定会落实到
某个人的头上去跟踪处理,绝不能出现?无主?的Bug
    ·PM 负责书写的Spec 是这个功能特征(Feature)的?合同?,以此Spec 来指导开发和测试。当Dev 和Tester 就某个Bug 发生争执的时候,PM 负责给出一个明确的说明
    ·测试不仅仅是Tester 的事情,尽管那是他们的专职工作。研发团队中的所有人每发现产品的问题时候,都有义务把这个问题告知负责这个模块的测试人员去记录跟踪这个Bug,或者干脆自己新建一个Bug 来跟踪
    ·你可以创建一个Bug 指派给自己,以跟踪某件事的处理。比如开发人员把源代码中的某处问题用Bug 记录下来,以后抽出时间来进行处理
    ·团队中的所有人都可以创建、指派和更改Bug 的状态
    ·当你创建一个Bug 的时候,描述一定要足够详细,让下面处理Bug 的人和其他关心这个Bug 的同事能够通过Bug 描述准确的重现这个问题,而不是猜测某些步骤或者跑过来当面问你
    ·通常一个Bug 的处理过程是这样的:
     1. Tester 发现一个问题,到Raid 中创建一个Bug,描述这个Bug 的详细信息,比如重现步骤(Repro Step)、错误结果(Result)、期望的改动(Expect)、运行版本等;然后把这个Bug 指派给负责该模块的Dev Lead
     2. Dev Lead 判断后把这个Bug 指派给某个特定的Dev
     3. Dev 处理掉这个Bug 并返还给原Tester,或者请求PM 给出一个澄清说明
    ·管理层通过Raid 来跟踪整体进度,以及每个员工、团队在其中的贡献
    ·有专人定期给相关同事发出Bug 的状态报告
    ·每个人都可以方便的自助查询Bug 的分布处理情况。Bug 管理系统对所有的团队成员都是毫无保留的敞开大门(除了你不能删除Bug,另外所有的操作都被忠实的纪录下来)
    ·随着时间的推移,管理层要逐步给出明确的Bug 解决指导方针:哪些Bug 是可以不理睬的(Won’t Fix),哪些是可以推迟到下个版本处理(Postponed)。比如在最终Build到来前的几周,也许非常严重的Bug,像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
    ·当一线员工出现争执、无法达成一致意见的时候(尽管这种情况不多见),管理层要快速给出处理意见等等。

 

  十. 我所计划的Bug 管理指导原则是:
    ·产品(WAP、彩e 或彩信杂志、网站等)中碰到的所有问题都要用BugFree 来跟踪处理
    ·有一个专职的测试小组
    ·团队中每个同事发现一个问题时,都有义务去告知相关的人员或者直接创建一个Bug
    ·需求、开发、测试三个角色的定位要非常明确。特别的,提出需求的人要把需求认真考虑好、细化成文档,然后才能提交正式开发、测试
    ·发现一个Bug 时,测试人员提交给某个开发小组长,他来负责指派给具体的开发人员;产生争议的时候由需求定义者来出面说明;?矛盾?很大时我来协调和仲裁。Bug 的处理过程都要用BugFree 记录下来:
    ·每天系统自动通知头上有Bug 的人自己还有几个问题。我会检查这些Bug,看到不合适的地方就去添加我的意见
    ·每周系统自动通知所有人前一阶段Bug 的整体情况;同时测试小组要汇总上周的Bug测试情况,告诉团队中所有同事哪些模块容易出问题、主要有哪些类型的问题

  上面这些我能够作为?硬性要求?的,只能是前两条:
    ? 任何人再向开发人员反映问题的时候,开发人员会告诉他们:创建一个Bug 来跟踪
    ? 刚刚成了一个测试小组
  其余的只能融化在日常工作中,管理层不断在很多细节上要求、甚至亲自示范(比如我会使用不同的产品,发现问题上Bug),去教会大家测什么、如何测、发现问题怎么办、Bug 解决后怎么办。

  十一. 关于“数字神经系统”
  让一切可以数字化、文档化的 信息被记录下来,为公司的进一步发展和决策提供基础信息支持。该系统可以用八个字来概 括:数据、文档、自助、自动。其表现形式就是一个包括六个子系统的企业内部网:
   (1). 员工管理系统 - 每个员工都有唯一的UserID,验证密码后方可登录数字神经系统,访 问公司内部信息,查看上下级关系、每个员工的个人公开信息等,此处学习 SharePoint、 Outlook和Exchange中的员工管理和展示;
   (2). 信息管理系统 - 内部的信息发布展示平台,有点象 BBS一样,可发布公司正式通告、 员工也可自由匿名发帖;
   (3). Email系统 - 现在Email的重要性对一个企业不言而喻,我们采用免费Qmail来搭建;
   (4). 文档管理系统 - 一个集中管理公司所有文档(包括研发过程书写的各种文档)的地方, 学习SharePoint中的文档库;
   (5). 源代码管理系统 - 集成优秀且免费的CVS
   (6). BugFree - 虽然网上有免费的Bug管理系统,但是我看后觉得都不好使,和我在微软用 的差别太大,科泰世纪公司的 Bug管理系统【见附录二】倒也很像微软的,但是要花钱买。 于是决定用PHP+MySQL借鉴微软的研发流程和Bug管理工具自己开发一个,以便对我们开发新 网站、声讯软件、客户端软件和公司事务管理中出现的问题进行有效的跟踪处理。

  
tuenhai:有两种表现形式:
   一是Blog的基础上作功能扩展,加上权限,加上评分.
   上部导航是我的一些栏目,每月工作,每周工作,每日工作,工作心得;  Bug管理,网文收藏,我的简历.还可以包括自定义栏目。
     每月工作,每周工作,每日工作帖子作固顶。每个帖子分三部分组成:高阶主管参与的工作计划,工作总结,高阶主管评分。
     每月工作,每周工作,每日工作,工作心得四个栏目本组人都可以看到。其他栏目全公司可以看到。
     Bug管理用来创建Bug,指派任务,整合BugFree的功能。
   右边是一些公共的东东,上部可以是公告区,显示公告或制度等。接着是项目文档,本组成员的Blog地址,我有权限看到的Blog文章等。

  另一种表现形式是如同内容管理系统,栏目和Blog形式一样。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: bug BUG Bug 管理 经验 实践


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网