7

在我的整个职业生涯中，我在 QA 方面取得了不同程度的成功。我承认我可以亲自接受错误报告，但通常当它们以自由形式制作时，其措辞更像是抱怨：“这个过程仍然不起作用！”，没有足够的信息来重现缺陷。

我愿意努力提高对批评的敏感性，但我也对使 QA 流程去个性化并鼓励信息丰富的错误报告的工具和技术感兴趣。目前，错误是通过电子邮件报告的，或者有时通过走上去并用语言来报告。

任何工具都应该是：像啤酒一样免费，易于安装/低管理。我也对如何让自己对错误报告不敏感的博客文章、书籍或文章持开放态度。

4

14 回答 14

10

  1. 获得真正的错误跟踪系统。FogBugz、Bugzilla 等等（我不是 Spolsky 的骗子，但我会说 FB 是迄今为止对我们的测试人员来说最容易使用的系统，而且易于使用对他们来说真的很重要）。这些使得定义 QA 流程和错误报告工作流程变得更加容易。这应该有助于减少您和测试人员之间的个人互动。

  2. 永远不要把它当作个人。通过我们的错误跟踪系统和个人互动，我总是遇到错误。不管他们的语气如何，我总是回答，“谢谢你看到这个，我会调查的”。他们可能今天过得很糟糕，你也可能过得很糟糕，谁知道呢？如果他们没有提供足够的信息来重现，并且他们没有在足够一致的基础上提供这些信息，请参阅#1（获取真正的工作流程并坚持下去）。

于 2009-09-17T13:15:25.507 回答
8

忘记工具。这是关于沟通的。 你需要有纪律的人告诉你到底出了什么问题，他们是如何到达那里的，以及导致事件发生的任何具体条件。当人们写“它坏了”之类的东西时，您还需要能够提供反馈。开发和QA管理需要讨论双方需要什么。

关于敏感性，我发现态度胜过一切。每次看到bug报告，都要抱着“这不是人身攻击，而是解决问题、学习东西的机会”的态度开始。 一旦你确定了你的心态，你的反应就会随之而来。

于 2009-09-17T13:20:16.857 回答
5

我会将工具推荐留给其他人，因为我们使用的不是“像啤酒一样免费”。

您的首要任务确实需要培养将自己从过程中分离出来的能力。这不能是个人问题。话虽如此，尝试与 QA（亲自或通过 CoC）沟通，在错误报告中进行编辑会适得其反（“这个过程仍然不起作用！”，正如你所写，没有帮助）。该过程的目的是提高最终输出的质量。这样的感叹并没有进一步实现这一目标。

于 2009-09-17T13:15:09.210 回答
5

作为一个基本上是开发人员（自动化回归测试）的 QA 人员，我想我已经能够看到这个问题的两面。

正如其他几个人所说，这是一个沟通问题，没有工具可以解决它。 诸如 bugzilla 之类的工具可以提高沟通效率，但它们仍然需要双方努力保持沟通渠道畅通。

我看到开发人员经常难以亲自处理错误，这导致当问题实际上是问题时，将它们视为“不重要”、“边缘情况”、“按预期”等。即使问题实际上并不重要，简单地分享您对修复错误的风险/回报的评估也有助于促进更好的沟通。

相反，QA 人员经常遗漏错误的细节和重现错误的步骤（包括我自己）。当您作为开发人员遇到遗漏的细节时，您的工作是向我们询问更多细节（请及时询问我们）。最糟糕的感觉是当你写了一个错误并将其发送给开发人员，然后几天没有收到任何回复，它被关闭为“无法重现”。

最后，关键是双方的及时和善意的反馈。如果我（在 QA 中）正在与一个开发人员合作，当我向他发送错误时总是回复并且似乎很乐意帮助解决问题，我更愿意花时间向他提供我所能提供的所有细节。

于 2009-09-17T13:48:52.790 回答
3

