关于开发工程师与测试工程师合作的思考

Question

假设我们想开发一个小模块(所需时间:一个开发人员两周)。那这个新的(也许)呢？管道：

1. 测试工程师开始工作：
   • 想一想我们需要测试的所有案例(包括许多边缘案例)。
   • 使用自动化测试框架将它们写成代码。
   • 在这个阶段，测试代码都会失败，因为业务代码还不存在。

2. 测试工程师完成后，开发人员启动：
   • 开发商业代码。在开发期间，运行上面的测试代码。(现在开发人员不需要使用像PostMan这样的东西来一遍又一遍地手动测试他的代码。)
   • 测试代码可能包含错误，开发人员应该修复它。(由于测试代码大多是简单的，所以修复不应该很困难)
   • 当所有测试代码都通过时，代码就几乎完成了。

3. 测试工程师检查测试的修改不会丢弃他想要测试的东西。
4. 好了。

我们在这里讨论的是E2E测试，而不是单元测试。IMHO单元测试应该由程序员进行(这是正确的吗？)

我们是一个很小的团队，所以可能无法在大公司中使用这种方法。

这种方法是否可以接受/精彩/可怕/可怕？

Answer 1

这看起来像是验收测试驱动开发的非迭代版本。与所有非迭代过程一样，它也受到这样一个事实的影响:它假定它能够完美地预测未来，客户永远不会改变他们的想法，需求、市场、环境和环境永远不会改变。

ATDD以迭代的方式工作:测试工程师与业务分析师和/或客户一起编写一个测试。开发人员会通过测试。该项目是建立和交付给客户，谁已经可以玩的产品。在玩游戏的时候，客户不可避免地会发现他们错过了一些需求，或者错误地判断了他们所做决定的影响。

然后，根据客户端的反馈，测试工程师与业务分析师和/或客户端一起编写第二个测试。…等

还请注意，在ATDD中，测试工程师和开发人员通常是同一个人，尽管他们不必是这样。(如果不是，您可以在阶段中做一些重叠，例如让测试工程师创建第二个测试，而开发人员仍然实现第一个需求。)

Answer 2

在TDD/BDD框架中，问题似乎没有得到正确的定义。测试是在定义接口部分的基础上计划并开始实现的。通常，敏捷开发团队必须提供适合于单元的集成测试，以证明创建的类满足用户故事，并满足性能、GC限制和资源消耗等非功能需求。此外，测试可以包含相关的度量作为断言的主题，这证明了类的生存权。因此，测试人员不应比其开发人员更了解所测试的对象。对编程，当一个工程师编写实现，第二个工程师编写测试(轮流编写)时，他们一起计划了所有的工作更合理--任何模块都应该包含测试，测试每一个需求(功能而不是功能)，因为模块代表业务逻辑的一部分，当在项目架构师或业务分析人员的参与下定义验收约束时，这是一个很好的实践，并且它们应该对应于实际情况，其中类将在其中工作。从另一方面来说，测试是一个极好的理由，它可以对编写的代码进行一次检查，并了解所做的工作以及还可以改进的内容。这样，测试工程师和开发工程师在项目中的角色几乎相同:他们都应该了解将要做什么，以及整个周期。此外，这种方式有助于建立一个工程和问题的共同愿景。毫无疑问，测试的计划和启动时间不应晚于已经开始的实现。另一种方法是实现计划好的接口和特性，并将测试委托给测试工程师。即使在这种情况下，试验计划及其实施也必须在同一论坛内以一种合而为一的方式拟订。但第二种方法的协作水平较低，我不认为它比第一种方法更有效。最后，XP或对编程已经证明了第一种编程方法是有效的，其中分离工程师-测试工程师是非常有条件的和时态的:角色通常是轮流的。因此，最好的协作是由具有旋转角色的对编程工程师协作。