在同一冲刺中进行编码和测试

如果直到冲刺结束才完成全部或大部分编码，如何在与编码相同的冲刺中处理测试？（我指的是冲刺中单个PBI的“汤对坚果”开发和测试。）

我在网上看到的大多数答案都涉及QA自动化，但这实际上是不可能的，因为您通常需要功能性UI来记录或创建自动化测试。我只有故事板随着我开发功能和发现新需求而不断发展。

就我而言，我正在开发一个新的桌面应用程序。桌面应用程序通常无法很好地进行自动化测试。我有一些自动化的单元测试，但它们不是QA专业人员执行的手动功能/集成测试。

因此，我现在的状态是明天的sprint结束，我仍然需要完成编码，而且我的质量检查人员还没有要测试的东西，也不知道如何测试如果不握住我的手给我的东西。

我确定我不是第一个遇到这种困境的人。

过去，我做过一个管道：在当前的sprint中，测试团队测试在上一个sprint中已实现的功能。在我目前的工作中，PM将这种方法称为“瀑布”，因此是不可接受的。

如果您不测试用户故事（US）并验证是否满足接受标准，则不会完成该故事。如果不这样做，美国当然会进入下一个冲刺。而且，如果您所有的美国都处于这种状态，则您的sprint已经结束，而该项目没有任何价值。从客户的角度来看，我无法将其与整个开发团队一起度过假期。

精益原则之一（敏捷并不以混乱结束）说“质量是内在的”。仅当满足您定义的质量标准时，才执行某些操作。这对于拥有真正的敏捷过程至关重要，以零值结束弹簧或将开发与开发分开进行测试是一个大问题的征兆。

您可以做很多事情：

• 自动化是成功的关键。至少在单元测试级别，以及其他类似CI的实践也很重要。这还不够，但是如果做得好，这些类型的测试会导致在手动测试中发现很少或没有错误（通常是很少的UI事情）。如果您有专门的质量检查人员，那么他们可以是使验收测试自动化的人，并且其中一些自动化可以在完成冲刺之前开始。

• 查看您的用户故事的大小。如果您在冲刺的前两天第三天完成了美国比赛，那么质量检查人员可以对其进行测试。在我看来，拥有小的（SMART）用户历史是敏捷开发成功的最重要因素之一，很多人似乎还没有意识到这一点。

• 测试人员与开发人员之间的合作是成功的另一个关键部分。在我以前的项目中，当美国由开发人员完成时，有一个质量检查人员与开发人员进行“配对测试”（可以是手动的，也可以通过启动一些自动化的工具来完成，或者两者都可以进行），效果很好。

根本的问题是，您有编码但不进行测试的程序员和测试而不是进行代码的测试人员。

解决该问题，您将不会遇到这个问题，并且可以说是效率更高的团队。

过去对我有用的一种方法是建议编码人员和测试人员将故事与提供完整测试故事的明确任务配对。同时，我也消除了所有形式的“开发完成”思想：scrum / kanban / trello板上没有“开发完成”专栏，编码人员也没有“开发完成”的态度。

发生了什么事：

• 两人负责传递故事，如果故事未完成，他们都会失败。在大多数情况下，他们被视为负责提供软件的负责任的专业人员，而且他们确实做到了。

• 由于测试人员需要进行单元和集成测试，因此测试工作量少得多，因此他们无需手动重复相同的测试。

• 当开发人员更好地了解测试人员需要什么时，一些测试就会自动进行。

• 有些人不高兴。

• 平均而言，故事提交得更快，因为代码提交拉测试周期几乎是即时的

当然，这只是我的轶事，但如果可能的话，您可能想尝试一下。

就您的情况而言，鉴于您的评论是测试人员和开发人员在您的公司中是权威地分开的，因此对于我来说，消息似乎很清楚。公司规则在沟通和协作方面存在明显的障碍。

这是一个沟通问题，而不是敏捷问题。采用敏捷方法只是使其显而易见。筒仓团队是已知的管理反模式，因此在这种情况下，请接受敏捷的非适应性！

质量检查的实际作用接近验收测试。我可以想象这将由一个单独的团队完成，该团队更多地充当产品所有者，而不是开发团队的一部分。

示例：在冲刺期间，您需要添加一项功能，该功能可以按不同条件过滤搜索结果。您已经实现了搜索机制，但是结果按字母顺序排列。

• 在冲刺期间：

  1. 团队起草了新功能的设计及其对实际代码库的影响。

  2. 开发人员编写单元测试，以确保订购按预期方式工作，并同时编写实际代码。

  3. 新功能经过了深思熟虑的测试，以确保它不会破坏任何东西（回归测试），并且可以按预期工作（单元测试）。

  4. 如果可能和适当的，这是不是在大多数项目的情况下，一个产品负责人（所以你的QA团队）能够不断地评估，以避免球队在走错方向的新功能。这需要每天与数十个构建进行持续集成。

• 冲刺之后，产品负责人评估新功能，以检查其是否符合客户需求。冲刺结束后，您的质量检查团队实际上就在这里。

