软件测试人员应该如何做才能使开发团队变得更有价值和更有帮助？

Question

当我编写详细的缺陷描述或错误报告时，我的团队开发经理会感到满意。黑匣子测试人员能做些什么来帮助开发人员更高效地解决缺陷呢？

我观察到一件让我的开发团队担心的事情是，我在产品发布前一周和代码被冻结之后报告了重要的bug。

另外，当我在新构建中重新测试一个bug修复并失败之后，在第二次被开发人员修复之后，我再次发现了同一个bug的症状，我错过了这个症状，并且应该更早地找到它。

我注意到Dev团队并不欣赏这些东西，因为他们总是把发现的错误推迟到下一个版本，难道我在这里是无效的吗？

因此，好的和有经验的开发人员真正期望QA团队做什么？我们测试人员如何为在同一个项目团队中工作的开发人员创造更多的价值？

Answer 1

从这个角度考虑测试人员的角色是非常令人钦佩的。

冷酷的事实：

• 当他们的代码中发现一个bug时，没有人会感到高兴。假设自己是一名开发人员，您已经完成了编码，您已经完成了单元测试，并且您在签入代码时感觉非常好。当有人在代码发布前不久出现并告诉你你的工作不够好的时候，你会有什么感觉。
• 对于开发人员来说，防御性是一种常见的反应；防御性思维有两种表现: 1，它不是一个bug；2，测试人员可以更早地告诉我。

测试人员如何处理这种情况？

您提到在代码发布和/或代码冻结之前不久就发现了bug，您的开发变得非常关心。

• 这是不可避免的；当您发现一个bug时，您无法完全控制它。在冻结或标记代码以供发布之前，请咨询您吗？在冻结或标记代码以供发布之前，应咨询测试人员。如果不征求您的意见，您应该提出更改它的建议。是的，在某些文化或公司中，它是不可能改变的。(您的发布管理可能没有很好的组织，但是没有进一步的细节，这只是我的推测。)

您提到，当您发现同一个bug的新症状时，您的开发团队并不欣赏您作为测试人员的有效性。

• 它可能是不同的bug，也可能是部分修复的错误。如果这是一个新的错误，那么找到它是你的功劳，你完成了你的工作。如果正如开发人员所声称的那样，同样的错误只是部分发现，因此部分修复，这并不意味着您没有做好工作。记住，不可能发现所有的bug。每个人都错过了什么。解决方案是改进与开发人员的沟通方式。
• 指出他们的代码中存在一个bug的一个有效方法是将这个坏消息夹在两条好消息中。例如，当一个bug被发现时，马上去找你的开发人员，开始对话时说:我喜欢你的代码，它的工作做得很好。当您的开发人员不处于防御模式时，请将bug提出来，然后恭维一下以结束这段对话。随着时间的推移，开发人员不会认为你是他们的死敌，而是一个帮手。

我想澄清一个问题：

• 当我编写详细的缺陷描述或错误报告时，我的团队开发经理会感到满意.，您将您的错误报告直接发送给谁？拥有这段代码的开发人员还是你的经理？我见过经理在QA和Dev之间造成不必要的延误和误解。理想情况下，错误报告应该直接发送给它的开发人员，当然，在一些公司中，管理人员希望首先阅读这些报告，这样他们就可以进行优先排序等等。

Answer 2

使测试人员变得更有价值和帮助开发团队.

专注于在流程的早期帮助开发人员--

在此过程中，要更早地关注增值。专注于在编写代码之前和编写代码时与开发人员合作，而不是在测试/准备环境中部署代码之后。这将有助于将您的角色从一个评论家转变为一个助手。

实现这一变化的实际方法：

• 参加短跑计划会议，并在会议中就质量问题提供投入。
• 维护目标受众使用的各种浏览器和移动设备，以便QE或开发人员能够根据需要使用它们。
• 参加起立，听一听你认为会从QA /测试中受益的票，然后找出有票的开发人员，并要求与他们配对。
• 确保您有管理支持，以便更早地与开发人员一起工作。通常，这意味着您向开发总监报告并得到其支持，而不仅仅是首席程序员、架构师或编程团队组长。
• 通过午餐和学习、演示和演示，宣传质量保证/质量工程。
• 在正式的代码拉请求发布之前，而不是之后，请提供输入。
• 继续发展你的实用技能。如果您有能力：，您将得到开发人员的更多尊重。
  • 搜索和解析服务器日志
  • 执行SQL查询
  • 浏览并理解源代码

• 继续发展你的技术知识
  • 程序设计原则
  • 质量工程原理
  • 用户体验、可用性和可访问性
  • 设计原则

我是一名前开发人员，以上所述反映了我的经验。

