如何在Scrum冲刺中进行测试以及如何在Scrum中编写用户案例

我是我公司新项目的开发团队负责人。这是公司将使用Scrum的第一个项目。我们有一个瀑布/迭代式SDLC。BA编写需求文档，移交给开发人员和测试，开发人员开始开发并将在迭代中发布以进行测试。测试人员需要花费很长时间来测试发行版，开发人员可以通过该发行版继续进行开发，还需要修复当前发行版的错误。我有几个问题

1. 在一个包含5个故事的冲刺中，您什么时候发布测试？是开发人员在故事完成后立即完成，还是在所有故事完成后但在sprint结束之前给出测试所需的测试时间。
2. 如果广管局写用户故事，那么细节应该是什么。传统上，编写带有所有UI布局，行为，文本等要最终确定的规范需要很长时间。我想我的问题是如何编写可实施和可测试的故事。
3. 我们的测试团队是非技术人员。对Scrum进行自动UI测试有多么重要。UI基于WPF。

我在使用敏捷方法（TDD，代码审查，重构等）方面拥有扎实的开发经验，但对Scrum还是陌生的。

编辑：通过迭代，我的意思是，如果有100个需求，我们可以在完成30、35、35个需求时发布测试，而不是等到所有100个需求都完成了。

如果测试与开发是分开的，那么您将有两个单独的Scrum团队。一只手另一只手是一个坏主意。

开发人员必须编写他们自己的测试，分开从这个其他球队。您必须将此另一个“测试”团队视为您的客户。

在冲刺中……您什么时候发布进行测试？

冲刺完成时。完全完成。这意味着您已经完成了自己的单元测试，并确保它可以工作。开发团队完成后，您可以将其发布给其他团队以进行“测试”或“部署”或组织中发生的任何其他情况。

我想我的问题是如何编写可实施和可测试的故事。

每个团队的情况各不相同。BA是开发团队的一部分。您必须作为一个团队（BA和开发人员）一起工作，以获取适当数量的细节。这是团队的一项工作，旨在从BA获得正确的信息给团队的其他成员。

对Scrum进行自动UI测试有多么重要。

必要。任何UI开发都完全需要。开发人员必须先进行所有测试，然后再将其交给“测试团队”。如果有一个UI，他们必须对其进行测试。如果没有UI，则不需要自动UI测试。需要进行测试，并且必须对UI进行测试。自动化测试是当前的最佳实践。

底线。一个单独的“测试”团队和一个写每个细节的BA都不是Scrum的最佳组织。Scrum意味着您必须重新考虑组织和流程。

我要给出的大多数答案都与软件开发的敏捷方法与迭代瀑布方法有关。Scrum恰好是流行的敏捷实现。

1. 在典型的Scrum中，没有单独的测试阶段，因为正式测试应该在整个sprint中进行。当开发人员完成用户故事时，质量检查资源应该已经准备好了他/她的测试用例，并从那时开始测试。如果他们的测试用例通过，则他们接受用户案例并转到下一个案例。一旦所有用户故事都已完成并被接受，则冲刺结束，您可以开始下一个。当然，这完全取决于持续集成，因此开发更改可立即用于质量保证。进一步的开发应遵循TDD指南，以确保回归测试尽可能快速，轻松地进行。

2. 对于BA来说，编写用户案例是一个好主意，但是对于更详细和特定的控制，User Stories可以随附正式的需求文档。用户故事应从单个用户的角色角度编写。它从用户的角度表达了一种需求，因此，如果软件当前满足该需求的所有方面，那么很自然地就可以满足用户需求。用户故事可以包含子用户故事和可分配的任务。多个用户故事的任务中可能有重叠。

3. 自动化的UI测试可能是一件好事，但我个人认为，在TDD方法上付出更多的努力以及对所有业务逻辑进行100％的单元测试覆盖更为重要。大多数软件开发团队似乎无法达到100％的Business Logic覆盖率，因此在我看来，自动化UI测试将浪费宝贵的时间，该时间可用于编写更多的BL单元测试。我认为这不是奢侈。

1. 在Scrum中，应该在每个sprint的末尾产生潜在的可移植软件增量。结果，Scrum提倡整个团队或跨职能团队的概念，在该概念中，带领给定用户故事完成的所有技能都必须存在于团队中。

   在我当前的项目中，由于经过全面测试的故事是我们对完成的定义的一部分，因此我们在团队中嵌入了测试人员。在sprint的前几天，开发人员开始处理第一个用户故事时，测试人员将准备测试方案并设置一些测试数据。用户故事之一的开发人员完成后，他们将对其进行测试。

