51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2329|回复: 0
打印 上一主题 下一主题

[原创] 也许和缺陷管理有关的一些讨论

[复制链接]
  • TA的每日心情
    慵懒
    昨天 08:12
  • 签到天数: 3446 天

    连续签到: 56 天

    [LV.Master]测试大本营

    跳转到指定楼层
    1#
    发表于 2010-7-15 09:46:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    下面讨论内容在项目管理,本质和软件无关,节选部分内容,全文去看链接。

    zwchen:Bug管理,这两年,我们经历了三个阶段。
    先说说使用环境吧,因为这是决定一管理软件是否适合的最核心条件之一。
    人员 有开发人员和不懂软件的业务人员 问题主要是业务员提出
    距离 原来一年大家在一个办公室 后来IT部和业务部分,距离约1km
    项目 旅游电子商务网站 包括前台和后台 这类网站重业务和用户体验 技术上没难度

    最开始,使用的是Bug管理系统JIRA 用了约一年,基本上是推,业务人员不适应,最后我觉得反馈一个问题很烦琐,自己主动废弃了。
    后来,使用Excel,当然这是为bug管理定制的Excel, 执行一个月就觉得不行,因为问题汇总、截图等不方便,简单问题这样汇报似乎也太累。
    最后,使用Foxmail邮件 用得非常顺,特别是业务部和我们分开情况下。因为邮件有三个特性很受用:抄送人,延迟执行,贴图。
    有些很小并且及时的问题,直接通过QQ完成。
    反正,在我们这个小团队,最后一种方式,直到现在都觉得很适合我们。

    其实,在Bug管理的背后,有一个非技术支撑:信任。我们的重点不在责任界定、责任追究等和权限有关的事情上,我们只关注目标:问题被及时发现、及时解决,以及解决过程中的低成本协作。


    luming:别的不多说,至少缺陷管理上到一定的规模,必须用软件。
    个人觉得阈值是50左右,只要一次提交20以上,在修改、验证、再次出现、新缺陷等等,3 轮后,你就彻底迷糊哪个缺陷到底处理了没有,特别是可能多人测试重复提交缺陷的时候。

    前两天我们就做了一个这样的尝试,去其他地方测试,没有用我们的缺陷管理软件(CQ),直接用excel管理的,我们3个人,后来两个人,最后只有我自己一个人测试一个程序,大约6~7轮,实际缺陷 148,但是中间包括整理、重复等缺陷600+,弄的我很晕。


    zwchen:1、我不否认Bug管理系统的价值,项目到了一定规模,用它有时可以提高问题反馈、跟踪、解决效率。

    2、Bug管理系统也是一种管理软件,所以在上马它之前,一定要给员工培训其“业务”,比如Bug管理系统可以帮大家解决什么什么问题,有什么什么好处;另外,还有告诉它们实施过程中有什么阻力;然后再告诉他们使用流程。
    往往不是Bug系统不够好,而是团队不够规范,比如大家提交问题时马虎、或喜欢口头反馈。

    3、Excel可以做成很适用的Bug管理客户端,通过SVN来团队共享,见附件。

    4、本文的主题是,如何客观看待项目管理软件,偏管理、偏商业、偏宏观;你说的是微观,是问题的另一个方面。
    打个比方,你夸一个MM,你好聪明啊,她回答,难道我不够漂亮吗?



    luming:我们用的excel本身和你附件给的格式差不多啊。
    对缺陷管理这里,我想还是比较有发言权的,51testing的缺陷管理版本人就是版主,也比较关注这些方面的问题。
    这么多年,我一直用ClearQuest,其实就是因为CQ几乎隐藏了所有对开发人员无用的东西。
    zwchen说的很对,开发人员用缺陷管理软件需要培训,这么多年来,我见到的培训最少的缺陷管理软件就是ClearQuest。
    ClearQuest其实配置使用起来是最麻烦的,而且也过于古老,新的软件jira等我不否认比CQ好很多,比如可以把缺陷分配给多人处理。
    但是使用软件需要成本,我个人认为,这个成本最好转移到测试人员而不是开发人员,就是测试配置完毕后,仅仅需要开发人员方便的使用,其他麻烦的事情,都在测试方面,因为主要需要使用此软件的是测试而不是开发,开发仅仅需要了解问题并解决,至于缺陷状态时什么,有多少严重问题,有多少缺陷,什么时候需要修改,开发人员的想法很可能是“关我何事”。
    所以测试人员需要给开发人员设置方便。
    包括TestDirector或jira这样的软件,给开发人员讲解比较麻烦,因为太多的内容不好隐藏,很多时候真的是需要培训才可以的。
    ClearQuest则不然,功能相对强大自由,配置繁琐费时,客户端也比较麻烦,但是web端啥都没有,开发人员想折腾都不可能。
    通常在ClearQuest上我都按照开发人员姓名或模块和状态(等待处理,再次出现)做查询,就告诉开发,你只要点击自己名字的查询,修改里面的缺陷即可,状态选择按照你的处理模式,已经修改、不是缺陷、暂不修改,别的你不用管也不用动,2分钟完事。
    从培训和使用角度,我觉得对开发人员来说,ClearQuest是最简便的。

    Excel也一样,我之所以不想用它,也是同样的思想,麻烦事测试做,开发只需要了解哪个问题需要修改。
    所以每一轮,我都要检查几个人提交的缺陷是否重复,重复的合并。程序员已经修改的问题直接删除,只留下新问题和没有修改的,这样每轮都需要做很多整理工作。最后写总结,把这些中间过程的缺陷文档合并到一起,就觉得很多了(600+整理为148)。

    也许很多人对同样的问题看法也不一样吧。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

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

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-4-28 06:48 , Processed in 0.074337 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表