如果我在错误的地方问这个问题，我深表歉意。（可能是特定于职业建议和 QA 的小型堆栈溢出之一）我最近花费了大量时间来学习和实施我们项目的单元测试框架。
在引入单元测试框架之前，我们的方法是编码、手动测试、提交，希望事情不要崩溃或逆流而上。一个非常被动的系统。
现在，我们都明白事情需要进行测试，并且自动化测试是高效且良好的。但是，目前的角色似乎是“你做测试”和“编写自动化测试”
进行手动测试是可能的，但感觉势不可挡（因为总是有错误），而且很像我的技能没有得到充分利用。
我在完成请求的第二部分时遇到了困难。如果代码不是可测试的，那么编写自动化测试是很困难的。
我负责 QA - 但是 - 我只能找到有关测试驱动开发的资源。
在其他开发人员尚未编写有关创建可测试代码的问题时，我可以使用哪些方法来提高我的 QA 角色的效率？
名称Test-driven development和unit-testing的问题在于它们暗示它们是关于测试软件的。他们不是。TDD 和单元测试是关于设计的，它们本质上是开发人员的责任。
QA 分析师的角色对于任何实践 TDD 的团队来说仍然是最重要的，而且在你发现自己作为一名尽职的 QA 工作之前将需要很长时间！
看看验收测试驱动的开发，并考虑通过编写自动化验收测试来更多地参与需求阶段，也许使用诸如FitNesse之类的工具。
当然，手动的探索性测试仍然占有一席之地。但是你应该考虑重复回归测试违反你的基本人权！
我认为开发人员至少应该编写单元测试（可能使用 TDD）。这是保证他们签入的代码可能正常工作的最低标准。
我将 QA 角色理解为提供更高级别测试的人，以确保软件满足客户的要求，因此您不会真正测试单个类，而是测试模块或整个应用程序。即使开发人员不提供单元测试，您仍然应该能够自动化端到端测试（这通常包括自动化测试环境的设置等） - 但是您的工作会更令人沮丧:)
我认为让开发人员加快单元测试的速度将是您的主要关注点！这样，每个人都是赢家。
在那之前，由于您实际上是在使用遗留代码，Michael Feather 的《有效地使用遗留代码》一书显然包含了很多关于测试此类代码的有用建议。
您可能已经知道这一点，还可以查看行为驱动开发 (BDD)，其中包含很多关于创建自动化集成测试的内容，我认为您会对此感兴趣。
根据我的经验，人们不会一夜之间就编写测试转过头来——说服他们是一个过程。程序员最终会不情愿地尝试它，但距离他们成为倡导者和常规实践者还有几周或几个月的时间。这并不意味着你应该放弃，只是认识到这是一场艰苦的战斗，需要来自上层的支持，以及团队内部的一些优秀倡导者。
您可以自己潜心编写测试：
鉴于大约一半的错误是以前错误的“回归”，在您的情况下，我将专注于为新的和关键错误编写回归测试。这将极大地帮助您进行正常的 QA 工作，但也将成为未来错误的绝佳安全网。
即使你不能说服开发人员立即编写测试，你也会有一些有价值的测试，他们很快就会看到它们的价值。这项工作可能有助于推销开发人员编写单元测试的想法。
几年前我曾担任过类似的工作，所以我能理解你的烦恼。为了让开发人员跟上单元测试的速度，我建议进行指导和结对编程会议。为设计不佳的课程编写第一个单元测试可能会很痛苦。如果你们有两个人，那就更容易也更有趣了——更不用说降低在最初的重构中犯愚蠢错误的机会了。
正如@Grant 已经提到的那样，Feathers 书是这方面的宝贵资源。在最初的几个月里要有耐心和坚持，在结果（测试覆盖率和团队态度）慢慢开始显现之前。
你还必须有强有力的管理支持——没有这个，尝试就毫无意义。管理层必须明白，构建单元测试是一项投资，它现在占用了你很大一部分时间和精力，而且只会在未来几年内得到回报。如果他们坚持与以往一样保持最后期限的压力，你将不可避免地失败。如果开发人员压力很大和/或缺乏动力，他们就无法学习和练习新的技能和思维方式。
（硬币的另一面当然是必须考虑投资是否会带来利润。为遗留代码构建单元测试只有在管理层预见到该产品将被维护和使用多年的情况下才值得。来。）