如何告诉程序员在签入之前测试他们自己的代码，而不是仅仅“塞在墙上”？
#1 楼
免责声明：我是以程序员的身份来处理这个问题的（主要是在这里学习如何与测试人员更好地进行交互。）请务必记住，开发人员并没有总是被告知如何测试代码。尽管我们希望这不是真的，但开发人员还是从一个真正不在乎系统各个方面的人那里获得了一系列要求。您不能指望每个开发人员都了解系统的每个部分。不幸的是，规范中还存在另外两个或三个要求，这些要求现在已经失效。
是谁的错？是打破现有要求的开发人员吗？还是只是生成规范并只告诉他要测试什么的人？老实说，在许多公司中，开发人员甚至都没有告诉他们需要测试什么。代码更好，请这样做。如果我可以阻止再次见到您的错误，那么我想这样做。否则，我必须在三天之内修复它，当变化过滤到您的身上然后又回到我身边时，我已经忘记了它的所有内容，花了一个小时才能做出一个简单的修复程序，我运行该测试花了我30秒钟的时间。您可以说：“嘿，我注意到出现了一些带有XYZ属性的补丁。通常，我使用__input测试它们，并以此方式捕获了许多错误。”我认识的大多数开发人员都希望避免在代码发布后返回并修复它们，并愿意接受。
我向您保证，如果您对此感到直言不讳，您会得到一个非常生气的开发人员，他会发出嘶嘶声。在这种情况下，您将说“您有错误代码”，而不是说“嘿，这是一种提高效率的方法”。后者更具吸引力，并且更具生产力！
#2 楼
在过去，我通过首先定义“质量标准”来达到预期效果，并得到整个团队的同意。这包括为整个团队设置缺陷阈值（通常为0个Sev 1，每个开发人员有10个bug）。当开发人员或团队超出此阈值时，他们必须停止添加功能并修复其错误。然后，开发人员知道他的目标。然后，我使用指标和重点测试来实施此目标。如果开发人员或应用程序领域容易出现缺陷，我们将集中精力进行测试，达到极限，开发将停止，直到质量提高。渴望在高质量的代码库上工作，因为它们可以自信而快速地添加新功能。
评论
这是否会引起关于“这不是一个sev 1”，“是的是”，“不，不是”的可怕论据，尤其是当您接近第十个错误时？我似乎不想在这种环境中担任测试人员-我讨厌玩乒乓球，一位开发人员说：“不，不是我的代码有问题，他的代码传递了错误的信息”，其他开发人员说：“不，不是我的代码有问题，她的代码...”。
– testerab
2011年5月4日在21:19
#3 楼
如果可能，请与他们坐下来，解释错误。解释一下如何找到它，并在他们说它准备就绪之前询问他们进行了哪些类型的测试。开始提出一些建议。我总是发现，以一些礼貌的，建设性的反馈开始进行代码质量讨论会产生最大的结果，使他们可以决定自己认为足够的内容。这并不是说他们不想提供高质量的代码，有时候他们只是不考虑要寻找什么。#4 楼
我的建议是将它们编写在您使用的错误跟踪系统中。如果没有，则需要开始。如果这些错误很明显，那么他们的项目经理应该和他们谈谈。跟踪软件的统计信息应能够支持您的说法，即它们粗心大意，或者需要更好地理解该软件要解决的业务问题。“显而易见的”错误有多明显？我的上一家公司在税务/财务报告领域出售软件。我离开时才在那里呆了5年（其他人到那里的时间都比我更长），而且许多“显而易见的”领域知识规则和测试都是我尚未遇到的事情。一个示例规则是，表格5500归档可能具有附表I或附表H附件，但不能同时具有两者（两者都不可接受）。每个人都知道，一个被“写下”的唯一地方就在美国国税局和PBGC的法规中。在会议上被召唤（并感到尴尬）后，我终于也学到了。
在以前的雇主那里，最接近错误报告的地方是在走廊上大喊“要在检查之前更好地检查您的工作！”仍然没有回答出什么问题。但是那家公司遭受了缺乏源代码控制的麻烦，因此最后一个编辑文件的人应对文件曾经做错的一切负责。
我的意思是，我确实有一个意思，就是对您来说显而易见的东西对其他人而言可能并不那么明显。
#5 楼
有时我亲自与他们交谈，并要求解决某些问题，有时以我为借口，可能会错过一些东西并希望他们提供帮助。这是一种外交手段，试图让他们站在一边，也许看看您是否可以从他们那里撤出他们为什么看不到他们的理由，或者为他们这样做而撒下种子。外交是我们工作的重要组成部分，也是您需要与其他团队保持联系的重要组成部分。了解他们这样做的原因可能也很有用，也许他们认为他们正在彻底检查但不要考虑您正在寻找的区域；或只是看错了。通常，我发现开发人员对应用程序进行编码并以他们期望的工作方式进行测试，而QA经常以完全不同的方式对其进行测试。
#6 楼
首先，请确保您可以使用一些客观数据来备份您的疑虑，例如错误跟踪系统中的错误计数。如何告诉它们取决于您与开发人员的关系。如果彼此信任和尊重，可以尝试向他们展示您的客观数据。他们可能不知道自己在交付许多错误。
请牢记，可能有许多原因导致开发人员的bug数量增加；例如
开发人员受到管理人员的压力，要求其发展太快
开发人员不熟悉其使用的技术
开发人员会分心（例如参与销售电话）或客户支持问题）
开发人员不理解要求
开发人员不认为使此特定交付物成为高质量的产品很重要
测试人员尤其擅长查找错误
测试人员比其他测试人员对错误更挑剔
评论
+1为您的总体答案和第一句话。作为一个开始从事测试职业生涯的开发人员，我非常坚信，任何想成为开发人员的人都应该至少花费6个月的测试时间。重要的是要看到栅栏的另一边是什么样子！
–Rob
2011年5月4日在10:08
@Rob我当然可以感谢拥有测试人员的经验。我认为也有很多事情可以带来这种经验（不同的语言背景，不同的体系结构背景，不同的软件过程），但是不一定必须要有。但这并不是要贬低您获得的经验。我知道在开发社区中，测试有点“被看不起”，就像您是测试人员一样，这是因为您是一个糟糕的开发人员。这离事实还远。
–corsiKa♦
2011年5月4日23:10
宝贵的见识。我想说的唯一一件事是没有给出要求。我们的团队很少有如此苛刻的要求。
–劳拉·亨斯利（Laura Hensley）
2011年5月6日13:30
@Tristaan这实际上是我公司与开发人员所采用的相同方法！分析师制定了规范，当我们告诉他们如何进行改进时，他们真的不喜欢它，好像他们在制造业工作了20年使他们对数据库设计的启发远胜于我多年来的饮食经验使我具备了资格做一名厨师。
–corsiKa♦
2011年5月26日20:14
我听到了，@ glow。归结为每个人都认识到我们都在同一个团队中，我们都有自己的专业领域，但是我们每个人都没有能力制造出优质的产品。我们需要所有不同的观点才能使所有内容变得清晰。
– TristaanOgre
11年5月26日在20:24