Muhammad Saad在LinkedIn上发布了一个有趣的场景，我将在下文用斜体字引用它，并对此进行评论……
想象一下你作为测试人员第一天上班的情景。你被要求测试一个应用程序。这是一个包含数百个表单和数千个报告的ERP应用程序。你开始进行探索性测试，打开了一个包含大约50个字段的表单。
你尝试在这个表单中输入随机数据，这大约花了20分钟。然后你点击提交按钮。哇！显示了一条错误消息，看起来像是一个未处理的异常。你感到非常高兴，自豪地记录下步骤，并在缺陷管理系统中报告了这个bug。你的努力得到了回报，你感到非常自信，干劲十足。你继续测试，直到当天结束，并发现了更多的bug。你不禁感叹：第一天真是太棒了！
这样的第一天确实不错。作为测试人员，你的前几天甚至前几周都充满了学习。而学习的一个重要部分就是研究被测产品。要想做好测试，你必须对产品有足够深入的了解。你可以通过多种方式获得这种能力，但通过直接使用产品来进行有趣和开放的探索过程，我在RST（Rapid Software Testing）中称之为“调查测试”，可能会比其他方式都更有效。
接下来是第二天，开发人员修复了问题并发布了一个新版本。你用同样的步骤测试了同一个表单，发现bug已经修复。你将其标记为已修复。太棒了，你通过发现该错误，为产品质量做出了贡献，随着错误被修复，产品质量也得到了提高。
在这一天里，还有很多其他事情要做。你可能没时间去验证bug修复。也许其他人会去验证，也许可以等等。你有很多东西情要学习和测试。尽管如此，在第二天验证修复还是有可能的。
我的测试经验越丰富，我对“为质量做出贡献”的兴趣就越小。我的兴趣在于对产品进行全面的监控，以便没有任何问题能够逃过我的法眼。我发现质量本身就是一个分散注意力的概念，但我理解，很多人都乐于把产品做得更好。到目前为止，Muhammad的故事还不错。
第三天，开发人员又发布了新版本。现在，你又要测试该表单，确保没有任何回归问题。同样是 20 分钟。现在你觉得有点无聊了。
同样的 20 分钟吗？感到无聊吗？不对，两个问题答案都是不。不是同样的 20 分钟。我每次测试的方式都不一样。我会扩展和改变数据。我会考虑可能帮助我生成更好数据的工具。我可能在与比我更了解产品的人交谈（如果这是一个成熟的产品，那么我肯定不是第一个测试它的人，如果它不是一个成熟的产品—它怎么可能已经有了数百个表单和报告呢？） 现在才是第三天，对于像 Muhammad 描述的这样复杂的产品，还有大约 200 天的密集学习等待着我。
我并不无聊。我致力于寻找更巧妙的测试方法。我正在学习这项技术的功能、操作和技术细节。这么短的时间就感到无聊的人，很可能不是热爱测试或对测试非常了解的人。测试并不仅仅是按下按钮和检查输出结果。测试是一种不断运用判断力的过程，你需要收集证据并从中理解其意义。
如果你不断重复一开始的那种浅层次的测试过程，那么我猜你很快就会感到无聊。但是我的测试会随着时间的推移变得更加深入，直到达到一定程度，然后随着我学会准确地知道在哪里进行关键观察，它在策略上又会变得更简化。
Muhammad可能是在简化这个故事，以便更清楚地表达他的观点。也许当他说“第三天”的时候，我们可以认为他指的是“第 20 天”，并对他的说法保留一定的怀疑态度。
现在想象一下，从现在起的一个月内，新版本会不断发布，而每发布一个新版本，你都必须测试这个冗长的表单以及其他 100 个类似的表单，只是为了确保回归没有问题。
现在你感到愤怒，感到疲倦。你开始跳过一些步骤。你只填写了50%左右的字段。你的准确性不一样了，你的精力也不一样了，毫无疑问，你的步骤也不一样了。
然后有一天，客户在同一个表单中报告了同样的错误。你觉得自己很可怜。你现在感到没有自信。你认为自己能力不足。管理者都在质疑你的能力。
我有个事情要告诉你：这是90%的测试人员的故事，他们在测试中没有使用代码/工具。
也许 Muhammad将他对测试过程的不满投射到了其他测试人员身上。我认为他对其中一些测试人员的看法是对的。确实，有些测试人员可能会感到愤怒、无聊和疲惫。但我强烈反对他的观点适用于那些热爱测试、研究测试并以此为职业的人。
回归测试是由回归风险驱动的。如果没有回归风险，就没有必要重新测试。因此，回归测试的负担比他说的要轻得多。除非开发人员完全失控、不计后果，否则回归风险不会很高。旧的 bug 很少会重新打开；产品的稳定区域也不会像罗马省的叛乱分子一样突然地爆发出 bug。通常更重要的是进行主流程测试，因为它能发现长期存在的错误。
此外，重新测试并不是完全重复第一次所做的工作。最好在测试中引入大量变化。这可以帮助你发现新的错误，以及那些你可能在第一次测试中遗漏的bug。
如果你对自己没有信心，这对一个新的测试人员来说是正常的。经验丰富、训练有素的测试人员知道“测试是困难的”，并将他们对进度的期望保持在一个合理的水平上。即使你能力超群，管理者也会质疑你的能力，因为这些管理者可能并不是专业的测试人员。他们并不清楚测试是如何工作的。他们可能有一些模糊的想法，认为所有的测试都应该自动化。
然而，测试本身是无法自动化的。可以自动化的是某些固定的输出校验。我同意Muhammad的观点，自动化在大多数项目中都很重要，尽管我通常发现自动化最好由工具专家在测试人员的建议下完成，而不是由测试人员自己来完成。你必须始终牢记自动化能做什么和不能做什么，以及体验式和交互式测试（很多人称之为“手工”测试，但我认为这个词是侮辱性的，也是不准确的）能够发现自动化永远无法发现的错误。
回归问题是最令人痛苦的问题。我们是人类，无法每天都以同样的精力、速度和准确度做同样的事情。这是机器的工作。这就是为什么我们需要自动化。
回归的bug并非最令人痛苦的bug。最令人痛苦的bug是那些对用户造成最大伤害的bug。与“回归”相关的bug并没有表明这样的 bug 特别严重。我想找到每一个严重的bug。
Muhammad在重复一个老掉牙的事情，而我在25年前的文章《自动化测试的误区》中首次攻击了这个观点。他似乎认为机器可以复制人类的工作。事实并非如此。他似乎认为自动化的创建和维护成本不高。实际上，它相当昂贵，尤其是相对于它能发现的bug数量而言。
我重申一下：我认为在每个项目中都要考虑自动化；对于某些项目来说，它绝对至关重要。但这也需要相当多的工作量。很容易创建许多低价值的检查项，而这些检查又必须随着产品的变化而维护。Muhammad 所描绘的是一个人手严重不足的项目，而且显然已经很长时间没有测试团队了。解决测试问题需要时间，管理层必须要有耐心。
绝不能让自动化本身成为一种痴迷。我个人有很多关于编写工具的经验（我的职业生涯是从开发人员开始的，我喜欢编写代码来帮助测试），也时常沉迷其中。但我知道，我需要身边的人帮助我保持客观的视角。
作为一名专业的测试人员，我的工作涵盖测试策略、测试文档、测试执行、开发测试数据库、开发测试工具、配置测试平台、报告缺陷、倡导可测试性、学习产品以及理解用户。我正在从事许多有趣而具有挑战性的工作！自动化只是我所面临问题的一小部分。
