前几天我写了一篇如何成为一名优秀的测试人员的文章。现在我试图确认这样一个观点：一个优秀的测试人员对开发人员来说是非常重要的，从质量保证的角度来看也是非常重要的。成为一个良好的开发人员的文章有数百篇，我希望下面的一些想法能帮助程序员与测试人员更好的合作。

　　1、不要测试测试工程师

　　即使你与测试人员或整个质量部门的人的关系非常不好，也不要用人为的错误代码来证明他是个质量差的测试人员！诡计迟早都是要暴露的。测试人员也有好方法来显示你的低技能，人与人/部门与部门之间的斗争总是结束在客户的关键的免责条款下。

　　2、做你自己的验收测试

　　在单元测试代码覆盖的时候，它似乎是更重要的可用性或GUI测试，特别是如果我们看着开发人员工作。不幸的是，GUI单元测试是与易用性紧密联系在一起的，并不是很有效。尽管开发人员常常下意识地避免珊瑚礁，但还是每一次都执行短暂的验收测试。

　　3、不要犯同样的错误，即不要重复的BUG

　　作为一名测试人员你可能经历这样一件坏事：开发人员重复同样的错误。出现这样的事实，测试人员应该能够预测这个错误是如何在一个功能性变化的场景发生的。这说明了程序员的粗心和他在学习困难的技术方面缺乏进展。人从错误中学习，因此开发人员同样应该如此。

　　4、测试工程师不是想去伤害你

　　开发人员通常认为，测试人员的主要测试任务是通过检测出尽可能多的bugs来证明代码的编写者是低能的。开发人员常常是害怕给代码进行测试，而应寻求协助，以确保做好工作。如果这时测试人员过来并说：“你非常糟糕，因为我在你的代码中发现了29处错误”- 问“又剩下多少？”：）有人说，“我们发现更多的错误，更多的是依然存在” - 不要忘记它。

　　5、不要把质量责任推卸给测试工程师

　　另一种负面的东西，常常有情况是，当错误在客户端被发现时，开发人员往往不认为这是他们的责任。他们把责任转移到质量保证人员，当然，他们是有责任的，但我们必须记住该产品是在协同合作下创建的，整个公司都是有责任的。尽量编写最好的代码，放弃这样的想法，如“我会写这段代码，测试人员会发现所有的错误，如果没有，这将是他们的错” - 非常糟糕的做法。

　　6、编写良好注释和可读性及的程式码

　　在Visual Studio和其他一些开发工具中自动化注释可见的情况下，开发人员忘记从里面包括一些东西。一些通常在危机中被证明是非常有益的，而且对代码评审是必要的东西。与此同时，编写解释了很多但没有可读性的注释代码，函数和变量名的字符数将不再限制！

　　7、提供易理解的错误警告信息

　　我认为测试人员执行的最艰巨和耗时的活动之一是寻找一条访问到bug的路径。提交错误到软件缺陷追踪系统，并得到响应“无法重现”，这种情况通常结束于打电话给开发人员来演示或发送给他截屏视频。通过提供良好的错误信息，测试人员能够提供一个的现成bug。如果你有日志引擎那是非常好的，因为在一个bug附件里有客户端日志文件是非常有用的。

　　总结

　　这些都只是一些松散的意见，来源于我作为一名开发人员和测试人员的经验。如果您有其他建议，请评论。

　　版权声明：51Testing软件测试网原创出品，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。