测试人员与开发人员的沟通

尽管有很多关于开发人员与开发人员，开发人员客户，开发人员团队经理之间的交流的文章，但我找不到任何有关测试人员与开发人员之间的交流和联系的指南的文章。

无论测试人员和开发人员是单独的团队还是在同一团队中（在我的情况下，我是敏捷开发项目中的一个孤独的测试人员），我相信如何看待测试人员对于使测试被良好接受是极其重要的，以实现其提高项目质量的目标（例如，不应将其视为警察部队）。

关于测试人员应如何与开发人员进行交流的任何建议或研究？

更新：谢谢大家的回答。他们都证实了我的想法。就目前而言，我的团队非常乐于接受我的角色，我们最终取得了真正的进步。我可以选择多个答案作为答案，但我必须做出决定。

提高沟通的最简单方法就是一起工作与你的开发人员（设计师和建筑师等），并慢慢打破那些无聊的角色，并最终实现我们所有的测试，但我们中有些人比别人有更多的经验。

对于敏捷，只需“按书”即可。测试人员是团队的一部分，而不仅仅是一些外部实体，您可以在完成后将其移交给他们。您宝贵的专业知识将在整个开发过程中使用。首先，在创建用户案例时，您可以帮助进行验收测试并使它们自动化。这些测试然后由开发人员在他们的工作中使用。您还每天花费时间进行部分和已完成工作的探索性测试，并与PO交谈以不断澄清和改进您的测试。

这就是我谈论“一起工作”时的意思。我完全确定这是团队沟通的方式。这篇文章很好地解释了它。

与此相反，许多组织喜欢通过将所有测试人员（以及DBA，设计师和程序员）放在不同的部门来处理开发。这不利于交流，仅有助于巩固分阶段发展的理念。在这种情况下尝试改善沟通是可能的，但是您可以期望的微小改进是不值得的。至少与实际将人们放在同一房间并创建跨职能团队相比。

我坚信开发人员与测试人员之间的任何交流。

我看过很多次，每支球队之间都发生bun头打架，来回小打小闹（“按设计封闭”，然后“重新开放”等）。

我总是告诉与我合作的测试人员，如果他们有任何疑问，请与我交谈。

我真正讨厌的一件事是，开发人员对测试一无所知，并且对此一无所知，因此，我会尽一切努力与测试团队建立良好的关系。

在交流有关错误和测试的过程中，测试人员应与开发人员非常清楚和准确。重现错误的步骤的详细列表，如有必要，还提供屏幕截图...无法重现的错误或重现步骤不明确的模糊描述将很快使开发人员与测试人员的关系恶化。

我从不相信开发人员和测试人员之间总是存在一定程度的分歧，但是当我最好的一位朋友在我所在的公司担任测试人员角色时，我不得不面对这种情况，令我惊讶的是，他被分配了相同的模块进行测试我正在发展，所以FUN和他一起工作真的很重要，我必须说，在这种情况下了解他人的意见并控制自己的自我非常重要，这对我有很大帮助，我们在专业人士方面树立了良好的榜样。承诺以及个人友谊水平。

既然您说过自己是敏捷环境（假设Scrum）中的唯一测试者，也许可以利用回顾会议作为一个开放的论坛来定义交流过程，这可能是有条理的。

如您所知，回顾会议是为了解决Scrum流程中的皱纹。这些可能是诸如允许开发人员在不中断时间的XY时间内进行的工作，仅在周一通过电子邮件发送通信以及在一周的剩余时间内进行口头表达（无论您的团队是否适合）。沟通绝不是万能的。

作为开发人员，我感谢一位表现出主动性的测试人员。他们不画线...他们希望解决缺陷；不管根本原因是什么。开发人员和测试人员必须将感觉与业务分开。由于涉及人类，因此缺陷是业务的一部分。解决缺陷的最佳方法是组成一个统一的团队来整体解决缺陷。当线条开始浮出水面并布置边框时；沟通会中断。

利用您的每日站立会议。尽可能多地参与其中；不仅包括测试，还包括整个产品。归根结底，开发人员和测试人员正在努力实现一个目标，并且应始终将重点放在目标上。

我更喜欢将测试人员视为同一团队的一部分。在这方面，没有沟通问题。

每当测试人员不得不与开发人员交谈时，或者反过来，让我们聊天。只是日常工作。

但是，双方都必须相互尊重并正确地履行职责。

测试人员需要提供有关错误情况的详尽信息，并且在设计时不要将某些内容报告为错误。尤其是当只需要问那边的家伙有关可疑的看起来像是功能的东西时。

开发人员必须认真对待错误报告并深入调查，如果您没有在五次单击中重现该错误，则不仅要解决问题。

只需要专业的态度。

我发现作为测试人员（SDET）可以利用其来改善开发人员与测试人员之间关系的第一工具是诚实的奉承，尤其是以寻求开发人员指导的形式。

希望与我合作的开发人员比我更好。他们并不完美，或者我没有工作，但是他们比我更了解很多事情。它们是纯粹的开发，而我的注意力部分集中在测试上。我注意到它们做得更好的那些事情，并且我经常提到它们。当我阅读他们的代码时，我会注意到优雅的细节或设计模式的巧妙用法，并在讨论中加以介绍。我模仿开发人员，在可能的情况下使用类似的编码约定，并在适当时（例如，日志记录）将生产中的组件集成到我的测试工具中。我认识到他们的专业知识，因此，他们很高兴认识我。请注意，如果我认为有更好的做事方法，那么我绝对会说出来-但我的目标是提供正面的反馈，而不是负面的反馈，总体。通常，我会尝试使负面反馈更加正式和非人性化（例如，错误报告），而使正面反馈更加正式和非人性化（例如，面对面的交谈）。

给出关于质量的正面反馈以及否定反馈并寻求建议，将这种关系从有争议的转变为关于团队合作和相互学习的关系，并降低了防御能力。开发人员知道他们可以相信我总是说好话多说坏话，所以他们听我说就很舒服。此外，提出关于发展的有见地的问题会提高他们对我的看法，并突破“ SDET是失败的开发者”的刻板印象（至今仍然存在）。

我坚信开发人员与测试人员之间的良好沟通至关重要。至于最好的方法，我敢肯定有很多好的方法，但这是最适合我的方法。

直接/个人沟通！我发现个人交流（而非电子邮件交流）总是效果最好。它允许开发人员和测试人员建立个人关系。一旦有了，一切似乎会更好地运行，并趋于流行。他们永远不会遇到进行特殊测试或为您付出更多努力的问题。开发人员也是如此，我总是花额外的时间来研究他们需要帮助或遇到问题的事物。以我的经验，它可以更快地解决问题，减少浪费的时间。