如何在项目上担任“QA工程师”，而不是“测试驱动开发团队”的成员？

Question

如果我在错误的地方提出这个问题，我会道歉。 （可能是针对职业建议和质量保证的迷你堆栈溢出之一）我最近花了很多时间来学习和实现我们项目的单元测试框架。

在引入单元测试框架之前，我们的方法是编写代码，手动测试，提交，希望事情不会中断或上传。一个非常反应的系统。

现在，我们都明白需要对事情进行测试，自动化测试既有效又好。但是，目前的角色似乎是“你做测试”和“编写自动化测试”

可以进行手动测试，但感觉势不可挡（因为一直存在错误），而且很像我的技能未得到充分利用。

我在完成请求的第二部分时遇到了困难。如果代码的设计不可测试，则编写自动化测试很困难。

我负责质量保证 - 但是 - 我只能在测试驱动开发中找到资源。

在我的QA角色中，我可以使用哪些方法来提高效率，而其他开发人员还没有关注创建可测试代码？

Answer 1

名称测试驱动开发和单元测试的问题在于它们意味着它们是关于测试软件的。他们不。 TDD和单元测试关于设计，它们基​​本上是开发人员的责任。

QA分析师的角色对于任何练习TDD的团队来说仍然是至关重要的，并且在您发现自己作为一个尽职尽责的QA失业之前，这将是漫长的时间！

查看验收测试驱动开发，并考虑通过编写自动验收测试（可能使用FitNesse等工具）来更多地参与需求阶段。

手动，探索性测试当然还有它的位置。但你应该考虑重复回归测试，因为这违反了你的基本人权！

Answer 2

我认为开发人员至少应该编写单元测试（可能使用TDD）。这是保证他们签入的代码可能正常工作的最低标准。

我理解QA角色是提供更高级别测试的人，以确保软件满足客户要求，因此您不会真正测试单个类，而是模块或整个应用程序。即使开发人员不提供单元测试，您仍然应该能够自动化端到端测试（这通常包括自动设置测试环境等） - 尽管您的工作会更令人沮丧：）< / p>

Answer 3

我认为让开发人员加快单元测试的速度将是您的主要关注点！这样，每个人都是胜利者。

在此之前，正如您实际使用遗留代码一样，Michael Feather的书Working Effectively with Legacy Code显然包含了许多有关测试此类代码的有用建议。

您可能已经知道这一点，但也请查看行为驱动开发（BDD），其中包括很多关于创建自动化集成测试的内容，我认为您会感兴趣。

Answer 4

根据我的经验，人们不会过夜关于编写测试 - 说服他们是一个过程。程序员最终会不情愿地尝试它，但它们仍然是数周或数月才能成为倡导者和常规从业者。这并不意味着你应该放弃，只是认识到这是一场艰苦的战斗，需要来自上方的支持，以及团队内部的一些好的支持者。

您可以自己深入编写测试：

鉴于大约一半的错误是以前错误的“回归”，在您的情况下，我将专注于为新的和关键的错误编写回归测试。这将有助于您在正常的Q.A.工作，但也将成为未来错误的绝佳安全网。

即使你不能说服开发人员立即编写测试，你也会有一些有价值的测试，他们很快就会看到它的价值。这项工作可能有助于销售开发人员编写单元测试的想法。

Answer 5

几年前我在一个类似的角色工作，所以我能理解你的烦恼。为了让开发人员快速完成单元测试，我建议指导和配对编程会话。为一个设计糟糕的课程编写第一个单元测试可能是一个真正的痛苦。如果有两个人，那就更容易也更有趣 - 更不用说降低在最初的重构中犯愚蠢错误的可能性。

The Feathers一书，正如@Grant所提到的，是一个非常宝贵的资源。在最初的几个月里，在结果（包括测试覆盖率和团队态度）慢慢开始显示之前，请耐心等待并坚持下去。

你必须拥有强大的管理支持 - 没有这一点，没有必要尝试。管理层必须明白，构建单元测试是投资，它使用了大部分时间和精力现在，它只会在未来几年内回收。如果他们坚持保持与以往相同的最后期限压力，你将不可避免地失败。如果开发人员受到高度压力和/或失去动力，他们就无法学习和练习新技能和思维方式。

（硬币的另一面当然是必须考虑投资是否会带来利润。如果管理层预见到产品将被维护和使用，那么建立旧版代码的单元测试是值得的。很多年后。）