我相信您的实际问题如下：

• 范围。冲刺只与您的团队有关，而与您的团队无关，而与您实际的质量检查有关，后者更像产品所有者。

• 测试。您拥有质量检查团队的事实并不意味着您要做的就是编写代码。您的团队的工作是提供可以按预期工作的功能，而不是抛出其他代码以供测试。如果您依靠质量检查小组为您进行测试，则将增加总成本，因为错误会在一到两周后修复，而不是立即修复。

是否在冲刺结束之前没有完成全部或大部分编码？

为什么不早完成？此关键限制是您遇到麻烦的根源，而且我已经看到两种方法都可以成功。一个很好地适应了敏捷方法（但不适合其他常见实践），而另一个则有点敏捷（但更常见）。

首先是直到冲刺结束才编写代码。实际上，编写代码只是开发中相对较小的部分。如果您完成了冲刺的一半，那将为QA提供充足的时间来完成其工作。它还使您有足够的时间来编写文档，清理技术债务，为积压的项目进行设计……对于优质产品，您需要做的所有其他工作。我所看到的一个缺点是，几乎不可能快速完成功能和单元测试。就个人而言，我认为在让质量检查人员开始研究功能之后进行单元测试是完全可以的，但是TDD倡导者（和其他人）会不同意。

第二种选择是让质量检查人员像PM讨厌的人一样在开发人员后面运行冲刺。我也倾向于不喜欢这个。即使在发布过程中有逐步升级的过程，它也会在冲刺结束时消除“可发布产品”的概念。更糟糕的是，当质量检查人员遇到测试中的问题或错误时，开发人员将专注于“新”事物。开发人员也不太可能修复这种情况下的错误。但是我已经看到它可以按时生产高质量的软件。

《 Scrum指南》要求团队具有跨职能。所有团队成员均被视为开发人员，而不论其个人专长如何。孤岛人士（编码员，测试员，质量保证员，用户体验等）对Scrum毫无帮助。团队成员会尽力互相帮助。没有“将项目传递给质量检查”的概念。

在您的情况下，听起来好像您可能有一个估计问题。在估计产品待办事项时，您需要考虑所有活动，即：编码，测试，对等审阅，部署，集成-无论您对已完成需求的定义如何。

根据粗略的经验法则，期望将5到15个产品积压项目带入sprint。这使您了解每个产品待办事项项应有多大。它还为您提供了在冲刺中“完成”工作的绝好机会。

最后，团队的任务是将一个产品待办事项移至“完成”，然后继续进行下一个。有时，这样做意味着人们互相踩着脚趾，因此一次增加一个以上的产品积压是有意义的。不过，您的指南应该是减少进行中的工作（WIP）并完成产品待办事项。

测试和编码齐头并进。您可以逐模块安排它。模块完成后，您可以将其提供给测试人员。整个方案还取决于您正在进行的测试阶段。螺旋SDLC模型看起来不错。这样，同时进行测试和编码很方便。另一种方法是V模型。

我的回答一开始可能很奇怪，那就是：您没有时间进行测试，因为您认为测试必须在代码的副作用上进行。副作用是计算机科学术语：

如果函数（...）除了返回值之外，还（...）与（...）外界有可观察的交互作用，则该函数具有副作用。

我引用了这句话来强调“与外部世界的交互”部分：您希望在UI上进行测试，因为它是在屏幕上打印的（“ [开始测试]实际上是不可能的，因为您通常需要一个功能用于记录或创建自动化测试的用户界面，”）。

其他答案已经告诉您要自动执行此“验收测试”，以便可以快速进行。是的，但是不能完全解决您原来的问题：如果没有足够的时间编写这些验收测试该怎么办？

一旦代码与外界交互，即已经打印出某些东西并希望输入一些信息，就必须放弃测试的观点。副作用的问题是，它们实际上是不可测试的。这是我在阅读Guido van Rossum采访时突然意识到的，他说关闭计算机的声明只有通过执行才能证明是有效的。

解决“不稳定性”的方法是理解，如果您一旦证明该语句有效，则可以在任何地方使用它，并依靠它来执行其工作。将其隔离在功能中并测试其他所有内容。

使该示例更贴近您的问题，该函数现在可能是一个完整的库或框架，而不是关闭计算机，它会打印出一些内容：用户界面。保持对它的调用尽可能愚蠢和稳定，因为一旦进入应用程序的那一部分，您就只能通过昂贵的验收测试（即某种外部观察）进行测试。

实际上，将UI视为“外国领土”是正确的观点，因为您不需要测试您未提供的库的逻辑，也许令人惊讶的是，这是现实的观点：您真的期望测试一次调用，例如MyWidget.draw()，您期望达到一个像素水平吗？

这并不是说验收测试并不重要，或者可以跳过。正如其他答案所暗示的那样，它可以保留并使其自动化具有巨大的优势。但是，如果您想花时间在同一冲刺中进行测试和编码，请尝试尽量避免副作用。