最近，我在推特上发表了如下内容：
我想要关于这个主题写一篇博文，原因是我强烈的感觉到，我们作为测试者所能提供的价值中，其中一个就是和你的团队一起调查和发现潜在问题的能力。我比较喜欢用‘problem’这个词，而不用‘bug’。下面我将展开讲述为什么这样...
原因1：Bug – 假定我们都是质量把关者。
测试人员不应该成为那个单方面决定什么是bug而什么不是bug的团队成员。我们应该把所观察到的现象或潜在的问题传达出去，并允许团队去调查和决定它们是否应该该定性为一个bug。团队里有多种职位角色，他们都有着不同的技能结构和观点（开发，业务，用户体验等），要让他们来帮忙做出这种决定。
原因2：Bug – 可能无法标明你是在寻求援助。
把某件事情识别为一个bug，并不一定是在向你的团队发出求救或者请求援助。而问题则意味着需要团队参与进来（这也导致了第三个原因）。
原因3：Bug – 可能认为必要的应尽职责已经完成。
当你向你的团队说你的已经发现了一个bug， 那可能会被认为的确是一个bug，也就是说你已经完成了应尽的职责并且不需要更进一步的调查。这样有可能导致错误的bug报告，不必要的骚动（译者注：由于bug报告引起的），或者是完全的浪费时间。让整个团队参与进来可以避免这种情况的发生，而且更重要的是，可以避免它们以后会再次发生。
原因4：Bug – 意味着是需要修改的东西。
这个分类假定它是一个需要修复的问题。但是它确实是吗？你是如何这样确定的？
原因5：Bug – 假定客户也将会认为你发现的这个问题是有问题的
将某件事情称为bug 可能意味着，一个你的产品的现实生活中的用户也会发现你发现的那个问题是有问题的。但是他们会吗？你是怎么知道的？也许你认为的可能是个问题，但是对于他们可能就不是了。如果可以先去搞清楚这件事情吧。
原因6：Bug – 可能会使开发人员沮丧。
将某件事情称为bug可能会使一个团队特别是一个开发人员感到沮丧。我们可以假定这个开发人员漏掉了某件东西或者没能正确的实现。然而，这个问题有可能是源自于糟糕的设计，模棱两可或没有明确的需求， 过时的规格说明书，,糟糕的用户体验，或者是不当的或容易误导人的测试。 相反的，如果你将所发现的标记为问题，就可以使得整个团队一起参与进来进行调查并解决，进而发现问题源头。大家不会指责或者无法正确识别问题的来源。信不信由你，你的团队里有很多人都会跟你一样非常热爱调查问题！
原因7：Bug – 能激励那些有讨厌情绪的人。
我们所做的一个重要方面，毫无疑问是去发现潜在的Bug。但是将某件事识别为Bug，可能会导致团队成员之间产生讨厌情绪。“好吧，你发现了另外一个Bug，将它反馈给相应的开发人员吧。” 这时候你是想让你的团队成员更积极的参与进来的。我发现当我将某件事识别为一个问题时，整个团队都想知道是什么而且想要参与进来。相反的，如果我说我发现了一个Bug，那些与该问题无关的团队成员就不会有同样程度的参与度和好奇心。要保持好他们的好奇心和参与度！
这并不是说你不应该提出Bug。当然，还是有很多可能很明显的Bug的。但是请尝试养成习惯将所发现的任何问题标记为问题、潜在的问题或者发现的东西，并且标记下你的团队的参与级别（engagement level）。希望他们都能及时处理。如果他们看起来好象没有行动，请不要以质量检验把关的名义去胁迫他们。
一直保持这样，直到能起作用。
