如何用轻量协作工具做bug管理

摘要：秉持着是骡子是马拉出来溜溜的心态，我注册账号试用了一下他给我的第一印象是简单和，这些团队协作工具一样，也是一款基于的在线管理工具，没有在一开始就让我的安装包恐惧症发作。如何做版本管理第一个要说的，就是目标功能了。

对于一个团队来说，工作效率的高低很大程度上取决于团队的管理。

而作为一名刚接触测试职位的新人来说，如何把一堆堆杂乱不堪的bug管理得井井有条，无疑是最重要的。

我之前一直觉得测试是一份很个人化的工作，每个人有每个人做测试的思路，尤其是编写测试用例，需要大量的自定义字段来充实整个测试体系。在bug管理上，交给任何一个管理工具，我觉得都不如自己手动编辑测试逻辑更加高效。

因此，除了excel，我之前基本没有接触过其他工具。

工作了一段时间，我渐渐发现还是自己太年轻，测试其实是一份非常需要配合沟通的工作。由于excel在协作上实在办法不多，我每次只能把excel文件发给开发妹子们（没错，我们公司的开发都是妹子）。

但excel中的是个整体计划，每个开发负责的部分都是不同的，所以只能在全部信息中寻找自己需要做的那部分，这很难保证不会有遗漏。而计划一旦需要修改，我也很难与她们在第一时间达成同步。因此，很需要找一款能够在不同角色间沟通的bug管理工具。

于是，我将工作内容做了一个汇总，好帮助自己理清bug管理方面的需求：

编写测试用例（经测试，还是excel最好用）

记录并做好版本、功能、优先级相关bug分类

与开发沟通，及时反馈bug完成情况

一些个人的事务管理

带着这些需求，我开始试用bug管理类的工具。

起初，同事给我推荐了几款bug管理类的工具，像bugzilla，mantis，redmine，QC，jira等。但这些工具的使用体验真的很不友好：我连安装都没学会。

你要下载一个安装包，解压，在一群格式不明的文件中寻找一个尾部有.exe的文件，如果有好几个，那么你还要看看他们的名字哪一个更像是安装启动文件了，当然，你也可能根本找不到exe……（血泪史如图）

对我这种软件小白来说，一次安装和配置就要花上好久，还加上各种看不明白的英文。最可怕的是，一旦不能用了还不知道是什么原因，网上各种找解决的帖子，想想都觉得挫败感满满……

随后，我将目标转向了中文化的在线团队协作工具，诸如teambition、worktile这种，希望能用更简单直接的方式解决我的问题。至少，我不用再花时间和exe文件做斗争了！

但tb和wt的问题是，这种以“项目+看板”为基础的管理模式，虽然能够更直观的展现bug的处理进度。但对于测试管理这种动辄1000+的bug量来说，前期制定版本计划会变得非常麻烦。

“使用管理工具的目的不就是提高效率么？为什么会比excel表格还难用？”这是我在试用过一大堆管理工具后产生的最大困惑。

接下来我又试用了几款小众软件，在这个过程中，偶然发现了一款叫做teamin的团队协作工具（这里吐个槽：开始看名字，还以为是teambition的精简版，teamin团队表打我！>_< ）。

秉持着是骡子是马拉出来溜溜的心态，我注册账号试用了一下……

和teambition，worktile这些团队协作工具一样，teamin也是一款基于Saas的在线管理工具，没有在一开始就让我的“安装包恐惧症”发作。

他的界面很干净，没有那么多复杂的功能干扰我，如果不是左侧的菜单，第一眼会让我以为这是一款像evernote、石墨那种类型的文档管理工具。

它创建任务的方式也很像是在做笔记：写完一条任务，回车，开始记录下一条，我觉得这种记录bug的方式让我觉得很舒服。

经过一段时间的使用，我发现teamin的层级结构很特别。它一共分为3层：组织、团队和项目；项目中又分为列表、看板、日历、进展和文件五个模块；“我的任务”和“我的消息”作为个人事务管理独立于项目，信息范围覆盖整个组织；任务可以不断向下创建不止一层子任务。

这个结构纵向和横向的延展度都很好。简单来说呢，就是自由度很高。在这个结构下，我尝试出了一些与其他管理工具不太一样的新用法。

举个栗子来说：

teamin中，“我的任务”支持创建独立于组织之外的私人任务（只有创建者可以查看并编辑），并且可以通过设置任务所属项目与组织内任务进行相互转化。

如此一来，我就可以在自己的任务列表中随手记录下一些问题或是建议，也不会干扰到其他人。而一旦这些东西得到验证，我可以直接将它们转化成任务分配到项目中去。也就是说，记录与管理可以分开来做了。

这一点让我感觉很自在。

无论发现了什么问题，我都可以先记录下来，而不必担心打乱已有的bug清单，之后找个时间统一进行进一步的筛选与管理。这就比以往那种把任务从头设到尾的管理方式轻松多了，优先级设置也更精确……

个人管理的便利性和人性化让我渐渐爱上了这款工具。而且越使用，你就越会觉得，好像所有事都变得得心应手起来……很奇怪，它没有太多限制，也没有太复杂的功能，却很有控制力。

这种让人奇怪的感觉不仅体现在结构上，功能上teamin也秉承了“去边框化，去功能化”的特点，让我可以根据自己的实际需要，快速尝试出适合自己的那套管理方式。

