软件测试耗费时间和资源是事实。可以从不同的角度观察软件的测试。可以根据我们测试的内容来划分。例如，项目中的每个可交付成果，如需求、设计、代码、文档、用户界面等，都应该进行测试。
此外，我们可能会根据用户和功能要求或规范对代码进行测试，即黑盒测试。在此级别，我们将代码作为黑盒进行测试，以确保程序预期的所有服务都存在、按预期工作且没有问题。我们可能还需要测试代码的结构，即白盒测试。测试也可以根据测试中的子阶段或活动来划分，例如，测试用例生成和设计，测试用例执行和验证，建立测试数据库等。测试确保开发的软件最终没有错误。但是，任何过程都不能保证开发的软件 100% 没有错误。
尽管手动测试存在各类的问题，但即使在大型项目中，也不可能用自动化测试完全取代它。UX、可用性、探索性等测试需要人为介入，因为自动工具无法完全模仿用户行为。自动化测试也不适用于安全测试。自动漏洞扫描需要后续手动检查，因为它会提供许多误报信息。
在当今的现实场景中，应用程序会根据用户反馈、网络流量（性能/负载）等频繁发生变化。因此，要想在竞争中保持领先，就需要创新、升级和增强产品质量，使一切自动化变得具有挑战性。
自动化测试并不是精确的测试；它正在检查事实。检查是程序可感知的；测试需要感知。测试（手动）需要人类对可用性做出合理的判断。我们可以在意想不到的时候注意到异常情况的发生。此外，在实施测试自动化解决方案时还有其他相互关联的开发活动，而不仅仅是编写测试用例脚本。
通常业务会开发一个框架来演示测试用例选择、报告等操作。框架的开发是一项艰巨的任务，需要熟练的开发人员，并且需要时间来构建。此外，即使有一个功能齐全的框架，编写自动检查脚本也比手动执行相同测试花费的时间更长。
企业花费大量时间使用最佳工具和实践来开发完美的测试自动化解决方案，但如果自动化检查对团队没有帮助，那也无济于事。我们不应该以取代手动测试为目标，而应该拥抱它对团队的优势。例如，自动化测试有助于解放测试工程师的时间来进行更多的探索性测试，并发现更多的潜在的缺陷。
团队通常希望尽可能自动化更多的测试场景。但当他们遇到各种问题时，这又回来困扰着他们。团队应该分析他们希望自动化的测试用例类型，以及不能自动化或不应该自动化的案例。团队不应该仅仅为了测试而自动化测试。例如，如果将需要大量维护的一整套测试自动化，那么你将投入额外的时间，而从投入产出比来讲，这些通常意味着浪费。
让我们看看最可行的自动化测试场景：
问题的症结在于敏捷团队不再进行测试。由于 DevOps 等开发实践和文化，手动测试已经失去了优势。QA 领域存在鸿沟：可以编码的人和不能编码的人。大多数测试人员现在都在努力跟上自动化需求。在每个冲刺中都有自动化测试的压力，并且没有足够的时间进行彻底的探索性测试。
敏捷开发中的问题是测试人员采用用户流程并自动化其验收标准。但是，在这样做的同时，他们主要且唯一的关注点是与他们有限的编码技能作斗争以通过测试。
大多数人相信新的技术解决方案将挽救局面。测试工具也不例外！我们不能否认现在的工具几乎可以解决我们目前在测试自动化中面临的所有问题。然而，这种不切实际的乐观主义也会导致不切实际的期望。无论工具多么有能力，如果管理层的期望不切实际，它就不会达到期望。
不要仅仅为了测试而自动化测试。相反，在这个过程中多加思考，研究产品的高层和底层架构。在整体测试方法中采用基于风险的自动化方法。例如，发生故障的可能性有多大，故障的影响是什么？如果答案很高，这些场景应该自动化并在每次构建时执行。
仅仅因为测试工具没有发现任何缺陷并不意味着软件没有缺陷。重要的是要了解，如果测试包含缺陷，它们将带来不正确的结果。自动化测试将无限期地保留那些不令人满意的结果。需要定期对自动化用例巡检、评估，维护自动化用例库的有效性和及时性。
一个严重的问题通常会泄漏到生产中，因为没有人考虑过特定场景。执行多少自动化测试并不重要。如果一个场景被忽略，就会出现一个错误，根据墨菲定律，即如果某事可能出错，它就会出错。所以那些自动化测试忽略掉的测试场景，需要手动测试重点覆盖。
多数测试自动化工程师花时间与自动化代码作斗争，并让测试在现代软件开发中发挥作用。他们几乎不专注于适当的测试和探索系统。通常团队最终会执行大量的自动化测试发现很少缺陷，但探索性测试会发现大部分错误。团队应该基于风险评估来选择要自动化的内容。