就像开发人员一样，QA 有（或应该有）要遵守的最低标准。提出问题时，他们需要提供：

  • 一个可重复的测试用例；
  • 截图；或者
  • 问题的描述和任何模式（如果不一致或其他不可重现）。

如果我必须去质检部门询问问题是什么或他们是如何产生问题的，我会很生气。“这不起作用”还不够好。

在我开发的一个系统（Web 报告系统）中，我在每个生成的报告中生成了所有输入数据。当 QA 运行报告并发现问题时，他们可以转到盲 URL 并下载包含以下内容的 ZIP 文件：

  • 报告的定义；
  • 使用的模板；和
  • 任何数据库输入。

在开发方面，我编写了一个工具，可以仅基于该 ZIP 文件重新运行报告。这有几个影响：

  • 如果 QA 提出问题，我可以说“ZIP 文件在哪里？”；
  • 一旦他们养成了习惯，提出问题就容易多了。和
  • 开发人员重现和重新测试问题是微不足道的。

效果是深远的，我认为这突出了一个关键问题：开发人员不喜欢当事情难以测试、难以重现等等时。同样，QA 人员不喜欢任何让他们的工作更难的东西，他们喜欢任何让他们的工作更容易的东西。

因此，我对与 QA 和谐合作的建议归结为：

  • 使用问题跟踪系统。这是绝对的 #1 优先级。一切都需要审计追踪；
  • 有负责 QA 的人负责团队。他们可以解决 QA 提出的问题中提供的细节不足的问题。与其去找每个测试人员，不如去找这个人，让他们按照他们认为合适的方式处理它。一方面，这应该导致一致的标准；
  • 为 QA 提供尽可能多的工具和诊断，让他们的生活更轻松。它也会让你的生活更轻松；
  • 不要根据通过率来评判开发人员或 QA。甚至不要产生这样的统计数据。它们导致了一个对抗性而不是协作性的环境。你们现在（或应该）都在同一个团队中；
  • 在 QA、开发和项目管理之间每周召开一次缺陷会议，以在更宏观的层面讨论最新的、已解决的和未解决的问题。这对于项目跟踪的观点以及总体上了解您可能遇到的任何主要问题或问题区域都很有用。
于 2009-09-17T13:28:39.750 回答
1

在一起解决错误和/或分析错误时，我在 QA 方面拥有绝对最佳的经验。程序员和 QA 工程师都不是最容易相处的人，而且这些群体之间存在一些根本性的紧张关系。

当我对针对我的代码提交的错误报告遇到问题时，请走到他们面前询问它们的确切含义，和/或引导我完成重现它们的步骤。很多时候，问题在于我阅读某些要求的方式不匹配，而他们认为这会起作用。你说话，就像人类一样，不是按照某种公式，然后你们一起解决（同意不同意并让其他人打电话是这里的一种选择）。

在某些 bugtracker 中邮寄或归档的错误报告可能会让人觉得措辞不妥，而且肯定会因为它把矛头指向“你的宝贝”，你的创造。与提交错误的人交谈，您可能会注意到一个共同目标：让世界/软件变得更好一点。

我对 QA 的态度得到了回报，因为它变成了一种相互尊重的关系（尽管我们都不会承认：P），而不是尖叫“不是错误”，我会先走到他们身边。他们不会立即声称某事是一个错误，而是先走到我身边。最后，我们都在做我们的工作。程序员编写软件，QA 工程师在软件中打孔。我非常感谢与一些非常聪明的人一起工作，告诉我我做错了什么。

哦，永远不要使用“这不是错误，而是功能”这样的短语。

于 2009-09-17T13:24:56.880 回答
1

我同意保罗·威廉姆斯的观点。听起来 QA 用来提交问题的流程应该得到改进。电子邮件和问题状态的口头交流表明还有改进的余地。我也同意他的建议，即开发和 QA 共同努力改进流程和沟通。我是一名 QA 工程师，从事这项工作已有 10 多年了。

