我绝对感受到你的痛苦。正如我在一个问题中提到的（我会在一分钟内链接）我也为一家收入为 10 位数的公司工作，我们的主要软件对超过一百万行生产代码进行了 0 次自动化测试。

这归结为许多开发人员关于使用外部库而不是滚动自己的库的相同理念：我们害怕我们没有创建的东西。我们根本不信任不是我们编写的测试、不是我们编写的库以及不是我们自己创建的工具。

我曾经有一个老板（有点自负的你知道什么，但无疑是个聪明人）说“软件是英雄开发的，是凡人维护的，如果你想开发新软件，它需要开发人员的英勇努力。” 我不一定把它带到他所做的极端，他认为你必须在一个月内每周工作 80 小时，才能完成新软件。但我确实相信，我们需要做一些英勇、大胆和高尚的事情，才能在企业环境中完成任务。

所以你能做的最好的事情就是做一些自动化测试。继续制作它们。鼓励开发人员对他们编写的一些新代码和他们发现的新错误进行一些简单的自动化测试。这需要几个月的耐心，但最终其中一项测试会发现一个错误。然后，当他们看到这个测试工具的有效性时，他们会开始意识到它毕竟不是那么邪恶。很快又发现了一个虫子。还有一个。还有一个。然后，在季度/年度审查中，您可以说“由于自动化测试，我们能够阻止 X 数量的错误，为我们节省了大约 T 小时的测试/开发时间。想象一下，如果我们有更多，我们可以节省多少测试覆盖率？”

你需要耐心。如果您没有自动化测试，那么应用程序很可能不适合自动化。这意味着即使创建了测试，您也将面临一场艰苦的战斗。但值得一战。

关于寻找另一份工作：这应该始终放在桌面上。如果您不受合同约束，我不明白为什么聪明的开发人员不会每 2-3 个月更新一次简历，以防万一。管理层的一次转变可以将梦想中的开发商店变成惨淡的血汗工厂。如果您在一年多的时间内获得零牵引力，我会鼓励您在其他地方寻找工作。

编辑：我忽略了一些非常重要的事情。如果你能够减少你的团队和任何阻碍你的团队之间的紧张关系，那么双方的情况都会更好。我并不是说你必须把你的一生都奉献给他们，但是例如在我的工作中，一些来自应用程序支持和开发的人会在夏季的星期三去玩飞盘。只是一两个小时而已，但当你第二天在工作中看到他们时，即使你必须给出一些困难的消息，它也会变得更容易。

testerab对这个问题的回答对建立团队之间的可信度和关系有一些很好的看法。

我认为你需要了解他们为什么反对。可能你已经陷入办公室政治的蛇坑，你想知道为什么，因为爬虫学没有写在你的工作描述中。

您可能从说 NIH（非在这里发明）的骑士那里听到的一些抱怨！可能包括：

为什么要改变？我们一直都用老办法...

诚然，旧的方式是可行的，但我们已经看到那些不改变的公司会发生什么——他们已经灭绝了。

*为什么现在？”

我们必须在某个时候开始。我得到了管理层的批准。

它不会解决一切

没有什么能解决一切。自动化测试将有助于更轻松地确保测试的一致性，并确保以前发现的错误不会在未来的版本中返回。

你错了，这就是为什么...

对有些人来说，每一次讨论都是一场口头上的比赛，需要有人获胜，而对手则需要失败。一个可以表明自动化测试解决了一些困难（或“肮脏”或只是令人不快）问题的演示将有助于解决这些人。你说的部分“我什至花了时间自动化一个简单的应用程序的几乎整个 QA 过程，只是为了让 QA 负责人使用外包的 QA 测试人员来测试它！！”给我一种他们知道并且不想被证明是错误的感觉。有些人将被证明是错误的视为对自己的道德判断；您向他们展示了他们在这种情况下是不正确的，因此在所有其他情况下他们都是错误的。与这些人打交道的唯一方法是花一些时间阅读苏泽特·哈登·埃尔金 (Suzette Haden Elgin) 的系列书籍，这些书籍的标题中有“温和的口头自卫艺术”。

说话便宜！我来自密苏里州，给我看！

这些人可能会受到示威的影响（见上一段），而从事对话战争的人不会受到示威的影响。

工作量太大

