背景
2015年，我在一个大型团队中工作，负责美化Drupal内容管理系统(CMS)的页面。我之前曾测试过一个使用Django的 CMS，但Django是基于Python构建的。而Drupal运行在PHP上。我触发的每个错误页面，都是一次令人兴奋的新冒险，需要深入研究问题可能出在哪里，以及应该向15名开发人员中的哪一位反馈问题。除了其中一位外，他们之前都没有使用过 Drupal。
团队中的一半成员在纽约布鲁克林办公，另一半成员在哥伦比亚波哥大办公。我们与整个团队主要是通过早上的站会进行沟通。每个小组都会聚集在一个会议室里。大多数人都有机会通过长桌对面的麦克风喊话，努力倾听在另一半球也同样需要大声沟通的同事在说什么。不幸的是，有些人只能听而不能说，直到另一个项目把我们赶出会议室。
想象一下，在这样的环境中，我们之间的沟通和相互信任会是什么情况。
不同的观点
现在想象一下，你是哥伦比亚团队中的一名开发人员。纽约的Elizabeth发现了一个问题，她认为这是一个bug。她在测试你的任务时发现了这个问题，但你对系统了解得不够，不知道这是否是你的问题。团队中还有其他14名开发人员，任何一个人都有可能引发这个问题。
现在再想象一下，你是我的老板，负责公司中几个不同项目的测试人员工作。你想通过Jira了解一下我的工作情况，你搜索了”Elizabeth在过去两周内创建的bug”。你惊讶地发现，在过去两周内，Elizabeth似乎没有发现任何bug。
谈话和我的观点
我老板来找我谈话。他们问我为什么没有发现任何bug。毫无疑问，像我们这样已经延期并超出预算的项目，应该会存在很多bug吧?
我确实发现了一些bug。但我没有在 Jira 中将它们标记为 Bug 类型，而是将它们归类为功能请求。
我注意到，每当我提交一个 bug，就会经历数小时的来回讨论，讨论它是否是一个 bug，是谁的问题，以及争论应用程序的行为是否应该改变。而每当我提交一个功能请求时，总是被迅速采纳，按时完成，而这个时间通常和讨论一个 Bug 所花费的时间相同。
这些问题本身几乎一模一样:
- 我没有提交的bug报告：当我从列表视图进入详细页面时，出现 500 错误。相反，我应该能看到与列表视图中所见标题相对应的详细信息。
- 我提交的功能请求：当我从列表视图进入详细页面时，我应该获得与列表视图中所见标题相对应的详细信息。
相同的想法，相同的代码更改，但在 Jira 中却使用了不同的问题类型。为什么会这样呢？
功能请求具有故事点数。实现功能请求的开发人员为我们创造了一些我们之前所需但没有的东西。在迭代结束时，可以在 Jira 中统计每个开发人员交付的故事点数。（我不认为这与薪酬挂钩，但在公司中，Jira 中可衡量的产出似乎成为了一种社会认可的标准，这也可从我老板的询问中得到证实。）
Bug 没有故事点数。修复 bug 的开发人员在迭代结束时完成的故事点数会更少。他们还必须在第二天的站会上对着会议室的麦克风，大声告诉大家他们无法接手新的故事，因为他们正在修复自己造成的bug。
我的老板听完我的解释后，只是简单地将他们在Jira中的筛选条件从“Elizabeth在过去两周内创建的bug”切换为“Elizabeth在过去两周内创建的功能请求”。
所学到的经验
回顾过去，对于这种使用 Jira 中的数字作为社会认可标准的文化，我还可以挖掘更多内容。不管怎样，我确实认为这次经历让我成为了一个更好、更具合作性的测试人员，专注于修复应用程序，而不是追求功劳/证明自己正确/发现最多的错误。
我喜欢回顾我在这家公司的时光，我认为这是我学习最快的经历。但当我身处其中时，我只知道我从这次经历中学到的是:
- Jira并不能完全展现整个故事。
- 以好奇心或兴奋的态度来处理问题，将会获得比争论更好的结果。
- 修复 Bug 比将其标记为 Bug更重要。
- 保持沟通渠道畅通，以便能够传递信息，可能比特定的信息本身更重要。
