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