开发和QA之间的单独任务

Question

当我的公司开始其第一个敏捷项目时，我想知道是否更容易为QA和每个层/需求的开发提供独立的任务。这是一个更干净的过程，还是缺乏对开发任务的洞察力对QA是有害的，因为它们的任务是分开的。如有任何反馈，将不胜感激。

Answer 1

我的公司使用敏捷已经有一段时间了，所以我可以给出一些答案。

首先，我们只进行黑匣子测试，我们没有访问代码的权限。因此，每个故事都定义了一些技术子任务，这些任务只由开发人员处理。我们不测试他们。

至于其余的-我们分享所有的任务/故事(无论你怎么称呼它)。这是有原因的。一个是你提到的-缺乏洞察力，缺乏“大局”可能会成为一个问题。测试和质量保证是有区别的。你需要大局，你需要监控项目中发生的一切，这样你就能及早发现风险。我不只是向开发人员报告bug。我的职责也是向项目经理报告可能的风险。虽然开发人员通常只处理应用程序的一部分，但需要有人将其作为一个整体来看待。这就是为什么我认为分离任务不是一个好主意的原因。

另一件事是，对我来说，做一些普通的任务似乎更容易、更简单。您问过分离任务是否是“更干净”的过程。嗯，我不这么认为，我会说正好相反。对于每个人来说，定义状态都要容易得多(比如实现/测试/解决等等)。为每一个任务和实现一个适当的工作流。

最后一件事--共同的任务=更好的计划。如果您正在实现敏捷，您一定听说过墙上的彩色卡片(如果不是- google表示“颜色卡片敏捷”)。这是个好主意--它让我看到了目前正在开发的东西(或者在开发队列中等待)。由于这一点，我可以更好地计划我的工作(例如--我可以看到，即使我目前没有太多的事情要做，事情可能很快就会变得紧张起来(因为有很多任务正在执行，以便第二天分配给我)。

我希望这能帮到你。祝您顺利过渡到敏捷。一开始可能会很困难，但最终事情会变得很顺利。:)

Answer 2

在一个真正的敏捷项目中，开发和测试之间的界限可能变得非常非常模糊。一个正确实现行为驱动开发(BDD)的团队将自动化验收测试，作为每个特性的一部分。

这种方法有优点也有缺点，因为每个特性都是在编写自动化之前不会完成的，但是测试通常在低于测试人员正确的水平上。

另一件事是，通常情况下，他们实际上不是在测试，而是在检查。对于实际测试，您需要有测试人员心态的人来研究和应用智能，并使用启发式方法以典型的探索性方式发现bug。

Answer 3

我要用我最喜欢的答案--这要看情况了。

原因如下:通常测试是黑匣子，测试任务与同一用户故事中的编程任务没有多大关系，特别是如果您使用的是一个已有的代码库，该代码库经过多年的瀑布式开发(并且没有太多的单元测试)。同时，您希望作为一个团队来决定任务，并决定它们是属于测试领域还是属于编程领域(或其他地方)。您的测试人员可能没有承担编程任务的技术技能，但是您的程序员可以承担测试任务。

我建议团队共同决定任务，对于这个特定的任务或故事，分离测试是否有意义。例如，在我工作的地方，通常有编程任务来创建内部业务对象或业务逻辑引擎。这些不能直接测试，因此这些任务的测试领域几乎是缺失的--测试发生在对象或引擎的GUI使用可用时，以及反映对象或引擎的数据库更改发生时。其他任务可能有很多重叠，例如向登录表单添加验证。

最终，“最佳”解决方案是对您的团队最适合该任务的解决方案。