如果仅在开发之后才开始测试，将会发生什么？

#1 楼

我发现，在我的工作中，等到部署代码后，很难让编码人员重新关注正在测试的功能/问题。

他们已签入代码并移至任务清单上的下一个任务/故事/错误。因此，如果我发现几天前他们从事的工作中存在问题，那么让他们将注意力转移回去就具有挑战性。

开发人员告诉我，我正在处理这种上下文，将其转换回他们认为已经完成的工作具有挑战性。很难恢复到这种思维方式，然后减慢他们在已开始的当前任务上的工作。避免不必要的上下文转移。

#2 楼

最好尽早进行测试（“左移”），因为这样做比较便宜，而且：


实现更快的变更速度，这对于许多公司而言日益重要
启用更快的修复程序，因为上下文对于程序员来说是最新的
启用更高的质量，因为上下文对于程序员来说是最新的
帮助为开发人员带来了测试心态，从而提高了质量
鼓励自动化-距程序员越近，他们越希望实现自动化。
鼓励在设计和测试方面进行前瞻性对话*

也许最关键的是，您会*错过BDD的好处（行为驱动开发）和TDD（测试驱动开发）。
这些技术的优点不仅在于您的测试涵盖了代码。真正的优点是

测试推动易于测试的高质量应用程序代码的开发

一个成熟的开发人员将逐渐了解到，当您第一次编写测试时影响您随后编写的应用程序代码，实际上您最终得到的是不同的应用程序代码-一方面，它被编写为经过测试，并且解决了应用程序代码中最常见的问题-“它不是为测试而编写的！”

*我看到有关测试的10分钟“前期”对话节省了数周的工作

#3 楼

下面是瀑布模型的SDLC阶段的基本概述：

即使我们使用敏捷，devops或其他方法，其基本阶段也保持不变



上述瀑布方法的问题：

等待系统实施以开始测试最终会浪费前阶段的工作。

例如，

假设开发“旅行博客应用”，其中一项要求是能够将照片上传到该应用。开发人员进行了实施，并进行了可用性测试。但是，在可用性测试中，发现用户想要一次添加多个图像，但该应用程序仅支持单个上传。现在，应该重构该开发以包括多个上载并相应地调整框架的大小。

这会浪费时间，金钱和上市时间。

另一方面，如果在需求收集，UX设计以及每个阶段都涉及经验丰富的可用性测试人员。这样，多个图像上传用例就只在初始需求列表中了。

这将导致产品更加集中，快速和优质

最佳实践：

让QA参与了需求收集，UX设计，单元测试，集成测试等各个阶段和级别。首先存在弱点并浪费时间进行重构的设计

#4 楼

如果您不断进行测试，则始终会有可能被发布的应用程序片段。它可能没有所需的功能，但仍然可能是有用且成功的应用程序。您可以对重要的功能进行优先级排序，而丢弃那些功能并不是那么好（或便宜）的功能。您花了一年时间编写了一年的功能，现在您必须测试一年的功能。在测试并解决所有问题之前，您将无法发布任何产品。即使削减一半的功能将是有利的，但在测试阶段您实际上无法承受那样的代价，因为任何这样的削减都会导致破坏有效功能的巨大变化。

这通常意味着连续测试可以为您提供：


缩短上市时间
更好的应对市场变化的能力（惯性较小）
更高质量的产品，因为您避免了急于在最后进行测试和修复的事情，所以管理层可能还没有考虑到这些问题

还有其他好处，您已经提到了其中一些：


解决问题的时间越早，价格可能越便宜。在设计中修复事物比在开发中修复事物要快，而在开发周期结束时修复它要快于修复。您将需要更改更多的代码，做出更多的让步，并且您可能不太记得所有如何以及为何执行操作以及如何正确修复它们。
它鼓励开发人员与测试人员之间进行更持续的互动，这可能意味着更少的“我已经完成工作，现在是您的工作，质量检查员”的态度。它鼓励人们仅在实际验证完成后才将其视为已完成的任务。各个开发人员更清楚应该一开始就应该做的事情所浪费的时间。令人惊叹的警示故事之一来自MS Word开发人员的开发，他们实现了GetLineHeight() => 6;之类的方法。它显然已经坏了，但是您没有时间正确执行事情，并且三个月后您会收到质量检查的反馈，因此您花了一些时间。
它使代码所有权更有价值，因为它允许您可以轻松地与负责变更的人员一起跟踪在任务中出现的所有问题。将您知道的某件事发送给质量检查人员无济于事。这也意味着时间表更加可预测和灵活。

#5 楼

关于您的问题“部署后进行测试时还有哪些其他缺点？”


您提出的问题很适合James Bachs博客问题开发人员应该首先测试产品吗？ James表示，他希望尽快获得用于测试的产品，以避免在测试和编程之间遇到障碍。我认为尽快开始测试（也要在产品可测试之前）对测试人员来说是一件好事，因为每次查看或理解用户的故事/要求时，都有助于我们为测试范围获得更好的想法
有趣的是来自James的“有时产品完全无法使用。即使那样，我还是想要它。仅通过查看其文件和结构即可。我可能会开始获得更好的测试思路” >>>意味着尽快开始测试有助于了解有关创建可能的测试方案/测试用例的想法
此外，通过尽早的沟通，您会与产品负责人，需求经理，开发人员充分了解，...您认识负责此事的人员以及遇到问题时可以举手而不是用“乒乓”的方式发送电子邮件来问问题。这种经验就是我们在项目中所做的。编写要求时（在那段时间里，我们没有引入敏捷的方式，例如乌斯特故事），我们试图从视觉上想象按钮的外观。这有助于我们估算未来的测试范围。此外，我们还与开发人员和需求经理结识，他们感谢我们的工作，因为我们还在早期阶段发现了一些错误。 Lisa Crispin也提供了很好的链接，测试人员和开发人员可以从中学到什么？

除此之外，尽快凝视测试活动会使您的测试人员“可见”。这也是我们公司面临的问题。测试人员不可见。参加会议（例如，要求，站起来等等）时，您可以看到测试活动，人们会更好地了解您。

希望我能为您提供帮助。