一旦我最终完成了代码，就会听到QA的消息，这是相当令人讨厌的。让他们通过测试计划工作，或者在现场发布移动设备或IE浏览器，查看仍在进行的开发，这对我很有帮助，也更受我的欢迎。

Answer 3

从开发人员的角度来看，

我是一个自由开发人员，因此，我与许多不同的QA设置工作。从一个测试所有东西的人到一个完整的团队来检查其他人的工作。我通常不是唯一的开发人员，就是处于“管理”型职位(开发经理、领导开发人员等)。我只提到这一点，因为知道“岛的哪一边”是很重要的。

首先，也是最重要的QA起着至关重要的作用。我能写出很棒的代码。但是，我只能编写代码来理解我正在试图解决的问题。如果QA什么也不做，只是提供了一个不同的思维定势，那么它们的价值已经是天文数字了。

下面是一些你作为QA“人”可以做的事情，它们确实会有帮助。

• 要明白，你不是一个释放的路障，而是沿着这条路迈出的一步。我见过太多次QA“人”醉醺醺的权力，并“阻止”一个版本，因为一个错误或问题。有时会发生这种情况，但更多的情况不是识别问题，然后阻止发布。特别是在短发布周期，列出“已知问题”通常比没有新特性要好。
• 记住，你是一个支持的角色。这个计划对你来说是更好的，毫无疑问，但是你在那里帮助这个项目变得更好。很多时候，QA人员都会觉得自己是王国钥匙的守护者。
• 这不是一个该死的记分板，我经常看到这个。QA的人觉得如果他们发现更多的问题，他们的工作就会做得更好。这导致他们开始发现各种非理性的东西。我收到错误报告说“地址导入”不能工作，因为用户无法上传JPG。我还见过QA人员在文本中每遗漏一个逗号就会提交一个小小的bug。
• 学习使用问题跟踪器，希望与您一起工作的开发团队使用某种问题跟踪系统。我经常看到QA人员没有搜索系统并多次列出相同的问题，或者将问题放在明显的错误位置(就像桌面应用程序类别中的网站问题)。正确使用问题跟踪器将有很大帮助。
• 尽早报告问题，让我们举一个假的例子。星期一和星期二我写新的代码，星期三和星期四专门用于清理和维护。星期五将开始生产。不要等到周四晚上才把600个问题放入问题跟踪器(甚至1)，这已经太迟了。相反，当我在周一编写代码时，您应该测试它。你周四的任务应该进行(在一个完美的世界)“是的，这解决了它”。如果你在周四确实发现了问题，你当然需要提出来，但目标是解决问题，而不是寻找新的问题。
• 在报告问题时，请详细说明，我知道的开发人员不会因为有太多的信息而生气。告诉我们问题，你做了什么达到那里，什么版本，什么分支，错误信息，包括屏幕截图，包括堆栈跟踪，如果你有，以及预期的输出是什么。至少，你应该能够说“当我做X，Y应该发生，但是Z发生了。”我见过太多次QA人员说“它不起作用”或“我有错误”。但这不足以让我做任何事。错误应该是存在的。这是一个好错误还是一个坏错误。
• 很多时候，QA人员会提交一个"bug“，因为一个特性发生了变化，当整个版本的重点都是更改特性时。例如，如果我们说我们想限制上传到2 megs。然后QA需要注意这个变化，当他们的5 Meg文件上传错误时，不要提交错误。您还需要了解次要的更改。在“支持国际电话号码”这一新特性之后，我将看到大量类似于“电话号码导致验证错误”的报告。尝试理解对应用程序所做的更改的原因和效果。
• 当然，在适当的时候问问题。你能做的最糟糕的事情之一就是走到Dev人跟前，说“它应该这么做吗？”你能做的最好的事情之一就是发一封电子邮件，或者聊天，问同样的问题。
• QA人员多次支持开发团队，他们说的话使他们成为dev的敌人。他们不是故意的，但他们都是这样做的。“我正在等待dev来解决地址上传的问题。”那可不好。“我们仍在用地址上传来解决这个问题。”那很好。一旦你说了一些让问题变成“德夫的错”的话，证明它不是问题是一种自然的反应。如果你采取团队的方法，那么德夫就不会“不得不”“把你扔到公共汽车下面”来洗清他们的名声。这是一条出路的问题。可能地址问题是您试图上传XLS而不是CSV。更好的做法是获得一张写着"XLS格式不受支持，尝试导入CSV“的票证，然后才能得到对电子邮件链be的响应"QA没有正确地测试该功能。特性是CSV导入，他们正在用XLS进行测试。这不是一回事。”
• 把你自己想象成更大的团队的一部分，很多时候，QA的人都会把自己当成裁判。那里没有。如果开发是进攻线，那么QA是防守线，他们有不同的目标，但都是同一支更大的球队的一部分。