2. 这是Scrum IMO中最大的困难之一。您必须找到必要数量的规范，以获取可实施的，可测试的用户案例。过多的前期分析，文档编制和规格说明将导致制定严格的计划，而该计划将不可避免地在冲刺过程中被证明是错误的。相反，未由产品负责人明确定义和表达的用户故事将导致Sprint期间开发人员与PO之间的通信带宽饱和，并导致开发延迟，而PO在Sprint中途做出有关用户故事的决策。

   在我们的案例中，我们已将用户故事的正确细节量定义为1 /以“作为...我想要...以便...”的形式进行描述和2 /一系列接受标准。我们很少事先制作UI的模型，它可能在sprint计划期间发生，但它们是更多的草图，之后会被丢弃。

3. 以我的经验，自动UI测试非常耗时且非常脆弱。在WPF中有很多方法可以做到这一点，但是在采取这种方法之前，我会仔细考虑这些测试的维护成本。

在越来越短的迭代中进行工作，使所有这些切换的成本越来越高。您可以通过遵循一条愚蠢的简单规则来减少这些成本：将批次大小减少一半，更改工作方式以使自己感到舒适，然后重复直到满意为止。

以您的5层冲刺为例。如果您的团队习惯于为所有5个故事编写代码，然后测试所有5个故事，则批处理大小为5个故事。切成两半。在下一个冲刺中，首先处理3个最紧急的故事，使它们尽可能早地准备好进行测试。当测试人员正在测试这3个故事时，其余的可以将其余2个故事准备好进行测试。这会引起一些成长的痛苦。更改工作方式以使其更舒适。

例如，更多的人将在一起处理每个故事，因此请尝试更多的配对，看看是否可以帮助您更稳定地工作。或者，也许测试人员会在故事2中发现问题，这会分散一些程序员在尝试编写故事5时的注意力，因此鼓励程序员和测试人员下一个冲刺，以期较早地讨论如何测试“第一批”中的一个故事”，这样程序员就不太可能犯错误，即测试人员可以轻松地进行测试。

在程序员处理下一批故事时，可能需要一些冲刺才能解决与测试人员测试一小部分故事相关的大问题。感觉舒适后，再次将批次大小减半。然后再次。在一年左右的时间里，该团队将轻松地测试故事，因为程序员认为他们已经完成了这些故事，并且一路上可能犯的错误更少。每个故事都将尽快完成。

当然，在这一点上，现在您可以对团队从产品所有者那里收到的批次进行处理，或者将团队运送到运营组织的批次进行相同的处理。等等。此时，您可以解决“广管局应该为故事写多少细节？” 问题。

顺便说一句：为了使测试人员能够减少周转时间，他们将必须通过学习如何自动化和程序员帮助他们实现自动化的某种组合来采用某种自动化。当您尝试减小批量大小时，您会发现何时需要解决这些问题。不要仅仅因为一本书说您需要自动化而添加自动化。

希望对您有所帮助。

只想分享以下经验，希望对您有所帮助。

在一个包含5个故事的冲刺中，您什么时候发布测试？是开发人员在故事完成后立即完成，还是在所有故事完成后但在sprint结束之前给出测试所需的测试时间。

对于每个大用户故事，应该将其分解为许多子任务，并且当开发人员完全完成子任务时，应将其发布给QC以立即进行测试。在对那些子任务完成测试之后，应修复缺陷。

如果广管局写用户故事，那么细节应该是什么。传统上，编写带有所有UI布局，行为，文本等要最终确定的规范需要很长时间。我想我的问题是如何编写可实施和可测试的故事。

在Scrum中，用户故事应采用任何格式，只要围绕故事的对话发生并且预计不会完成或静止。一个小故事，简称为用户故事，是一个众所周知的故事，可以在sprint中实现。故事的优先级可以基于投资回报率，业务价值或用户认可的其他重要条件。这是PO的活动。

我们的测试团队是非技术人员。对Scrum进行自动UI测试有多么重要。UI基于WPF

在Scrum中应用自动化测试非常困难。因为所有功能都没有完全实现并且不是很稳定，所以让QC通过某种自动测试工具来实现测试用例。应该对称为“回归”的冲刺进行此操作。