人人都知道猫和狗不能和谐相处。我对此的较不科学的解释之一是：这与不良沟通有关的。当狗摇尾巴时，它说：“一切都很酷，让我们一起玩吧。”但是就猫而言，狗说的是：“当心！我真的很生气！”
这并不是说我要称呼任何人为狗（或猫），而是开发员和测试员之间的关系往往也同样紧张。这可能只是自然的“我们对他们”的心态，团队发展作为一种群体认同的手段。但是有时，它会不适当地轻视另一团队所做的工作和努力。
我认为这种情况至少部分是由于沟通不畅造成的。各方对另一方应该知道和做的事情有一定程度的期望，而对另一方在其工作必须的约束、条件和要求却知之甚少。缺乏对一个团队的工作如何影响另一个团队的工作的了解，加剧了已经存在的紧张局势。
这可能导致一个团队对另一个团队失去耐心，并感到他们是失败的原因。一旦这种情绪开始，就很容易失去互相学习的机会。
例如，假设我们的测试团队得出的结论是：开发人员编写晦涩的设计文档的原因是，他们不关心任何需要阅读和使用这些文档的人（即我们）。结果，当我们收到另一份写得不好的文档时，我们只是不断地互相抱怨，而不是尝试与作者合作以提高他们的写作技巧。同样，当开发人员拒绝了一个bug，声称我们没有提供足够的细节时，我们只会把这个人标记为懒惰的人，而不是认真工作和修复bug。
但不一定要这样。稍加努力就能改变这种态度。这里有两个我的经历可以教我们一些东西。
一位开发员给我写了一封长信，抱怨我的团队提交bug报告的质量低下。最基本的说法是：提供的细节不够，缺乏复现步骤，而且我们糟糕的报告技巧使他浪费了很多时间；到目前为止，没有什么新的改进。如果你在测试中工作了足够长的时间，可以确保你也至少收到过一封这样的信。
使这封信与众不同的是它的其余部分。该开发员详细解释了造成他浪费时间的原因以及bug报告中的哪些更改可以节省其时间。他指出了其希望测试人员采取的一些基本调查步骤，以定位出问题所在。他展示了在所提供的细节上的一个小小的改变将如何避免他走错方向，为什么我们引用的测试脚本在他的机器上不工作（以及如何修复这个问题），以及为什么使用bug报告中的步骤很难重现bug。这种语气不是“看你做得多么糟糕”之一。相反，它是“请理解你的工作对我的工作的影响，并利用这些知识在未来做得更好。”
除了信中的细节很有洞察力，并且可用于bug报告培训之外，它还增加了我们对这个特定开发人员的赞赏。与其撰写令人讨厌的“如果你知道如何写一个正确的bug报告，我们都会过得更好”，而是他努力详细解释了我们报告中的弱点，它如何影响他的工作以及什么可以防止或减轻这些问题。他还格外小心，以确保不仅细节正确无误，而且语气也是我们愿意听的。自然，我们会继续听取这个开发员的意见。
把这一点放在我们这边：如果开发员所做的事情打扰了我们，我们可能会被惹恼，抱怨并永久保留开发员的形象——根本不关心质量。或者我们可以反思问题出在哪里，以及它如何对我们的工作产生负面影响。它不需要大动作。我们每个人都可以不需要太多的客套就可以做到。它所要求的只是愿意放弃通过发出尖刻的信息而获得的即时满足。相反，花些时间和心思去指出可以修复或改进的地方。
作为我工作的一部分，我可以阅读很多架构、设计和测试文档。其中许多内容难以理解，不是因为技术含量高，而是因为它们的编写方式。它们充斥着复杂的短语、有歧义的句子，以及命名对象缺乏一致性。
一种选择是叹息并接受这就是事实。另一种方法是写一个隐晦的评论：“不清楚”。第三种方法，我经常使用，解释令我烦恼的文字以及为什么我认为需要对其进行修改。
这需要很多时间，主要是因为这意味着我要写更多评论：不仅是与内容相关的评论，还包括编辑评论。我将解释为什么语句带有歧义，或者由于缺少一些关键信息而根本无法理解。如果文本与文档中其他地方的内容相矛盾，我将引用该部分或提供引用。当一些东西以复杂的方式被写下来时，我试图提供一种替代的方式来表达同样的东西。这通常意味着写作、编辑和重写几次，直到我满意为止。
我所有这些努力的目标是帮助作者提高写作水平，而不是仅仅提供负面评论。有时结果是作者确实对文档进行了改进。我希望这能对他们的写作技巧产生持久的影响。当然，在某些情况下，所有编辑评论都将被忽略了，而在某些罕见而令人满意的情况下，实际上有人会说谢谢。相反，当我碰巧得到一份写得很好的文档时，我一定要感谢作者并向他们的经理表示赞赏。
当你在工作的任何方面采取这种建设性的方式时，反馈必须非常具体才能有效，因为接收反馈的人可能具有与你不同的技能和知识。当其他开发人员阅读设计文档时，他们可能完全可以理解。对于测试人员和其他利益相关者来说，这可能非常晦涩。因此，我们需要通过详细的评论来帮助作者站在我们的角度来审视他们的文字。
同样，对于编写开发人员很难跟踪的bug报告的测试人员来说，关于测试设备和条件的某些细节可能显得非常琐碎，以至于没有必要在报告中提及它们。当开发人员要求获得测试人员认为不言而喻的额外细节时，很容易将请求解释为烦人的，或者将开发人员标记为懒惰或水平低。然而，当评论或请求附带适当的解释时，测试人员很有可能会站到开发人员的一方，接受建设性的评论，并提供缺失的信息。
测试人员和开发人员之间的紧张关系在某种程度上是自然和不可避免的。然而，要利用这种张力，而不是作为一种破坏力，以促进所有有关方面的相互改善。
译自Michael Stahl的《Improve Tester-Developer Relationships with Helpful Feedback》一文。