如果您的任务是为在“敏捷”环境中开发的Web应用程序引入测试过程”，该任务每周2个周期发布。但目前尚无框架。没有有关现有功能，测试计划或其他方面的文档。那你从哪里开始呢？
我一直在考虑这个问题，我认为以下是考虑的好起点：
确定现有功能：
等级对于因更改和断裂影响而导致断裂的风险。
对于高/中等冲击/风险特征：
确定特征应如何工作。
创建详细说明预期功能的测试用例。
创建数据进行测试。
确定应该在哪里，何时以及如何进行测试。添加到测试计划中。
为了澄清，目的是引入一个框架，该框架可用于生成新功能的功能测试以及现有未记录功能的回归测试。但不要为此目的进行测试和记录。
#1 楼
我将在这里走出去，说您拥有的是一个临时开发过程，而不是敏捷开发过程。我是从这里开始的，假设您具有与此相关的程序员和项目/应用程序管理能力（即使您没有这种能力，也可以得到很多） ）。
谁-谁是该应用程序的目标用户和实际用户？用户群通过他们的身份来创建自己的需求：Intranet环境中受过训练的人员使用的应用程序与Internet上的一般公众所使用的应用程序具有不同的要求。
内容-调查应用程序的功能-我将通过两个主要步骤进行操作：一次用于垂直切片（功能和模块），一次用于层（表示，业务逻辑，数据存储等） 。这也是我开始绘制需要在要素之间以及图层之间传递哪些信息的地方（在这种情况下，我认为模块是相关要素的集合，例如在网络商店中，用于浏览产品的目录模块和用于购买的购物车模块。目录模块中的功能可能是产品搜索或产品过滤器。在购物车模块中，某些功能可能包括针对已保存付款的已登录客户的一键式订单以及帐单/送货信息，支持不同的付款方式等）。
何时-查找并绘制时间/流量依存关系。这也将涵盖应用程序中最常见的路径，您需要了解一些信息，因为最有可能影响用户的问题将出在那些常见的路径上。那就是您要开始的地方。
位置-应用程序“生存”的环境会产生影响-测试环境也会产生影响。您将要在某种程度上模拟实时环境，但是要以某种方式使您能够控制应用程序以进行测试。您还将要记录测试环境中无法模拟实时环境的任何方面以及与之相关的潜在风险（例如，测试环境经常不使用SSL）。
为什么-该应用程序的基本目的是什么？每个大小的应用程序都是为了解决问题而存在的（解决问题的定义就是“做某人想要的事情”或“做某事比其他事情做得更好”）。知道目标之后，您就会有目标。
这是我的第一遍。在将一些信息与我收集的信息放在一起后（可选格式-您可以使用思维导图，文档中的项目符号，电子表格或更正式的形式-可以使用的任何内容），我将开始研究更多信息详细信息：
以前的故障-如果正在进行任何类型的问题跟踪，请对其进行调查。您可能想知道所报告的问题类型，问题所在的位置（这使您可以了解应用程序中最脆弱的区域可能位于-或流量最大的区域位于何处）。您甚至可能会很幸运，并找到有关故障影响的信息，包括财务影响。这也可以使您了解应用程序中哪些是严重问题，哪些不是。
模块依赖性-根据我的经验，总是存在依赖性和假设。对于Web应用程序，这些应用程序包括其使用的浏览器，连接性等。模块通常取决于存储在可访问位置的用户登录信息。如果在完成某些其他活动之前不应该访问任何模块，则需要找到它们并加以注意-因为它们通常取决于先前活动提供的信息。
功能依赖项-与模块依赖项的工作原理类似，但往往需要更详细的信息。如果有它们，应用程序帮助文件/页面对此可能会很有用。我已经完成了对大型应用程序进行调查的过程，以自己挖掘信息，如果可以避免的话，我不想重复此操作-但有时这是获取所需数据的唯一方法。 br />
开发过程-您需要知道如何将新功能添加到系统中以及您的角色在哪里。几乎可以肯定，它不是一个看门人：测试人员通常会提供有关被测系统状态的信息，从而使更接近业务需求的人员可以决定该系统是否已准备就绪，可以投入使用（我会指出，这不会阻止它继续运行。处于尚未准备就绪的状态-可能存在合同要求，机会成本，并且在测试人员世界之外的很多其他方面要比影响用户潜在问题的潜在成本更重。
内部通信-尽可能地与以业务为中心的人员（通常是项目和应用程序管理）以及程序员和任何其他测试人员进行交谈。这样可以避免很多误会。我已经成功地告诉人们“我很懒。我不想把事情做完-我想让他们第一次做对”。此外，从事某项功能的人员还将对该功能的工作原理有深入的了解-这使他们成为您和您的团队的宝贵资源。
这绝不是一个完整的列表-它更多是一组快速而肮脏的想法，可以用作起点。
评论
投票是因为-令人遗憾的是-我们社区的人们陷入这种情况并不罕见最近陷入了同样的境地。我首先编写了一个测试策略文档。您不必做的一件事就是“详细说明预期的功能”，测试应该断言预期的功能与实际功能匹配。不要害怕从功能团队寻求更多信息/文档。另外，不要忘了负面测试，性能测试，安全性测试，可用性测试等。还有很多测试不只是幸福的道路。