我要在这里冒个险，说你所拥有的是一个临时的开发过程，而不是一个敏捷的开发过程。

这就是我要开始的地方，假设您有能力与程序员和项目/应用程序管理一起工作（即使您没有这种能力，您也可以获得很多）。

• 谁- 谁是应用程序的预期和实际用户？用户群根据他们的身份创建自己的要求：受过培训的人员在 Intranet 环境中使用的应用程序与一般公众在 Internet 上使用的应用程序具有不同的要求。
• 什么- 调查应用程序的功能 - 我会在两个主要阶段进行：一个用于垂直切片（功能和模块），一个用于层（表示、业务逻辑、数据存储等）。这也是我开始绘制功能之间和层之间需要传递哪些信息的地方（在这种情况下，我认为模块是相关功能的集合 - 例如在网上商店中，会有用于浏览产品的目录模块和用于购买的购物车模块。目录模块中的功能可能是产品搜索或产品过滤。在购物车模块中，某些功能可能包括已保存付款的登录客户的一键订单和计费/交付信息，支持不同的支付选项，等等）。
• 何时- 查找并绘制时间/流依赖关系。这也将涵盖通过应用程序的最常见路径，您需要了解这一点，因为最有可能影响您的用户的问题将出现在这些常见路径中。那将是您想要开始的地方。
• Where - 应用程序“存在”的环境会产生影响 - 就像您的测试环境一样。您将希望在某种程度上模仿实时环境，但以某种方式让您控制应用程序以进行测试。您还需要记录测试环境中无法模仿实时环境的任何方面以及与之相关的可能风险（例如，测试环境经常不使用 SSL）。
• 为什么- 应用程序的基本目的是什么？每个应用程序，无论大小，都是为了解决问题而存在的（对于问题的定义，即“做某人想做的事情”或“做某事比其他任何事情都做得更好”）。知道目的会给你一个目标。

那将是我的第一关。在我将收集到的信息（格式可选——你可以使用思维导图、文档中的项目符号、电子表格或更正式的东西——任何适合你的东西）组合在一起之后，我会开始深入研究细节：

• 以前的失败- 如果有任何类型的问题跟踪正在进行，调查它。你会想知道报告了什么样的问题，它们聚集在哪里（这让你知道应用程序中更脆弱的区域可能在哪里 - 或者流量最大的区域在哪里）。您甚至可能会很幸运并找到有关失败影响的信息 - 包括财务影响。这也可以让您了解应用程序中哪些被视为严重问题，哪些不是。
• 模块依赖——根据我的经验，总是存在依赖和假设。对于 Web 应用程序，这些包括与它一起工作的浏览器、连接性等。模块通常取决于存储在可访问位置的用户登录信息。如果有任何模块在其他活动完成之前无法访问，您需要找到它们并注意这一点 - 因为它们通常取决于先前活动提供的信息。
• 功能依赖项——这与模块依赖项类似，但往往需要更详细的信息。如果你有它们，应用程序帮助文件/页面可能对此很有用。我已经完成了调查大型应用程序以自己挖掘信息的过程，如果我可以避免它，我不想重复它 - 但有时这是您获得所需数据的唯一方法。
• 开发过程- 您需要知道新功能是如何添加到系统中的，以及您的角色所在的位置。几乎可以肯定它不是看门人：测试人员通常会提供有关测试中系统状态的信息，让更接近业务需求的人决定它是否准备好上线（我要指出，这不会阻止它继续生活在一个尚未准备好的状态中——可能存在合同要求、机会成本以及测试人员世界之外的更多因素，这些因素比影响用户的问题的潜在成本更重要）。
• 内部沟通——您需要尽可能多地与以业务为中心的人员（通常是项目和应用程序管理人员）以及程序员和任何其他测试人员交谈。省去了很多误会。我已经成功地告诉人们“我很懒惰。我不想把事情重新做一遍——我想在第一时间把它们做好”。此外，开发某个功能的人员将深入了解该功能应该如何工作 - 这使他们成为您和您的团队的宝贵资源。

这绝不是一个完整的列表——它更像是一组可以作为起点的快速而肮脏的想法。