你听起来很成熟，对你来说是个大道具，因为你不会对任何人大发雷霆。可以写成“它仍然坏了”的意思，但显然 QA 人员需要学习更多机智。

我完全不同意 AnthonyWJones 发送的信息。我意识到每家公司都有自己的文化，但他的回应方式暗示了“把它扔到墙上，QA 负责质量，而不是我”的态度。这没有什么特别的问题，但如果你想营造一个合作和亲切的环境，这也无济于事。更健康的文化是整个开发团队（包括 QA）对质量承担同等责任的文化。

于 2009-09-17T13:36:50.927 回答
1

阅读“和你一起工作就是要了我的命！” 意识到人们只想度过这一天，赚钱，然后回家。“不要为小事出汗。”

于 2009-09-17T13:47:26.950 回答
1

去个性化的工具对我来说似乎是错误的方向。

  • 不要把事情个人化
  • 感谢他们在你的老板或客户发现问题之前发现了问题
  • 尊重测试人员的关系；想想他们在开发过程中添加了什么
  • 用更好的方式表达你的挫败感：

“天哪，这似乎是我们需要修复的一个非常重要的错误。谢谢你找到它，伙计。

我对如何重现它感到困惑。你有什么想法？还是更多信息？”

  • 请记住，您在同一个团队中：

哇，你写的那个错误报告真的很棒。它为我节省了大量的时间来隔离错误。谢谢！

想出去喝杯啤酒吗？啤酒，就像免费的一样？

等等

于 2009-09-18T06:52:27.630 回答
0

我发现处理诸如“它不起作用”之类的陈述的最佳方法是使用类似的简洁问题作为答复。“谢谢，不过你能告诉我更多关于你发现的东西吗？”。然后将球留在他们的球场上。

如果有投诉您没有回复，您可以指出您的请求以获取更多信息。不要做别人的工作，QA 的工作是定义哪些具体不符合他们负责保证的质量。

于 2009-09-17T13:16:03.623 回答
0

你工作的地方有共享点（或维基等）吗？在那里建立一个问题日志供所有人免费查看是很容易的。我不打算讨论跟踪工具的选择，那里有很多。如果您想免费，请查看 SourceForge 或 Codeplex。

最大的帮助是绝对不要把它当成个人 - 他们和你一样做他们的工作。为“可接受的”错误报告设置格式会有所帮助，即使使用您当前使用的电子邮件也是如此。

它们至少应包括：

  • 缺陷性质
  • 严重程度（通常为 1 - 5，其中 1 表示“无法继续”，5 表示拼写错误
  • 重现步骤。
  • 屏幕截图（如果有）。

任何体面的 QA 人员都应该已经这样做并测试脚本。

于 2009-09-17T13:25:37.617 回答
0

尝试让他们更多地参与项目过程。我们定期进行回顾，让 QA 人员与开发人员享有平等的发言权。他们经常提出我们可以改进流程的方法，以使他们的工作更轻松，并让他们更容易确保质量。更重要的是，这些建议经过辩论并（如果同意）被采纳。这使得 QA 和 dev 成为同一过程的一部分，而不是对立。

开发人员对他们的代码负责也很重要。如果 QA 在一个区域中发现了很多错误，那是因为开发人员在编写它时做得很差。这不是因为质量检查很困难。开发团队都应该认识到这一点。

于 2009-09-17T13:33:06.047 回答
0

我不认为工具可以帮助你很多。

要求 QA 写出重现问题的步骤，最好从

  • 运行应用程序
  • 点击 ...
  • 等等

这将构建他们的想法并帮助您理解 QA 想说什么。

于 2009-09-17T13:54:04.757 回答
0

对于作为远程团队成员的我来说，错误跟踪工具是不可避免的。根据我的经验，它们确实有助于“去个性化”这个过程。

于 2009-09-18T07:11:02.497 回答