3

我还没有找到任何关于 QA 行为准则的好资源，并想开始记录这一点。我遇到的主要问题是非常基本的东西，例如：

  • 当真正的问题是他们正在使用 IE6 并且尚未更新缓存时，有人报告“设计已损坏”。
  • 一位团队成员说您破坏了构建，而实际上他们还没有从源代码管理中检索到最新版本。
  • 有人抱怨当他们导航到某个页面时他们的数据丢失了，但没有解释他们是如何到达那里的。

我真的很想要一份文档，当他们下次抱怨“这段代码很糟糕”时，我可以将其分发给他们，而实际上他们应该说的是“这段代码没有实现我们的业务目标”。

4

6 回答 6

5

这听起来更像是一个人际问题，而不是技术问题（也许最后一点除外）。

如果你觉得人们彼此不礼貌和不尊重，有很多解决方案（咨询、辅导等），但应该将其视为社会问题，而不是技术问题。

如果这是投诉者的一个简单错误，那么某种内部培训可能会有所帮助。不幸的是，我不知道任何好的行为准则。

有一些报告错误的准则，例如：

https://developer.mozilla.org/en/Bug_writing_guidelines

http://catb.org/esr/faqs/smart-questions.html

这些可能是一个起点。但是很多内容将特定于您的环境、软件等，因此您不太可能找到可以使用的东西。

于 2009-06-10T13:23:56.923 回答
2

如果可能的话，花几分钟亲自与某人交谈，否则请通过电话交谈。

只有使用错误跟踪系统的电子邮件才能真正导致双方对问题感到沮丧的这种情况。

你需要从沟通中获得

“这东西糟透了”

至

“当我做这做那然后发生这种情况等等时，我真的很困惑。”

您需要了解人们看到问题的原因和位置，以及哪些小问题可能会给您的测试人员和/或客户带来巨大的挫败感。

您可能还需要帮助他们理解为什么事情会这样。

并且您可能知道存在问题，但现在无法修复，因为这将是有风险的或更重要的问题具有优先权。

于 2009-06-10T14:34:36.390 回答
2

一篇古老的 Joel 文章可能会有所帮助：Painless Bug Tracking，其中：

记住一个好的错误报告的规则是很容易的。每个好的错误报告都需要三件事。

  1. 重现步骤，
  2. 您期望看到的，以及
  3. 你所看到的。

看起来很容易，对吧？也许不吧。作为一名程序员，人们经常将错误分配给我，因为他们遗漏了一个或另一个。

于 2009-06-12T12:32:58.023 回答
1

这里有一些很好的答案。我们知道在一个好的错误跟踪数据库中我们需要什么。这些相同的功能，适当地运用，有助于教育错误报告者。

这就是良好的错误数据库审核的用武之地。错误应立即进行限定和分类。所有丢失的数据都应归还给用户，如果未提供，则暂停该错误。一个月没有数据，对用户来说不重要，Bug 报告已关闭。

当客户看到他们的 bug 很快被优先级降级（“偶尔只影响一个客户”）、被边缘化（“无法重现”、“提供的数据不足以识别”）、被边缘化（“等待丢失的信息”、“重新分类”），等等，他们很快就会意识到他们必须站起来打球。提供更多和正确的信息，否则它会排到最后，然后在下一个次要版本中完全消失。

用户的琐碎、刻薄的评论永远编码在错误数据库中。礼貌的响应，或者更好的是，自动化的响应是开发人员方面唯一的事情。每个新的数据输入都由人工处理，并带有感谢和错误状态的变化。

当然，他们会抱怨正确报告错误所需的努力门槛。他们会抱怨优先级。他们会抱怨在超时后或在下一个软件版本中关闭错误。你只是耸耸肩说，如果这很重要，他们会和你一起工作，给你你需要的东西。

如果他们想要报复，他们可以通过不断重现问题并输入更多相关数据来保持漏洞。然后，您将拥有修复错误所需的东西。

于 2009-06-12T13:08:15.737 回答
1

我很困惑——当你说 我真的想要一份文件时，我可以在客户或团队成员下次抱怨“这段代码很糟糕”时分发给他们，而实际上他们应该说的是“这段代码没有完成”我们的业务目标”。
有什么不同？术语？代码很糟糕或没有完成，甚至更糟糕的是不使用它或为它付钱给你，失去客户导致人们认为，与其担心他们怎么说，重点应该是如何真正将代码/应用程序带到它应该在的地方以获得更积极的回应。很高兴他们正在提供反馈，而不是无视您/您的陪伴。尽可能获得所有负面反馈，

于 2009-06-12T12:24:51.940 回答
1

虽然像“这不起作用”这样的错误报告确实不是很有帮助，但您必须意识到并非每个人都是程序员。

大多数“抱怨”的人根本不知道他们可以提供哪些信息来更有帮助，并假设您知道他们在说什么。他们也经常不知道自己的“语气”，因为他们并不总是习惯于精确的书面交流（即使是经理类型也可能公然无知——程序员 OTOH 往往是完全的狂热分子，因为他们习惯于在一小段文本中紧密包装语义，因为这就是他们的谋生手段）。

你需要解释你需要知道什么才能理解一个错误（即能够重现它或追踪它）。如果像 Mozilla 这样的指南出现在错误跟踪系统中，它们会很有帮助。如果您的错误跟踪系统主要由 QA 向您发送愤怒的信件，那么您可能会通过亲自与他们交谈并向他们解释如何在他们关心的情况下提供更多帮助，您可能会做得更好。

如果他们不在乎，那你就完蛋了。

于 2009-06-12T12:37:44.360 回答