StackExchange 搜索似乎认为这是一个主观问题。对此我不确定。这似乎很简单。
软件开发的敏捷方法不仅仅涉及测试部分。开发人员、技术作家和客户代表（产品所有者）在敏捷世界中发挥着重要作用。
然而，当涉及到医疗、金融、保险等受监管的行业时，需要满足许多正规化的结构。正式记录的规范、设计文件、测试计划、测试用例、风险评估等都是必要的，以使不同的审计机构满足所有基础都涵盖并符合法规。
然而，在这种情况下，测试和质量保证最受关注，因为在确保一切正常运行时，我们是“最后一道防线”。当谈到适用于测试的敏捷开发方法时，您如何满足所有所需的书面记录和其他标准程序和政策？
我记得几年前在一个关于受监管环境中的探索性测试的会议上，我遇到了同样的问题：你如何在需要严格记录正在完成的测试的环境中使用 ET，此外还要审核需求-设计-之间的可追溯性测试问题验证等
然后我听到了解释，这似乎是微不足道的。您可以使用 ET 中适合的部分，并且仍然记录您在测试执行过程中所做的工作。就在那时我了解了 SBT 以及他们如何真正将他们的章程与要求相匹配等。
但是足够的 ET 和 SBT。我认为您可以以同样的方式进行敏捷开发，并享受该方法的优点，同时仍然符合您所在行业的要求。
特别是围绕敏捷，我认为如果您进行真正的批判性分析，您将得出结论，与“敏捷测试”相关的任何内容都不能用于非敏捷（让我们称之为传统？）方法论。这促使我在我的博客中写了一篇关于敏捷思维而不是敏捷测试的文章。
无论如何，我认为您应该真正了解您对敏捷测试的喜好，并找到将其应用到您当前方法论的方法。我的猜测是您将能够实现 80% 或更多。
我认为这里的关键是要意识到，当您处于受监管的行业时，文档不再是一项任务。它现在是一个已发布的功能，您需要满足感兴趣的客户和外部利益相关者。您应该像对待非监管项目的用户手册一样对待它。
对于我们的团队，我们通过将文档作为要发布的功能放入 sprint 中来处理外部发布的文档。我们对这些文档用户故事进行估计，并将它们视为 sprint 中的任何其他用户故事。
我有一个类似的问题，我发布在 softwaretestingclub.com 上：
http://www.softwaretestingclub.com/forum/topics/ieee829-testing-standards-in
我从答案中得到的，不仅来自网站，而且来自我当前客户的同行，是敏捷中仍然有文档，但更少，而且更少。您的故事中的信息可以汇总到官方文档中，因为每个故事都可以有效地被视为一个微型 v 模型。
Anna Baik 的一个回应真的让我明白了：
“......您可以记录您的测试的唯一方法是预先计划！这真的是监管机构想要看到的，还是他们想要看到您实际进行的测试的证据，以及您如何决定是否够了吗？”
Anna 还提供了一个对您有用的链接：
从其他地方复制粘贴我自己——敏捷宣言说“工作软件优于文档”，它并没有说如果你必须写文档，你根本不应该写文档。当在现实生活中使用敏捷时，它可能会进行一些调整，我的经验中很少有例子——涉及新硬件，客户在完成任何开发之前需要完整的规范，软件是更大系统的一部分，需要获得来自系统架构师。您仍然可以在较短的发布期内工作，交付工作软件，少做文档，设计少。