如何应对自动化反对者？

#1 楼

我绝对感到你的痛苦。正如我曾经提到的一个问题（我将在稍后链接）中提到的那样，我也为一家10位收入的公司工作，我们的主要软件针对0百万行生产代码进行了0次自动化测试。

可以归结为许多开发人员使用外部库而不是滚动使用自己的库的相同哲学：我们担心自己未创建的库。我们只是不信任我们没有编写的测试，我们没有编写的库以及我们没有创建自己的工具。

我曾经有一个老板（有点自我） -令人赞叹不已-但您无疑是个聪明人。 ”我并不一定要把他的想法发挥到极致，他认为您必须每周花80个小时来辛苦工作一个月才能完成新软件。但是我确实相信我们需要做一些英勇，大胆而又高贵的事情，才能在公司环境中完成任务。继续制作它们。鼓励开发人员对其编写的某些新代码和发现的新错误也进行一些简单的自动化测试。这将需要几个月的耐心，但是最终这些测试之一将捕获一个错误。然后，当他们看到此测试工具的有效性时，他们将开始意识到它毕竟不是那么邪恶。很快又发现了另一个错误。还有一个。还有一个。然后，在季度/年度审查中，您可以说“由于能够进行自动测试，我们能够停止X数量的错误，从而为我们节省了大约T个小时的测试/开发时间。想象一下，如果我们拥有更多的产品，我们可以节省多少？测试覆盖率？“

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

关于寻找另一份工作：这应该总是摆在桌上。如果您不受合同约束，我不明白为什么聪明的开发人员不会每2-3个月更新一次简历，以防万一。管理上的一次转变可以使梦想发展商店变成沉闷的汗水商店。如果您在一年内获得零牵引力，我会鼓励在其他地方找工作。如果您能够减轻小组成员与任何阻碍您的小组之间的紧张关系，那么双方的情况都会更好。我并不是说您必须全力以赴，但例如，在我的工作中，一些来自应用程序支持和开发人员会在夏季的星期三去玩飞盘。仅一两个小时，但是当您第二天看到他们在工作时，即使您必须提供一些困难的消息，也可以轻松完成。

关于建立团队之间的信誉和关系的说法。

#2 楼

我认为您需要了解他们为什么被拒绝。可能是您已经进入了办公室政治的毒蛇坑，并且想知道为什么要这样做，因为在您的职位描述中没有写上爬虫学。

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


为什么要更改？我们一直都是用旧方法来做的...


当然，旧方法是可行的，但是我们已经看到了不变的公司会发生什么-它们已经灭绝。


*为什么现在呢？”


我们必须开始一些工作。管理部门已将我的工作许可给我。 >

不能解决所有问题


不能解决所有问题自动测试将有助于确保测试的一致性以及确保先前发现的一致性错误不会在将来的版本中返回。


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


对于某些人来说，每一次讨论是一场口头比赛，需要有人获胜，而对手被击败。演示可以表明自动测试解决了一些困难（或“肮脏”或只是平淡的不愉快）的问题，将有助于解决这些问题。 “我什至花了一些时间使一个简单的应用程序几乎自动化整个QA流程，只是为了让QA负责人使用外包的QA测试人员来测试它！”给我的感觉是，他们知道并且不想被证明是错误的。有些人以为自己被证明是错的。对自己的评判；您向他们展示了他们在这种情况下是不正确的，因此在所有其他情况下都是错误的。与这些人打交道的唯一方法是花一些时间阅读Suzette Haden Elgin撰写的系列书籍，这些书籍的标题中带有“言语自卫的温柔艺术”。


谈话很便宜！我来自密苏里州，告诉我！


这些人可能会受到示威活动的影响（请参见前面的段落），而参与对话战争的人则不会受到示威活动的影响。


繁琐的工作


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


我们已经尝试过此方法...


是的，时间和技术已经改变。到那时，现在我们可以执行X，Y和Z了。


用鲱鱼砍伐这个森林！


回到开始，学习办公室政治是一项至关重要的技能。除了保持幽默感。学习办公室政治是一项令人讨厌的任务，但是必须掌握它，否则您的额头也可能会纹身。


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


我们想假装我们是在精英统治下运作，在这里您做的事情比您认识的人更重要，而我们在这些方面的共同努力使公司变得更好地点。世界不公平。因此，要学习办公室政治，而不是让您玩弄他们并虐待他人。但是您可以像芦苇一样弯曲，并利用对手错误定向的能量来打击他们。

#3 楼

似乎管理层与质量保证团队之间存在脱节，尽管在完成工作后，如果质量保证负责人正在外包，我无法告诉管理层正在购买什么。交流可能会有所帮助，但应该自上而下进行交流。