上文提到了我在工作中遇到的一些问题。为了解决这些问题，我渐渐总结出了一套用法，涉及到一些teamin中比较特别的功能，接下来我就与大家分享一下。

1、如何做版本管理

第一个要说的，就是“目标”功能了。之所以把它放在第一位说，就是因为它完美解决了我在其他在线管理工具中一直没有解决的问题——版本管理。

而一开始，对于这个功能的出现我是很困惑的：这样一排tab页一样的东西是用来做什么的？这不是和标签功能重复了吗？（teamin的任务本身是可以设置标签的）

用了一段时间后，当我想要将创建的任务进一步整理归类的时候，突然发现“目标”功能的真正价值……这不就是一个版本管理神器么！

目标是一个独立于项目与任务间的管理层级，不同于标签，它能够带给我管理上更多发挥的空间。对于测试而言，目标非常适合做bug的版本管理。

显示目标后会出现两个默认标签，“全部”和“无目标”。

“全部”就是查看项目内所有bug；而没有被指定目标的bug，会被统一归入“无目标”中，这里我更喜欢叫它“bug需求池”；除此之外，我还需要新建几个目标用来管理具体版本：

调出项目目标，按不同的版本创建好目标，将任务添加到项目中。

进入“无目标”中，将其中的bug分配到各自的版本目标中。

这种方式可以帮助我将冗长的“bug清单”进行瘦身，相比其他管理工具那种上千条bug混在一起的bug表单来说，“列表+目标”这一功能组合无疑是更好的选择。

你想想，当一个开发MM怀揣着以往与测试GG种种工作上不愉快的回忆战战兢兢来到这里时，却遇见了我这样一个如此为她着想，把bug计划安排的井井有条的SunshineTestBigBoy，难免不会产生崇拜之情，难免不会……

哼哼，我才不会让你们发现我的真正意图~

2、如何制定计划、跟踪进展

teamin的第二个功能特点，就是他看板+列表的双模式管理方式。

大家都知道，看板模式的优点就是便于查看任务进度，但却不擅长做整体计划，而teamin是我试用过的所有工具中，唯一拥有列表和看板两种模式的管理工具。

不仅如此，teamin中的列表看板任务信息是互通的。也就是说，我在列表中做的所有操作和修改，都会实时反映在看板中。

这样一来，我可以先在列表中做好计划，再到看版中管理bug进度。两种模式分别对应两种管理需求，使制定计划与控制进度都能达到效率最大化。

除此之外，日历中的任务也是相连通的。

3、如何与开发进行协作

很多时候，测试和开发间最大的问题就是沟通，我们无法即时将bug推送到开发面前，往往过了几个月，查看bug清单时，才发现仍然后很多bug没有被处理过，相信很多测试都遇到过这种问题。

为了能让bug得到及时解决，我一开始的做法是直接将bug提到开发项目中，但结果反而效率更低了。

在与开发妹子交换意见时，我了解到，其实bug与任务放在一起会使项目列表显得纷乱不堪，任务也会变得更难区分。

于是，我换了一种方式，把测试项目独立出来，将bug和开发项目分开，需要在当前开发计划中修改的bug才通过任务跨项目的方式分配给她们。这样的好处是可以防止开发陷入bug的汪洋大海中，可以有条不紊地安排开发的bug修改计划。

当然，想要做到这一点，和任务跨项目协同是分不开的。

其他管理工具在解决跨项目任务协同的问题时，一般都用任务复制，或是任务关联，将一条bug分成两条不同的任务，测试一份，开发一份。但实际上，他没有真正解决信息同步这个问题，即便开发那边完成了bug的修改，测试这里的bug状态也不会随之更新。

而在teamin中，却完全不同。任务可以属于多个项目，也就是说不同的项目共同拥有一条任务，而且支持状态同步。通俗一点说呢，就是心灵感应，你在那边干了什么我都知道哦~

这样的处理方式，最终得到了广大妹子们的一致好评，她们纷纷表示喜闻乐见，人民幸福指数也有了显著提高，朕心甚慰。

讲完了独特用法和优点，我对teamin还有几点小建议。

首先，希望能够添加信息导入导出的功能：之前光是将测试项目搬到teamin中，就花费了我大半天的时间。对于想要入驻teamin的用户来说，这也算是个不大不小的门槛了。

其次，希望能有类似垃圾箱的功能：被删除的项目或团队可以被恢复，以免误删或数据丢失。

总体来说，teamin是一款体验流畅、功能强大的管理工具。虽然略有不足，但同时也给了我很多使用上的惊喜。

而且，它和同类管理工具相比，有个最大的不同点：

我感觉teamin一直在跟着我的思维走，它不会束缚我，让我可以随意发挥、创造。很多需求都能找到很多种解决办法，我只需要在其中选择一个最优的，无须担心它在功能上会不会支持。随着使用的不断深入，又会发现更多让人眼前的一亮的点。

它就像一块七巧板，看似平淡无奇，但当你真正深入其中，却发现它可以凭借玩家的发挥，变换出千种形状。这一点尤为难得，也是我最终选择它的原因。

其实没有什么规定说，bug管理就一定要用bug管理工具，那只是人们的一种固有思维，有时我们需要撕下它们的标签，才能看清我们探求问题的本质。

选择管理工具的唯一标准，是它能否让我的工作提高效率，而非它的标签。

如果大家有什么问题，或是有更好的工具和管理方法，也欢迎一起探讨。