摘要
测试人员和开发人员之间的关系常常很紧张。 各方对另一方应该知道和做的事情有一定程度的期望，而对另一组必须工作的约束，条件和要求知之甚少。 但这不必是这种方式。 做出一些更具体和有用的反馈的努力可以大大改善态度。
内容
大家都知道猫和狗不相处。我对此的较不科学的解释之一是，这都是关于不良沟通的。当狗摇尾巴时，它说：“一切都很酷；让我们一起玩。”但是就猫而言，狗说的是：“当心！我真的很生气！”
并不是说我要称呼任何人为狗（或猫），而是开发人员和测试人员之间的关系通常也同样紧张。团队发展成为团队认同的一种自然的“我们对他们”的心态。但是有时候，它会不适当地轻视另一个团队所做的工作和努力。
我认为这种情况至少部分是由于沟通不畅造成的。各方对另一方应该知道和做的事情有一定程度的期望，而对另一组必须工作的约束，条件和要求知之甚少。对一个团队的工作如何影响另一个团队的工作缺乏了解，加剧了已经存在的紧张局势。
这可能导致一个团队对另一个团队失去耐心，并感到他们是失败的原因。一旦形成这种情感，这就是失去相互学习机会的一种捷径。
例如，假设我们的测试人员团队得出的结论是，开发人员编写不清楚的设计文档的原因是，他们只是不关心需要阅读和使用这些文档的任何人（即我们）。结果，当我们收到另一份写得不好的文档时，我们一直在互相抱怨，而不是尝试与作者合作以提高他们的写作技巧。同样，当开发人员拒绝声称自己没有提供足够详细信息的错误时，我们只会将该人标记为懒惰的人并且会玩一些时间，而不仅仅是干活并修复错误。
但这不必是这种方式。付出一点努力就可以大大改变这种态度。这是我的两个故事，可以教给我们一些知识。
一位开发人员给我写了一封长信，抱怨我的团队提交的错误报告质量低下。基本的主张是所提供的详细信息不够，缺乏复制步骤，而且我们不良的报告能力使他浪费了很多时间。到目前为止，没有什么新鲜的东西。如果您在测试上工作了足够长的时间，可以确保您也至少收到过一封这样的信。
其余的部分使这封信与众不同。开发人员详细解释了造成他浪费时间的原因以及错误报告中的哪些更改可以节省时间。他指出了测试人员希望他采取的一些基本调查步骤，以找出问题所在。他展示了所提供详细信息的微小变化将如何使他避免走错方向，为什么我们引用的测试脚本无法在他的计算机上运行（以及如何解决此问题），以及为什么难以复制使用错误报告中的步骤查找错误。这种口气不是“看你做得多么糟糕”之一。相反，它是“请理解您的工作对我的工作的影响，并利用此知识在将来做得更好。”
除了信中的细节很有洞察力并且可以在错误报告培训中使用这一事实之外，这还使我们对这位特定的开发人员更加赞赏。与其撰写令人讨厌的“如果您有任何想法如何编写适当的错误报告，我们都会过得更好”，而是他努力详细解释了我们报告的弱点，它如何影响他的工作以及什么可以防止或减轻问题。他还格外小心，以确保不仅细节正确无误，而且语气也是我们愿意听的。自然，我们继续听取这位开发人员的意见。
将此视为我们的分歧：如果开发人员所做的事情打扰了我们，我们可能会惹恼，抱怨并永久保留开发人员的形象，因为他们根本不关心质量。或者我们可以反思问题出在哪里，以及它如何对我们的工作产生负面影响。它不需要大的操作。我们每个人都可以做很多事而无需做任何仪式。它所要求的只是愿意放弃通过发送苛刻的信息而获得的立即满足。相反，要花一些时间和思想指出可以修复或改进的问题。
作为工作的一部分，我阅读了很多体系结构，设计和测试文档。其中许多内容难以理解，不是因为技术含量高，而是因为它们的编写方式。它们充满了复杂的短语，可以以多种方式理解的句子，以及在命名对象方面缺乏一致性。
一种选择是叹息并接受这就是事实。另一种方法是写一个模糊的注释：“不清楚”。我经常使用的第三个选项是解释令我烦恼的文字以及为什么我认为需要对其进行修改。
这需要很多时间，主要是因为这意味着我要写更多评论：不仅是与内容相关的评论，还包括社论评论。我将解释现有的措词如何理解为说不同的话，或者由于缺少一些关键信息而根本无法理解。如果文字与文档中其他地方所写的内容相抵触，请参考该部分内容或提供引用。当用复杂而复杂的方式写东西时，我会尝试提供一种替代的方式来表达同一件事。这通常意味着要写，编辑和重写几次，直到我满意为止。
我在所有这些方面的目标是帮助作者提高写作水平，而不是仅仅提供负面评论。有时结果是作者确实对文档进行了改进。希望它对他们的写作技能有持久的影响。当然，在某些情况下，所有社论评论都将被忽略，而在某些罕见而令人满意的情况下，实际上有人会说谢谢。相反，当我碰巧得到一份写得很好的文档时，请务必感谢作者并向他们的经理表示赞赏。
当您在工作的任何方面都采用这种建设性的途径时，反馈都必须非常具体才能有效，因为接收反馈的人可能具有与您不同的技能和知识。当其他开发人员阅读设计文档时，对他们来说可能是完全可以理解的。对于测试人员和其他利益相关者来说，这可能非常晦涩。因此，在提供反馈时，我们需要通过在评论中保持冗长来帮助作者用眼睛看到他们的文字。
同样，对于编写错误报告的测试人员来说，开发人员很难跟踪，关于测试设置和条件的某些细节对于测试人员而言似乎微不足道，因此在报告中没有提及它们。 当开发人员要求提供测试人员认为不言而喻的其他详细信息时，很容易将请求解释为烦人的，也可以将开发人员标记为懒惰或略低于标准。 但是，如果评论或请求带有适当的解释，则测试人员更有可能看到开发人员的观点，接受具有建设性的评论并提供缺失的信息。
测试人员和开发人员之间的紧张在某种程度上是自然而不可避免的。 但是，可以采取许多措施来将这种张力用作破坏力，而不是将其用作破坏力，以促进所有有关方面的相互改善。
原链接
https://www.stickyminds.com/article/improve-tester-developer-relationships-helpful-feedback
