SU冲刺测试

Question

在敏捷环境中，对于用于小更新的sprint，建议采用哪些测试方法？我们只是在SUT发布之前进行探索性测试，还是同时进行探索性测试并运行一些功能测试或回归测试用例？

附加信息:我们只有手工测试的测试用例。到目前为止，我们还没有任何自动化的测试用例，因为我们仍然在为将来的sprint创建它们。

更新：

谢谢你的意见。不幸的是，我们目前还没有任何自动化的测试用例，因为我们仍然在创建它们。由于这个原因，我们过去的SU冲刺是在每个任务到达测试栏之后，在完成所有的任务之后，手动测试每个任务，然后，一旦在sprint的第二天到最后一天构建了一个小的更新，每个人都只是对工作流和一些关键的功能测试用例进行了手动和探索性测试。当测试列中没有可用任务时，在sprint中的停机期间，测试人员只是在应用程序周围临时设置任务。我们团队中大约有7名测试人员，所以很难让他们都忙碌起来。

Answer 1

正如Suchit所说，这在很大程度上取决于更新的性质。我看到了一行代码的更改触发了一个完全的回归，因为这一行恰好在一个核心计算引擎中。

我对任何开发过程的建议，无论是否敏捷，都是至少每天运行多个自动回归测试套件。这些测试应该涵盖应用程序(或应用程序)的核心功能，并针对最新的可用构建运行。这样，无论在开发过程中发生了什么，在引入回归到核心功能和检测到核心功能之间，您的时间不会超过24小时。

如果您还没有这样的自动化水平，则需要时间来构建它。在这种情况下，我建议将一小部分核心函数，最好是一直使用的函数(登录是一个很好的方法，因为您以后需要这样做)，然后在此基础上进行自动回归。理想情况下，自动化过程应该是它自己的开发项目--尽管我还没有足够幸运地在发生这种情况的地方工作！

如果您没有自动化，在构建过程中，我建议为应用程序标识您的钢线程/愉快路径测试用例，以及在获得新功能或更改功能的过程中将使用的测试用例(例如，如果您的应用程序需要一个有效的登录才能运行，那么每个测试都将从登录开始，因此不需要具体的回归)，并构建一个轻量级的手动回归，以便每次运行，直到您能够实现自动化以消除需求。

在软件中，除了修复标题中的排版之外，真的没有什么小改变。我看到一个错位的“不”破坏了整个系统。如果您每天运行全面的自动回归，您可以将手动测试的重点放在受变化影响最大的区域，并了解您的自动化将发现任何其他重要的回归。这确实是一个最好地利用资源给你的问题。

这种断断续续的漫步是由于咖啡因不足和清晨太早给你带来的--我希望这里有你可以使用的东西。

Answer 2

测试不是scrum团队中的单个功能。开发人员开发和测试人员测试的概念(我编写了它，你测试它)是一个瀑布实践。团队负责进入“已完成”状态的特性。具有SQA经验或专业纪律的测试人员在理解如何测试和如何生产质量方面带来了价值。

在sprint中晚些时候进行测试是一个灾难的秘诀，并设置了旧的瀑布“测试危机”，没有足够的时间来测试，因为所有上游运行晚。这些特性必须经过编码、测试和批准，即使该特性包含了许多应用程序的垂直切片，集成测试必须由团队在几乎实时的情况下与bug修复一起执行。在“完成”之前不要前进。经常构建，经常合并，经常发布到用户测试/评审！避开斯库姆福尔！

Answer 3

这取决于什么是小的更新。这可能是一个小的改变，但它影响到系统的许多部分，例如更新数据库中的内容。

无论是一个小的更新，还是一个大的更新，不管定义如何，测试都不应该被绑定。它应该与您认为是给定更新的效果有多大联系。一个小而重要的更新可能需要广泛的测试，并且团队不应该急于推出更改。