尝试从质量检查团队中找出问题所在，他们担心自动化会导致他们失业吗？还有吗与苦恼这个问题并想知道为什么他们不听话相比，了解他们的立场将为您提供更好的帮助。您必须说服他们，您正在做的是帮助他们，将其卖给他们，他们会加入您的行列，而不是反对您。请记住，这些人是您团队中的人，或者您需要与他们一起工作，如果您正在为他们而建，他们也是客户。在午餐时与他们坐下，结识他们，然后试着找出他们的来历。门是关于我一天的消极情绪，然后是离开的时间。如果我可以进来并且仍然认为自己在做一些有趣的事情，那么我会留下来并尝试解决问题。

#4 楼

在诸如“这些家伙被困在自己的方式中”和“我已经尝试过演示文稿/演示文稿等以使我的观点无所适从”之类的评论栏之间阅读时，“很多人不知道如何[有效]”-您在这里碰到的地方，就好像您主要是在告诉他们自动化将是多么出色，而不是一开始就表明您确实有兴趣倾听他们，了解他们的工作，并了解他们的问题。

这是一个公平的评估吗？

如果是这样，那么您就需要解决一个信誉问题。如果没有解决正确的问题，自动化的程度有多大都没关系。而且，如果您无意间给人留下了深刻的印象-即使您从未明确地说过-您是对的，而他们只是愚昧无知和无所事事-那么哇，您需要谦虚让别人听你说现在。另外-您是否真的认真考虑过它们可能是对的？

MichaelF的建议很不错：结识人们，与他们共度时光，了解他们来自何处-但是您回答说：“也许是时候再来一次演示！”。没有！停止演示了！你已经做到了！不止一次！没用！

忘了经历管理。您知道他们与正在发生的事情断开了联系。接受迈克尔的建议，与他们一起吃午饭。在他们测试时与他们坐在一起，注意他们最抱怨的是什么，让他们沮丧的事情-不要以为您觉得无聊的东西与他们觉得无聊的东西是一样的。停止尝试使“整个QA流程”自动化，即使那是可能的（如果您可以使思考，分析，探索，学习和设计自动化，那么您应该从AI中赚取数百万美元）。从计划开始，只是要了解人们所遇到的问题，而要阻止自己过早提出解决方案。

尝试找到实际上没有测试的很小的问题-也许有一些繁琐的数据设置需要做，并且您认为可以编写一些非常简单的方法来帮助解决问题-但不要着急去做-首先多问一遍，以确保您了解问题，并且同样重要-向他们表明您正在努力首先了解问题-并询问他们是否会有所帮助，他们会如果您只花了半个小时敲了一下快速的小工具，那会非常介意一下吗？使其小巧，低调，并且可以解决当前的问题。

#5 楼

人们必须充分利用自动化的实质利益。人们很少无缘无故地拒绝使事情变得容易。测试运行起来有多容易？结果容易解释吗？这些问题对您来说似乎很小。对于从未接触过自动化的测试人员，此学习曲线可能比较陡峭。结果，对于质量检查人员来说，简单地外包似乎更为容易。

证明自动化的工作原理。与手动测试工作并行运行测试。当您可以证明测试自动化发现了一些手动测试迭代发现的相同错误时，很难与之抗辩。最初，您可能需要自己动手做。最终，您可能会发现测试人员开始依靠您的脚本来捕获那些悬而未决的bug，而使他们专注于更复杂的测试。

#6 楼

我认为，“说服”反对者的好处的唯一方法是向他们展示现实生活中的实时信息。做吧一直进行一次测试。在许多环境和场景中对其进行测试，以证明其有效。

软件已转向敏捷。对于我们大多数人来说，很高兴。 CI / CD是一个重要目标。没有测试自动化，后者将无法工作。开发人员喜欢单元测试。 API测试。这些的主要障碍只是时间。开发人员可以轻松应对无头测试。

UI测试自动化拥有自己的历史。成功的UI测试自动化的第一大障碍就是这段历史。我们中的许多人已经看到这种自动化尝试不断失败。但是不知何故，我们会错过这些失败所带来的教训。

https://www.stephaniestowe.net/成功

查看此信息是否适用。

#7 楼

如果好人的方法不起作用，请尝试以下操作：

如果可能的话（如果不是全部的话）巧妙地自动执行应用程序。

请他们来对应用程序进行每日回归（完整运行），并坚持要快速获得结果。当测试套件变得越来越复杂并且通过重复进行相同的测试而开始变得脑筋急转时，然后运行测试脚本并向他们展示如何完成。

#8 楼

也许这对戴尔·埃默里（Dale Emery）的动机会有所帮助

http://cwd.dhemery.com/2005/05/motivation/

--- Michael B.