对于一个团队来说，工作效率很大程度上取决于团队的管理。作为测试岗位的新人，如何把一堆乱七八糟的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的简化版。我！>_<）。抱着当骡子当马的心态，我注册了一个账号，试了试……他给我的第一印象是，简单得就像teambition、worktile等团队协作工具。Teamin也是一个基于Saas的在线管理工具。一开始并没有让我的“安装恐惧症”发作。它的界面非常干净，没有那么多复杂的功能干扰我。如果不是左边的菜单，我第一眼还以为它是印象笔记、志摩之类的文档管理工具呢。它创建任务的方式也很像记笔记：写完一个任务，回车，就开始记录下一个任务。我觉得这种记录bug的方式让我觉得很舒服。他有非常自由的经历。使用一段时间后，发现teamin的层级结构很特别。分为3层：组织、团队、项目；项目分为列表、看板、日历、进度、文件五个模块；“我的任务”和“我的消息”作为个人事务管理独立于项目，信息范围跨越整个组织；tasks可以不断地向下创建不止一个级别的subtasks。该结构具有良好的纵向和横向延展性。简单的说就是自由度高。在这个架构下，我尝试了一些不同于其他管理工具的新用法。例如：在teamin中，“我的任务”支持创建独立于组织的私有任务（只有创建者可以查看和编辑），并且可以通过设置任务所属的项目转换为组织内的任务。这样，我就可以在待办事项列表中记下一些问题或建议，而不会打扰其他人。而这些东西一旦验证通过，我就可以直接转化为任务分配到项目中去。也就是说，记录和管理可以分开进行。这让我觉得很舒服。不管我发现什么问题，我都可以先记录下来，不用担心打乱现有的bug列表，然后再找时间进一步筛选和管理。这比以前从头到尾设置任务的管理方式简单多了，优先级设置也更加精准……个人管理的便捷性和人性化让我逐渐爱上了这个工具。而且越用越会觉得一切都变得得心应手……奇怪的是，它没有太多的限制，也没有太复杂的功能，但是可控性很强。这种奇怪的感觉不仅体现在结构上，在功能上，teamin也继承了“去框架、去功能化”的特点，让我可以根据自己的情况快速尝试出适合自己的管理方式实际需要。他如何解决我的问题上面提到了我在工作中遇到的一些问题。为了解决这些问题，我逐渐总结出一套用法，其中涉及到teamin中的一些特殊功能，接下来分享给大家。一、如何做版本管理首先要说的是“目标”功能。之所以放在第一位，是因为它完美解决了我在其他在线管理工具中没有解决的问题——版本管理。一开始我对这个功能的出现很疑惑：这么一行tab页是干什么用的？这不是和标签功能一样吗？（teamin的任务本身可以设置标签）用了一段时间，想进一步整理创建的任务时，突然发现了“目标”功能的真正价值……这不就是个版本管理神器吗！目标是一个独立的项目和任务管理层次不同于标签，可以让我在管理上有更大的发挥空间。对于测试，目标非常适合版本控制错误。显示目标后会出现两个默认选项卡，“全部”和“无目标”。“全部”是查看项目中所有的bug；没有指定目标的bug会统称为“无目标”，这里我更愿意称之为“bug需求池”；另外，我还需要新建几个目标，用来管理具体的版本：调出项目目标，根据不同版本创建目标，给项目添加任务。进入“无目标”并将其中的错误分配给各自的版本目标。这种方法可以帮助我瘦身冗长的“错误列表”。与其他管理工具中成千上万的bug混杂在一起的bug列表相比，“列表+target”的功能组合无疑是更好的选择。想一想，当一个开发MM带着当年测试GG的不愉快回忆，战战兢兢的来到这里，却遇到了对她这么有好感，把bug计划安排得井井有条的SunshineTestBigBoy，难免不会有这种感觉爱慕之情难免不会……哼，我不会让你发现我的真实意图的~2。如何制定计划和跟踪进度teamin的第二个特点是看板+列表的双模式管理方式。大家都知道看板模式的好处是方便查看任务的进度，但是不善于统筹规划，而teamin是所有工具中唯一拥有列表和看板两种模式的管理工具我努力了。不仅如此，teamin中的列表看板任务信息是可以互操作的。换句话说，我在列表中所做的所有操作和修改都会实时反映在看板中。这样，我可以先在列表中制定计划，然后在预览中管理bug的进度。两种模式分别对应两种管理需求，最大限度地提高计划制定和进度控制的效率。此外，日历中的任务也有关联。3、如何与开发协同很多时候，测试和开发最大的问题就是沟通。我们无法将错误实时推送到开发中。通常，几个月后，当我们检查错误列表时，我们会发现许多错误没有得到解决。处理过，相信很多测试都遇到过这个问题。为了让bug能够及时解决，我最初的做法是直接向开发项目提bug，结果效率很低。和开发妹交流的时候了解到，把bug和任务放在一起，项目列表看起来会很乱，任务也会变得更难区分。于是，我换了个方式，把测试工程和bug从开发工程中分离出来。将当前开发计划中需要修改的bug，通过跨项目任务分配给他们。这样做的好处是可以防止开发陷入bug的海洋，可以有条不紊地安排开发bug修改计划。当然，这离不开跨项目的任务协调。其他管理工具在解决跨项目任务协同问题时，一般采用任务复制或任务关联的方式，将一个bug划分为两个不同的任务，一个用于测试，一个用于开发。但实际上，他并没有真正解决信息同步的问题。即使开发端完成bug修改，这里的bug状态也不会相应更新。但是在teamin里面，就完全不一样了。任务可以属于多个项目，即不同项目共享一个任务，支持状态同步。通俗地说，就是心灵感应。我知道你在那边做了什么~这样的处理方式终于赢得了广大妹子的一致好评。他们都表示自己的快乐和幸福指数也有了明显的提升。我很放心。一点建议说完独特的用法和优点，给teamin提一些建议。首先，我希望增加导入导出信息的功能：光是把测试项目移到teamin就花了我半天时间。对于想要入驻teamin的用户来说，这不是一个大或小的门槛。其次，希望有一个类似垃圾桶的功能：删除的项目或团队可以恢复，避免误删或数据丢失。总体感觉teamin总体来说是一款体验流畅、功能强大的管理工具。虽然略有不足，但在使用中也给了我不少惊喜。而且，与同类管理工具相比，它最大的不同在于：感觉teamin一直在跟随我的思路，不会束缚我，让我随心发挥，随心创作。可以找到许多解决方案来满足许多需求。我只需要从中选择一个最好的，我不用担心它是否会在功能上得到支持。随着使用的深入，你会发现更多吸引眼球的地方。它就像一个七巧板，看似平凡，但真正深入其中，你会发现它可以随着玩家的玩转而变化出千变万化的形状。这是特别难得的，这也是我最终选择它的原因。其实并没有什么规定说bug管理一定要用bug管理工具。这只是人的一种固有思维。有时我们需要撕掉它们的标签才能看到我们要寻找的问题的本质。选择管理工具的唯一标准是它是否能让我的工作更有效率，而不是它的标签。如果大家有什么问题，或者有更好的工具和管理方法，欢迎大家一起讨论。
