敏捷环境中的开发和测试时间

#1 楼

如果您想快速前进，则需要假设一旦完成某项测试并按一个周期工作，它将在该周期内继续工作。如果您不能做出这样的假设，则要么需要花费更多的时间（自己或在其他人的帮助下）进行测试，要么开发人员需要交付更高质量的代码。除了您和您​​的开发人员之外，没有人可以决定如何交付更高质量的代码。

前几年，我公司还拥有3名开发人员和1名测试人员。现在我们有四个开发人员和两个测试人员，但是我们仍然采用两阶段的方法进行测试：功能测试，我们专注于已知的变化；然后是回归测试，我们对整个产品进行测试而无需关于发生了什么变化。功能完成代码后，即开始功能测试。

当大多数/所有功能都完成并经过功能测试时，便开始进行回归测试。这是一个安全网，用于在可能与更改无关的区域中捕获错误。是否需要单独的回归测试取决于产品的结构以及从一个冲刺到另一个冲刺的变化量。

#2 楼

这是一个确切的问题，困扰着我的工作环境，还没有找到一种能够持续有效地工作的策略。

其中一些有助于您解决问题的策略和技术是： />
测试专家与编码专家一起进行单元测试。即使测试专家不是编码人员，了解单元测试的范围并与编码人员讨论也可以使整个团队更有效地利用时间。
代码完成后，编码专家将执行手动测试。在单元测试开发过程中进行的讨论可以帮助那些没有太多测试经验的人执行幸福的路径测试。
在开发和探索性测试期间，测试专家还可以确定要在最后一天半执行的核心测试作为少数旨在清除可能有问题区域的测试序列。首先执行这些操作，而代码专家则执行接受和满意的路径测试。如果团队真正敏捷，而不是“混乱跌落”或“敏捷跌落”，那么它会很有帮助。
无论是基于API还是基于GUI的测试自动化都在后面进行冲刺，以便自动化专家可以在稳定的代码库上工作。

坦率地说，以我的经验，没有最好的方法-只有一组技巧和策略可用于最大程度地减少问题。

#3 楼

以我的拙见，解决此问题的关键在于两件事：您必须使大多数测试自动化，并且必须使用严格的测试优先方法。这样做，您将能够首先指定测试，并针对每个版本立即自动运行它们。您也将以这种方式捕获任何回归。

当然，这根本不容易实现。有些事情比其他事情很难自动化。而且，首先要自动化测试（尤其是UI测试）取决于成熟的测试和开发基础结构。一个提示是使用数据驱动和关键字驱动的测试（绝对不是任何记录/重放）。

总是需要一些手动测试，即使只是探索性的测试，但是在敏捷项目中进行测试的第一步始终是尽可能多地实现自动化。

#4 楼

在敏捷团队中，这是非常普遍的情况。为了解决这个问题，我们提供了由开发人员和测试人员编写的大量不同粒度的自动化测试。但是，这还不够。为了早日交付部分完成且易于测试的功能，需要使用不同的开发人员的心态。

这就是想象开发人员正在对定期运行的Windows服务进行编程并可以通过UI进行配置。那位开发者应该通过一种简便的方法尽快将Windows服务交付给质量检查人员，以验证其行为并继续执行UI。 。然后，提供小的功能可以帮助每个人在可以使用的东西上有所建树。

#5 楼

无论您决定什么，错开代码和测试冲刺总是一个坏主意。您将交货时间（至少）加倍（至少），减少协作，增加管理复杂性，失去速度稳定性并招致更多错误。

#6 楼

首先，确定您需要进行的开发类型是否适合于敏捷开发。有许多简单的开发过程非常适合敏捷，而许多深潜开发过程却是尝试将敏捷用于其中的噩梦。
其次，如果您正在从事易于实施和测试的项目，那么与一个冲刺相比，您应该能够在与客户一起进行设计时将测试仪混入其中，然后测试仪可以编写测试并设置数据，同时进行编码，然后测试可以快速进行。

在我从事的5个敏捷工作中，大多数只是使用“敏捷”一词来隐藏荒野的西部。只有一个人与测试和客户合作良好。