我无法找到有关QA行为准则的任何好资源，并希望开始记录这一点。我遇到的主要问题是：
我真的很喜欢下次他们抱怨“这段代码很糟糕”的时候我可以发给客户或团队成员的文件，而实际上他们应该说的是“这段代码无法实现我们的业务目标”。
答案 0 :(得分：4)
这听起来更像是人际关系问题，而不是技术问题（除了最后一点）。
如果你觉得人们彼此不礼貌和尊重，那么有很多解决方案（咨询，辅导等），但这应该被视为社会问题，而不是技术问题。
如果对投诉人的一部分是一个简单的错误，某种内部培训可能有所帮助。不幸的是，我不知道任何良好的行为准则。
有一些报告错误的指导原则，例如：
https://developer.mozilla.org/en/Bug_writing_guidelines
http://catb.org/esr/faqs/smart-questions.html
这些可能是一个起点。但是很多都是针对你的环境，软件等的，所以你不太可能找到可以使用的东西。
答案 1 :(得分：2)
如果可能的话，花几分钟与某人亲自交谈，或者通过电话与他人交谈。
只有使用错误跟踪系统的电子邮件才能真正导致双方对此问题感到沮丧的这种情况。
您需要从
级别的沟通中获得'这件事糟透了'
到
'当我这样做时，我真的很困惑，然后发生这种情况等等。'
您需要了解人们看到问题的原因和位置，以及哪些小问题可能会给您的测试人员和/或客户带来巨大的挫败感。
您可能还需要帮助他们理解为什么事情就像他们一样。
并且您可能知道存在问题，但现在无法解决，因为它会有风险或更重要的问题具有优先权。
答案 2 :(得分：1)
一篇古老的Joel文章可能有所帮助：Painless Bug Tracking，其中：
很容易记住规则 一个好的错误报告。每个好的bug 报告正好需要三件事。
- 重现的步骤，
- 您期望看到的内容，
- 你看到了什么。
看起来很简单，对吗？也许不吧。作为一个 程序员，人们经常给我 他们遗漏了一件或者 另一个。
答案 3 :(得分：1)
虽然像“这不起作用”这样的错误报告确实不是很有用，但你必须意识到不是每个人都是程序员。
大多数“抱怨”的人根本不知道他们可以提供哪些信息更有帮助，并假设您知道他们在谈论什么。他们也经常不知道他们的“语气”，因为他们并不总是习惯于精确的书面交流（即使管理者类型可能会明显地忽略这一点 - 程序员OTOH往往是狂热分子，因为他们已经习惯了在一小段文本中紧紧包装语义，因为这是他们为生活所做的事情。）
您需要解释您需要了解的内容才能理解错误（即能够重现或追踪错误）。像Mozilla这样的指南如果存在于bug跟踪系统中会有很大的帮助。如果您的错误跟踪系统主要由QA向您发送愤怒的信件，那么通过实际与他们亲自交谈并向他们解释如果他们关心他们如何更有帮助，您可能会更好。< / p>
如果他们不关心，那么无论如何你都被搞砸了。
答案 4 :(得分：1)
这里有一些好的答案。我们知道在一个好的bug跟踪数据库中我们需要什么。这些相同的功能，正确运用，致力于教育bug报告者。
这就是好的bug数据库审核的地方。应立即对错误进行限定和分类。所有丢失的数据都应该放回用户的法庭，如果没有提供，则该错误将被暂停。没有一个月的数据，这对用户来说并不重要，错误报告已经关闭。
当客户看到他们的错误被优先快速降级（“偶尔只影响一个客户”），边缘化（“无法复制”，“提供的数据不足以识别”），边缘化（“等待缺失的信息”，“重新分类” “）等等，他们很快就会意识到他们必须站到板块并打球。提供更多正确的信息，或者它们会发送到最底层，然后在下一个次要版本中完全消失。
用户的小气，讽刺的评论永远在bug数据库中编码。礼貌的回应，或更好的，自动化的反应是开发人员唯一的事情。每个新的数据输入都由一个感谢你的人和bug状态的变化来解决。
当然，他们会抱怨正确报告错误所需的工作量。他们会抱怨优先顺序。他们会抱怨在超时或下一次软件发布后错误被关闭。你只是耸耸肩说，如果它如此重要，他们会和你一起工作并给你你需要的东西。
如果他们想复仇，他们可以通过不断重现问题并输入更多关于它的数据来控制错误。然后，您将拥有修复错误所需的内容。
答案 5 :(得分：0)
我很困惑 - 当你说的时候
我真的很喜欢下一次他们抱怨“这段代码很糟糕”时可以发给客户或团队成员的文件实际上他们应该说的是“这段代码是什么没有实现我们的业务目标“。
有什么不同？术语？代码糟透了或者没有完成甚至更糟糕的是没有使用它或者为它支付费用而丢失客户导致人们认为不应该担心他们如何说它而应该关注如何将代码/应用程序实际应用到应该的位置获得更积极的回应。很高兴他们提供反馈，而不是忽视你/你是公司。获取所有可能的负面反馈，客观地查看应用程序本身，并确定使其成型所需的步骤。