自动化需要时间来设置。一旦创建并设置了脚本，就可以轻松完成。我今天在采访中使用的一个轶事是提到持续集成服务器以及我的上一个雇主如何从拥有一台服务器中受益匪浅（我在这项工作中设置了一台，人们喜欢它，尽管直到我在我的开发机器上设置了一个演示后他们才理解它）。制作安装包的人是个早起的鸟——他的 8 小时工作在下午 3:30 左右结束。开发人员是晚上的人，所以他们会工作到晚上 10 点，但如果有构建，他们无法将安装交给 QA 人员，直到他在第二天 0600 来。对代码运行一些自动化测试将使开发人员能够处理许多已知的错误/问题（并非所有开发人员都会在将代码签入源代码控制之前运行单元测试），这将处理 QA 人员将进行的许多测试每次新构建准备好进行检查时都要做。并不是所有的开发者都安装了相同的东西，有些人会忘记切换到发布版本，所以一致性很可悲，只有几个开发者可以被信任来制作版本（一个产品太脆弱了，唯一的机器可以可靠地构建它是由 2004 年左右退出的开发人员留下的，因此他的机器必须小心维护，直到产品被重写，以便有东西可以运送和销售给客户）。构建机器（又名 CI 服务器）会解决很多这样的问题，以至于它们会在时间的迷雾中被遗忘。所以一致性很可悲，只有几个开发人员可以被信任来构建（一个产品是如此脆弱，以至于唯一可以可靠地构建它的机器是一个在 2004 年左右退出的开发人员留下的机器，所以他的机器必须是仔细维护，直到产品被重写，以便有东西可以运送和销售给客户）。构建机器（又名 CI 服务器）会解决很多这样的问题，以至于它们会在时间的迷雾中被遗忘。所以一致性很可悲，只有几个开发人员可以被信任来构建（一个产品是如此脆弱，以至于唯一可以可靠地构建它的机器是一个在 2004 年左右退出的开发人员留下的机器，所以他的机器必须是仔细维护，直到产品被重写，以便有东西可以运送和销售给客户）。构建机器（又名 CI 服务器）会解决很多这样的问题，以至于它们会在时间的迷雾中被遗忘。

我们已经尝试过这个...

是的，好吧，时代和技术已经改变。那是那时，现在我们可以做 X、Y 和 Z。

用鲱鱼砍掉这片森林！

回到起点，学习办公室政治是一项至关重要的技能。同时保持你的幽默感。学习办公室政治是一项令人讨厌的任务，但必须掌握它，否则你WELCOME还不如在你的额头上纹身。

专家将办公室政治定义为“员工认识并寻求调和他们相互竞争的利益的方式”。

我们喜欢假装我们在精英管理中运作，你所做的事情比你认识的人更重要，并且我们一起努力让公司变得更好。世界不公平。所以要学习办公室政治，不要玩弄他们，虐待别人；但是这样你就可以像芦苇一样弯曲并利用对手的错误能量来对付他们。

阅读诸如“这些人陷入困境”和“我已经尝试过演示/演示等来表达我的观点，但都无济于事”，“他们中的很多人不明白如何[它] 有效”——你来到这里就好像你一直专注于告诉他们自动化会有多棒，而不是一开始就证明你真的有兴趣倾听他们，理解他们的工作，并听到他们的问题。

这是一个公平的评价吗？

如果是这样，那么你有一个可信度问题需要解决。如果它没有解决正确的问题，那么你的自动化有多好都没关系。如果你不经意间给人一种印象——即使你从来没有明确说过——你是对的，他们只是无知和顽固——那么哇，你需要非常谦虚才能让人们听你的现在。另外——你真的认真考虑过他们可能是对的吗？你的方法可能会遗漏一些东西吗？

MichaelF 的建议很好：结识人，花时间与他们相处，了解他们来自哪里——但你回答说“也许是时候进行另一个演示了！”。不！停止演示！你已经这样做了！不止一次！它没有用！

忘记通过管理。你知道他们与正在发生的事情脱节。听从迈克尔的建议，在午餐时与伙计们坐下来。在他们测试的时候和他们坐在一起，注意他们最抱怨什么，什么让他们感到沮丧——不要认为你觉得无聊的事情和他们觉得无聊的事情是一样的。停止尝试自动化“整个 QA 流程”，就好像这甚至是可能的（如果你可以自动化思考、分析、探索、学习和设计，那么你应该从你的 AI 中赚取数百万美元）。首先计划只了解人们遇到的问题，然后阻止自己过早地提出解决方案。

尝试找到实际上不是测试的非常小的问题——也许有一些乏味的数据设置要做，你认为你可以写一些非常简单的东西来帮助解决这个问题——但不要急于去做——多问首先，确保你理解问题，同样重要的是——向他们表明你正在努力首先理解问题——并询问他们这是否会有所帮助，他们是否会非常介意如果你只是花半个小时敲出一个快速的小工具，你看一下？让它变得小而低调，并且可以解决眼前的问题。

似乎管理层和 QA 团队之间存在脱节，尽管如果 QA Lead 在您完成工作时外包，我无法判断管理层在购买什么。沟通可能会有所帮助，但自上而下的沟通应该以外交方式进行。

尝试从 QA 团队找出他们的问题是什么，他们是否担心自动化会让他们失业？还有什么？理解他们的立场比为这个问题苦恼并想知道他们为什么不听对你有更好的帮助。你必须说服他们你所做的就是帮助，把它卖给他们，他们会加入你，而不是反对你。请记住，这些人是您团队中的人，或者您需要与之合作，如果您正在为他们构建，他们也是客户。午餐时和他们坐下来，了解他们，然后试着找出他们来自哪里。

只有你知道它是否值得再找一份工作，通常如果我走进门时的第一反应是对我的一天感到消极，那么是时候离开了。如果我可以进来并且仍然认为我在做一些很酷和有趣的事情，那么我会留下来尝试解决问题。