也许程序员有他们自己的单元测试，也许是做测试驱动开发的结果。他们经常运行这些测试；也许每隔几分钟，但每天至少几次。
根据我的经验，QA 的自动化测试倾向于追求更大的功能块，因此比程序员的单元测试更慢并且通常更不可靠。尽管如此，尽快将这些测试的结果交到程序员手中还是很有价值的。
QA 是否应该推动程序员运行 QA 的自动化测试？QA 是否应该坚持在签入之前通过所有自动化测试？夜间构建过程是否应该包括运行 QA 的自动化测试？
（我写了nightly build但只有当你有一个 nightly build 时才有意义。我怀疑很多商店没有这个。我怀疑 QA 的完成方式差异很大，而且对其他做事方式的认识非常有限的。）
QA 是否应该推动程序员运行 QA 的自动化测试？
是的，但我也建议，如果程序员似乎没有这样做，那么在更加努力之前找出原因可能会更有成效。是什么阻止了他们？访问专有测试工具？难以在开发环境中轻松设置？结果没有意义或易于阅读？运行速度太慢？太脆了？
QA 是否应该坚持在签入之前通过所有自动化测试？
这可能很好，但如果测试套件需要 15 个小时才能运行，那就有点不适合了。
夜间构建过程是否应该包括运行 QA 的自动化测试？
是的。
以我的经验......执行，是的。维持NO。
我评论的上下文。我假设您问题中的程序员=应用程序开发人员，而不是具有编程技能的测试人员
我认为测试人员（甚至是专门从事测试的软件工程师）有一个开发人员没有的内在动机，那就是编写、运行和维护测试为测试人员所做的工作增加了价值，即它可以减少他们的工作量。手动测试工作量，而且它运行得越好，他们做其他“测试工作”的时间就越多。
对于程序员来说，阻止他们添加新功能只是他们需要做的另一项任务。
理想情况下，您应该拥有经过培训的开发人员的测试人员，并且这是日常构建和测试过程的一部分，您可以让 QA 运行。该过程尽可能顺利地进行符合他们的利益。
如果开发人员想要运行测试，那么他们当然可以，但是您的测试人员应该将其作为主要责任。
如果 QA 团队没有嵌入到开发团队中，我认为整个过程不会顺利进行。
开发人员应该始终编写单元测试，而不是 QA 团队。这是因为开发对代码有更多的洞察力。我会让 QA 团队编写更多功能测试脚本。
我认为这取决于两个主要因素：
显然，认为工程师可以从其他一些他们没有融洽关系的神秘团队进行测试是愚蠢的。但是，如果您确实将工程师和测试人员嵌入到同一个团队中，那么您更有可能让测试人员和工程师相互运行测试。
比测试本身更重要的是输出。如果输出对工程师没有用，那么您可能无法从运行测试的工程师那里获得巨大的价值。我为帮助缩小差距所做的一件事是将测试标记到对工程师有用的套件中。通过这种方式，他们可以运行与其特定工作相关的部分测试，而无需运行所有内容。