敏捷开发的经典描述在迭代结束时有可发布的代码。如果必须进行进一步的测试和验证才能创建可发布的产品，我们如何将其集成到流程中？

解决方案

回答

每次自动构建后的自动测试至少可以解决部分问题。

回答

将系统测试添加到sprint待办事项列表(在Scrum中)或者同等版本。

同上的用户文档。

回答

是什么阻止我们进行自己的流程？如果我们发现可以做得更好的事，那就去做。如果有效，请坚持下去..如果不尝试其他方法。如果我们要敏捷，则没有固定的过程。
在每次迭代结束时，使用频率更高的术语是"可运输"代码。这意味着我们可以将其提供给最终用户(作为一堆用于复制共享或者个人交付CD / DVD的DLL)，他将通过使用它获得价值。这样的代码已经通过了所有被认为是"完成！"所必需的单元测试(开发人员)和验收测试(客户/ QA /分析师)。验收测试是端到端的客户方案模拟。

我不确定"进一步的测试和验证"是什么意思。.我可以想到其他"预发布"活动

• 某些活动，例如"培训会议"和相关内容的创建。
• 如果很少或者不经常进行客户部署，则在发布前一个月进行演示或者部署到Beta网站。
• 准客户/专家/服务人员将亲身体验一下他们所听说的新产品。

我们只需将其堆叠在最后一个迭代端点的末尾(如果我们像我这样特别悲观..请取历史平均值..如果我们提早发布。是的！)因此，如果企业确定Iteration＃14界定了一个好的可以发布的一组功能。.只是在迭代14结束后"添加n周"。那时没有复杂的数学或者不确定性。关键在于，如果我们一直定期与利益相关者/客户进行互动，吸收反馈并保持可接受的质量水平，那么就不会有最后的惊喜。

如果需要，我们甚至可以滚动开始。即，当开发团队输入Iteration＃13时，培训团队开始工作。假设他们进行了2周的迭代，这给了他们一个月的时间。希望我们在上一次迭代中不会输入大量功能。因此，在迭代＃14之后最多2周的时间，并且受所有天体/组织对齐的影响，有释放和应有的休息。

回答

系统测试的执行通常太慢，无法紧密集成到敏捷开发中。 (对此有例外，例如，精心设计的浏览器测试套件运行起来不会比典型的单元测试慢很多。)

集成的一种方法是进行全天候运行的通宵构建或者连续构建，并且可能花费几个小时来构建和运行所有测试。如果构建通过所有测试(单元测试+系统测试)，则它可以发布，我们可以交付该二进制文件或者源代码快照。这个想法是让x版本的二进制文件/代码快照，异步验证它们并交付绿色版本。这既适用于自动系统测试，也适用于手动系统测试。

回答

首先要认识到，我们所说的测试的宽度/宽度会随着项目的进行而增加，并且软件会增加范围和/或者复杂性。因此，尝试将此工作投入一个迭代后，将无法正常工作。迭代的良好规则是每个阶段的工作水平恒定，这取决于项目的速度。

因此，解决方案可以采取以下两种方法之一：有或者没有自动化。较高测试级别的自动化将减少运行测试的工作量，使工作再次适合于迭代，因为每次迭代都只关注增量范围/复杂性的增加。即使这是我们想要的，也并非总是在所有项目环境中都能实现。高估高级测试自动化是一个陷阱，我们应该认真对待，换句话说，要避免低估一个经验丰富的探索性测试人员所带来的价值。

没有自动化，问题就会转移到基于测试管理的问题上。并行的，时移的测试迭代是一种候选解决方案。例如，我们可以选择为系统测试任务建立一个测试积压，该任务以与开发迭代相同的节奏进行管理，但是被延迟或者时移多达一个完整的迭代持续时间。这使测试人员可以在自己的沙箱中并按自己的优先级对新版本进行整体研究。

我主张测试迭代积压是与开发人员协作构建的，就像我建议开发人员迭代积压是与测试人员协作构建的一样。我还将提倡一个具有自动化经验的测试团队，以便他们可以使乏味的工作自动化并以更具探索性的方式工作。他们的自动化测试产品组合应随着每次迭代而增加。他们还应该有权访问开发人员单元测试，并能够在测试沙箱中的发行版上运行它们。

像这样的分阶段工作并不能消除不断增加的测试范围/复杂性问题，但是它确实提供了一种管理这种复杂性的机制，因为团队正在创建积压项目，调整优先级，自动化一些任务，创建清单等。基于他们共同认为下一步应该做的事情。他们很有可能会击中大物件。

保持测试人员的整体工作能力，发展他们的理解力并通过自动测试共享他们对系统的知识的能力，似乎都是值得努力的。