这篇文章是reddit上关于质量保障讨论的比较多的帖子，我把它转为中文版，供大家交流学习，由于直接用的翻译软件以及截图，大家凑合看下哈。
让我非常清楚地说明一下——自动化检查并不是真正的“测试”？编写自动化检查确实很重要——但编写自动化测试代码和框架与成为“软件测试/质量专家”是完全不同的两回事。我们应该停止称其为“自动化测试”，而应称之为“自动化检查”。
因为这种“如果我们自动化一切，那就没问题”的想法，导致了20亿美元的Crowdstrike漏洞以及其他许多对纳税人造成巨大损失的情况。不，这并不正确。实际的测试需要人类的参与。如果没有人类参与，那就不是测试。因为自动化工具太笨了，无法发现哪里出了问题，因为它只被设计用来检查几件事情。至少目前，没有人能用工具的自动化检查来替代人类的认知能力。
正如软件测试行业专家迈克尔·博尔顿所说
“测试是通过经验、探索和实验来评估产品的过程。这包括一定程度上的提问、研究、建模、观察、推断等，目的是发现产品的真实状态或系统。”
测试人员不会看到令人赏心悦目的演示就大声叫好“太棒了，太棒了！” 当我们周围的每个人都被炫目的效果、分散的注意力和坚定的“一切都很好”所迷惑时，测试人员必须在专业上持怀疑态度。在我们看来，测试是从一个前提开始的：产品中存在其他人没有注意到的问题风险，因为“项目中的其他人都没有把调查潜在问题作为自己的主要职责”。
这就是为什么在项目和组织中拥有经过培训、能够像测试人员一样思考的人员非常重要的原因。如果你不专注于寻找问题，那么问题就会乐意来找你……或者你的客户。
是时候让组织机构认识到这一点了，不要再把管道中的愚蠢的绿色自动化检查作为释放软件的信号了。更有趣的是，有人认为API测试足以证明软件质量。这真是太可笑了，太愚蠢了。API测试的好坏取决于编写和确保合同更新等工作的人员。除了API返回正确值之外，还有1000种可能出错的情况。
你有没有听说过汽车制造商解雇质量部门，只依赖自动化检查来保证产品质量的情况？有趣的是，有些零售公司有专门的质量部门来检查硬件产品，但在零售软件开发方面，他们却只依赖Jenkins管道来保证质量。真是疯了！如果你不投资于质量，那么开发者将不得不花费更多的时间来修复bug，从而导致客户满意度下降甚至失去客户。
往期系列文章
