Answers:
我说测试人员应该开发自动化测试-他们对代码采用“双眼”方法，并且会（或者应该只是“可能”？）发现您没有想到的错误，更不用说处理了。
加上他们对功能需求的理解可能比对开发人员的理解更高的层次-因此，他们坐在程序员的核心底层知识之间，但没有BA的知识那么高级。
如果可以自动化，请使其自动化。
让测试人员自由地找到您无法自动化的东西。当他们确实找到一个新的错误时，如果可以自动将其添加到自动测试中，则将其添加。
我认为，开发人员和测试人员应对不同类型的测试负责。
开发人员在编写逻辑时，还应该编写单元测试和集成测试。这将使开发人员能够确保他们到目前为止编写的内容能够按预期工作。此外，这些测试在将来进行更改时仍将继续供开发人员运行。一旦逻辑完成，开发人员就可以确保所写的内容可以理解他们的规范，并且可以传递给测试人员。
从这一点来看，测试人员应负责编写系统范围的测试，以确保业务逻辑按预期工作。
鉴于开发人员通常过于依赖代码，因此测试人员应该能够帮助清理开发人员的测试，反之亦然。
以我的经验，测试人员自动设置和执行测试用例的方式实际上与开发人员的方式不同。测试人员将更多地考虑如何从测试用例中获取最多的信息，如何快速执行测试，如何保持测试的可维护性等等。最重要的是，测试人员将看到开发人员会错过的测试覆盖范围的细微差别。
如果测试开发资源不足，开发人员可以提供帮助-但测试人员应仔细检查其工作。开发人员应在编写实际的测试用例之前使用固定装置和测试工具，并且开发人员切勿为自己的代码编写测试用例。让开发人员提供测试帮助确实有好处-将开发人员暴露于产品的其他部分，而测试可以帮助他们成为更好的开发人员。但是，就像初级开发人员的工作不会没有代码审查一样，开发人员的质量检查工作应该从具有更多经验测试的人员那里获得质量检查审查。
编辑添加：我是具有5年经验的SDET。我与每个都有10多年经验的优秀开发人员一起工作，并且最近一直在与他们合作克服测试瓶颈。
我真正希望看到的一件事是针对测试人员的可靠的自动化工具，该工具将使他们能够通过测试脚本有效地记录其进度，然后允许该脚本在将来自动运行。尤其是如果这还有助于同一脚本在不同的操作系统版本上运行，而测试人员不必手动检查所有脚本。
不幸的是，当然，对于我正在开发的产品，市场上没有任何工具能够胜任。但是，有必要牢记这一点，并仔细研究市场上的可用产品，以防万一某些产品可以满足您的需求。
在这里真正重要的一个关键区别是：测试人员只是在检查，还是在测试？
迈克尔·博尔顿（Michael Bolton）的这篇博客文章对此进行了更好的解释，但从本质上讲：他们只是在希望确认行为，还是在寻找系统问题？
我认为考虑敏捷测试象限也很有用（Brian Marick最初描述了这些象限，但是我在Lisa Crispin和Janet Gregory的“敏捷测试”书中遇到了这些象限：即使您没有遵循敏捷开发方法，我认为在考虑自动化并试图制定计划由谁做以及为什么做的计划时，区分产品的测试和支持团队的测试之间的区别确实是值得的。
例如，开发人员编写的单元检查可以用作变更检测器，使您能够在定期重新运行回归时及早发现回归-这些测试为团队提供了支持。自动化的系统级回归检查使它们可以有规律地快速运行，并且通过及早发现回归并支持开发人员进行的单元测试来支持团队。这样可以节省测试人员的时间来进行批评产品的测试-例如探索性测试。或者可能会应用一些自动检查来对产品进行压力测试。
我对链接的Lisa Crispin演示文稿非常满意的另一件事是，它指出自动化还可以用于支持手动测试-创建测试数据，自动化可以使场景达到您今天要关注的重点，例如例。
考虑这两篇文章将有望帮助您分析要进行的测试种类，使您更容易找出适合自动化的内容，并找出哪些自动化部分更适合测试人员进行，哪些应该由测试人员完成。由开发人员。