谁应该编写测试计划？

我在公司内部开发团队中，我们根据营销团队的要求开发公司的网站。在将网站发布给他们进行验收测试之前，我们被要求给他们提供一个遵循的测试计划。

但是，开发团队认为，由于需求来自请求者，因此他们将最了解测试内容，查找内容，行为方式等，因此不需要测试计划。我们一直对此争论不休，开发人员发现浪费时间来写下以下内容：

1. 点击按钮一个。
2. 重点在XYZ表单字段，然后单击按钮乙。
3. 你应该看到的行为Ç。

对于每项要求/功能，我们都必须重复进行。基本上，这是对需求文档中已有内容的重新表述。

我们正朝着使用敏捷方法来管理我们的项目迈进，并且在每次迭代结束时都要求这样做。

除了单元和集成测试之外，谁应该是提出最终用户验收测试计划的人？应该是请求者还是开发者？

提前谢谢了。

关于
CK

测试计划不应由开发人员编写。测试计划的一部分是检查开发人员是否正确解释了需求。开发人员无法在要编写的代码上有效地编写测试计划。测试计划应由将要进行质量检查的人员或业务分析师编写。如果开发人员必须编写计划，则永远不要指派某人为他要编写的程序部分编写计划。

请注意，这与设计单元测试不同，后者必须由开发人员编写，因为开发人员应测试自己编写的代码以查看其是否达到了预期。但是测试计划是为了测试应用程序是否按照预期的方式工作，并且必须由不知道该应用程序在技术上如何有效运行的人来完成。

质量检查小组应编写并执行测试计划。

理想情况下，测试计划应与功能规范并行编写-令人惊讶的是，如何思考功能测试可以集中精力并改善规范。

一个Scrum答案：如果您想定义“完成的定义”，您会注意到快速制定测试计划已成为其中一项。如果故事还没有经过测试，您还能如何描述待完成的故事。

谁负责创建测试计划？团队

谁是团队？任何致力于实现该产品的人都应该是The Team的成员。

因此，在您的情况下，您可以包括（或雇用）可以将测试计划编写到“开发团队”中的人员。如果您要迁移到敏捷，您会注意到在开发的并行过程中会创建测试计划。两者都是从同一个故事开始的，通过交流最终是同步并同时交付的。在通过利益相关者认为关键的测试案例之前，您不应声明自己的故事“完成”。

我发现功能测试计划应该由功能/业务分析师编写。他们编写功能分析（即使您正在敏捷地工作，我假设您也进行了分析），因此他们应该写下应用程序中应遵循的测试路径。

这完全取决于您的工作方式，但是在我看来，开发人员不应编写有关如何测试应用程序，使用哪些数据对其进行测试的功能文档。

这可能会使两个团队都高兴，并且很适合朝着敏捷方法迈进：

自动执行您的用户接受度检查，并进行屏幕广播。

http://pragprog.com/magazines/2009-12/automating-screencasts

听起来您遇到的问题的一部分是，您编写的测试计划是非常重复的，并且完全是确定性的。老实说，我根本不会称呼您正在编写测试的东西-如果只是在确认需求，那就是检查。自动执行此操作并进行屏幕广播，可以让您定期为客户打包一个简洁的演示（您甚至可以每天短时间发送给他们）–与打开测试计划和打开测试计划相比，他们更有可能点击演示并观看开始工作，所以希望您能获得更快的反馈（如果您正朝着更敏捷的方法迈进，这一点非常重要）。您将能够重复使用组件，从而减轻您的工作量，

它还提供了一种实际执行需求的方法-您是否遇到过Gojko Adzic的可执行规范？在这里看看：http : //gojko.net/2010/08/04/lets-change-the-tune/ 如果您正在考虑将其作为将需求转换为可执行形式以演示给客户的一种方式，那么似乎突然变得没有意义了。

现在，戴上我的测试仪，我很荣幸地指出，如果截屏事件开始，它将使您/您的利益相关者有空进行一些适当的测试-即尝试极端情况，以及实际挑战应用程序的测试，而不仅仅是确认要求。我建议您提供截屏视频，以及一些简短的问题或建议，以获取您需要更多反馈的领域，例如：

1）这是我们的新注册表格-观看此截屏视频，了解其工作原理！

我们想要反馈的信息：我们在此表单上添加了很多额外的检查，以确保客户无法输入错误的数据-我们非常希望您查看客户在收到错误消息后收到的错误消息输入错误的内容，并告诉我们我们的客户是否会发现它们易于理解。
我们还想知道在某些情况下我们是否过于严格-如果您有任何特别不寻常的客户数据（可能是一个很长的名字，或者一个很短的名字，或者名字上有不寻常字符的人，还是其他我们没想到的东西，或者他们的地址没有街道名称或类似的怪异内容？）那么您也许可以花几分钟时间尝试一下？

也就是说，您呈现了一个不错的截屏视频，然后要求您提供反馈，而不必过于具体地定格，让他们考虑潜在的问题，而不仅仅是确认。让他们思考，而不只是盲目地通过测试计划。您基本上是在为他们写一份探索性的测试章程。（如果您查看“ 敏捷测试象限”，这些将是第3象限中的测试）。

以装修房屋为例。您会接受承包商的清单，要求您检查他为您做了什么吗？还是您会提出自己的清单，检查承包商是否完成了您指定的工作？

答案很明确：请求者应该检查以查看他/她所请求的内容是否按照规范完成。他/她应列出自己的清单并测试该应用。针对此列表。

但是，开发人员应拥有自己的检查表，并确保在处理应用程序之前完成了正确的内部测试并清除了错误。UAT结束。理想情况下，开发人员应以测试脚本的形式自动化大多数测试。还记得TDD吗？理想情况下，应编写测试脚本（在本例中为单元测试用例）以测试应用程序的组件。然后应编写测试套件以结合这些单元测试用例，以执行集成测试和随后的回归测试。

最终用户验收测试计划通常由客户或代表客户的公司的业务伙伴编写。它应该代表客户想要的功能，并补充QA的集成测试。QA和Development都不能有效地计划用户接受测试，因为用户接受测试的主要目标之一就是要确保QA和Development认为客户想要的实际上是准确的。