如果您必须在软件项目中不使用其中一个，您会选择哪一个？ 我有很多项目，其中客户或 PM 认为他们可以在没有一个或另一个的情况下逃脱。我们总是付出代价。
【问题讨论】：
标签： testing project-management project-planning requirements
把它转过来，跟着我重复一遍：“测试就是要求。” :-)
【讨论】：
如果您的意思是“正式要求”，我可以很容易地没有这些要求。我更喜欢有活力、有活力的客户，他们可以告诉我他们想要什么，而不是死板、过时的文件。切换到 TDD 后，我再也不想回到“无测试”环境。我选择非正式要求（故事、现场客户和客户书面验收测试）而不是正式要求且不进行测试。
【讨论】：
我想说你可以不用测试而不是需求。如果你没有需求，你怎么知道你在开发什么？
如果程序员足够优秀，他们应该能够捕捉到测试会发现的大部分严重错误。
【讨论】：
您必须根据要求进行测试，因此如果您没有要求，则无法进行测试。所以如果你必须选择一个，你只能选择需求。
但不进行测试是通向失败的途径。保证。
【讨论】：
如果我必须选择一个，那就是要求。
它不一定是一份正式的、极其详细的文件，有 20 个签名，但您必须确切地知道客户想要什么，更重要的是客户需要。
这些要求也是您与开发团队的第一次沟通。如果你没有问清楚，他们怎么会知道你在问什么？充其量，您将面临正确构建错误事物的巨大风险。我宁愿把正确的东西建造得稍微有点错误。
【讨论】：
如果让我在要求或测试之间做出选择，我会选择完善我的简历。在任何项目中，您都离不开其中任何一个，因为基本的项目生命周期是：
如果您没有可验证（然后经过验证）的成功标准和目标，您如何确保自己会成功？如果你没有机会成功，为什么要开始这个项目？
【讨论】：
我会说需求，因为在您开发软件时，客户端似乎总是存在某种程度的“功能蠕变”。测试是 SDLC 中的关键部分之一。
【讨论】：
需求和测试对于大多数项目来说都很重要，但如果您真的必须选择，您应该根据需求进行选择。与测试相比，选择需求的优点之一是，您可以节省一些开发时间，因为开发人员知道他们必须构建什么，如果开发是在手头有额外的时间完成的，您可以将这些时间分配给测试 :)
【讨论】：
测试（功能和集成）比需求更重要；如果你可以指定测试，那么你也指定了要求，至少是隐含的
cmets 也是开发人员文档，单元测试是“快速入门”示例；-)
【讨论】：
不确定需求是被称为人工制品还是流程。尽管可以将需求作为人工制品跳过，尤其是对于较小的团队并仍然交付产品，但作为流程跳过需求是没有问题的。作为人工制品的需求使您能够以低于构建整个事物的成本对系统进行建模，进行可行性、估计，并让一个更大、更分散的团队减少通信开销并在脚下建立共同点。忽略要求，你会得到糟糕的估计（不管你是提前计划了很多还是只是做一个短的冲刺），对可行性的想法很差，沟通可能非常低效，还有很多沟通不畅。
另一方面，需求作为一个过程将存在，无论它是否被正式承认。你不能真正排除它，你可以假装需求过程不存在，或者集成到设计、编码、测试或直到试点和维护阶段。显然，以这种方式处理流程意味着它不会得到相当多的关注和资源。后果通常从交付最终无用的东西到必须在开发周期后期修复产品现在明显的缺点，甚至在产品在现场失败后发现真正的需求，增加开发成本，拖欠最后期限，毁了团队的好名声，破坏了用户的信心等等。
测试通常归结为验证和验证，最近测试技术的改进使自动化测试成为一种可靠的工具，可以提高调试效率并减少回归测试所需的时间。验证是确保团队构建了正确的产品，即范围要求是正确的、不矛盾的并且没有差距。另一方面，验证是确保产品构建正确：没有技术缺陷、意外错误等。
正如我们所见，测试在忽略需求的情况下提供了一个安全网。通常，当团队开始测试时，他们需要完善对需求的理解，从而修改软件。由于需求人工制品和软件本身都代表了对现实生活问题的解决方案进行建模时不同级别的保真度，并且软件作为模型的数量级更精确，因此应用程序的测试也可以评估需求（无论它们是隐式的还是显式的） ，正式分析或非正式沟通）。
通常，测试的替代方法是让用户报告大量的缺陷和缺点，并尝试将它们作为维护的一部分进行修复（意味着在产品生命周期的后期），从而增加每次修复的成本。
那么需求与测试？解雇经理。好的，如果您希望项目进度在测试阶段滑落，并让自己陷入构建不是用户需要的混乱之中，请跳过需求，如果您只是需要完全不尊重您的用户，请跳过测试。
【讨论】：
没有要求，您不需要测试，因为您最终得到的正是规范的内容
【讨论】：
有些类别的软件可以在没有要求的情况下完美开发，至少比电子邮件长度模糊表达的想法更重要。
问题是，如果您有特定的客户和项目经理，那么您的软件不太可能包含在其中之一中。不太可能有人专门付钱给你，比如“让我做一个涉及杂耍猴子的有趣游戏”。
唯一可以无需测试即可开发的软件类别是故障软件：无论软件是否有效（或者如果您有一个真正愚蠢的客户），您的公司已经设法吸引一些客户付费，如果它不起作用，则支付更多的支持和维护费用）。
这可能更有可能：合同的结构使得成功的利润低于失败的利润仍然相当普遍。如果您认为是这种情况，并且您想开发可以工作的软件，那么请考虑换一份您的兴趣和老板对立的工作。
【讨论】：
如果没有需求，我们可以制定测试计划吗？因此，即使我们选择测试而不是需求，我们也无法进行测试。
因此，即使您考虑敏捷测试环境，也应该优先考虑需求。
【讨论】：