刚开始测试自动化？ 不要犯这个错误
我经常与一些客户打交道，他们的测试自动化能力要么刚刚开始，要么正在努力成长，而且他们常常都犯同样的致命错误。
虽然他们可能了解测试自动化的基础知识，但是他们仍然认为脚本化测试的价值在于通过自动执行脚本而不是手工执行来节省时间。他们的理由是，如果自动化脚本执行速度比人类执行速度快，那么最大的效率收益应该来自于自动化运行时间最长的测试。
如果执行时间是衡量价值的唯一时间，那么他们是对的。
但是测试执行时间只是一个与时间相关的问题。您还需要考虑编写自动化测试所需的时间，以及学习如何编写测试所需的时间。
当团队将大型测试简化为更小、更短的测试时，他们更容易取得成功。你可以从这个非直觉的想法中获益。
留时间学习
蹒跚学步的孩子在学会站立之前先学会平衡。他们先站后走。程序员每次学习一门新的编程语言时都要会写“Hello world”。
学习自动化的团队可能同时通过几个学习曲线:编程语言、编程概念、测试自动化工具或框架、源代码管理，以及软件项目上的协作。
每次您添加并行学习目标时，您就需要花费更多的时间来熟练掌握。
最近，当我在一家大型保险公司计划向测试自动化的重大过渡时，我意识到仅仅是“条件”这个概念就可能需要人们几天或几周的时间来消化。
回想大学时，我们花了整整一周的时间在条件反射上。现在很难相信。这个概念对我来说太基础了，看起来很简单。但不是给那些从未接触过它的人。
请记住，学习一个概念所花的时间比您想的要容易得多。
很多时候，公司希望人们在一周内学会编码并立即开始产生良好的测试自动化。 太疯狂了 为什么我要花一周的时间来学习大学中的“ ifs”和“ elses”，但是一个没有背景的人只有一个星期的时间来学习他们进行基本编程所需的所有工具？
这里的教训是:保持测试简短，以便您的员工被迫学习更少的概念。这将加快学习和工作效率。
增长势头
这是强大的测试自动化工作中最容易被忽视的因素。 一个团队要么停滞不前要么动弹。 如果前进，甚至一点点，您的旅途情况都会更好。
为什么不先迈出一小步呢?为什么不从一个小测试开始，作为你的人写的第一个?作为新功能的第一个小测试?在你的API测试中，一个简单的GET请求到一个新的端点?
等待完美的工具选择，完美的用例，完美的资源集合不是进步。它是静止的。这种零动量，静止不动的缺乏鼓励了更多的同样的事情。
“完美”常常是“足够好”的敌人，“足够好”在前进，获得动力，在一个方向上增加动力。一个“几乎正确”的小测试，即使是在一个稍微错误的方向上，也可以修改和纠正。
让您的团队通过先编写小测试来体验进展、动力和小胜利。
建立心智分享
当您的人员处理长时间运行的测试用例时，这些测试用例可能包含更复杂的场景。当新测试自动化的人们花费精力学习复杂的场景而不是创建测试自动化时，他们的大脑会因为有限的精力而波动。
当您将您的思想集中在测试自动化的机制上时，您将更快地学习测试自动化。当您为复杂的业务逻辑做这些时，您将更快地学习复杂的业务逻辑。
学习测试自动化的团队应该首先关注学习测试自动化。当您学习自动化技能时，不要让复杂的业务逻辑支配您的思维。把那些长而复杂的测试留给那些更有技巧的人。
我们不会要求新音乐家和其他人一起演奏，在舞台上表演，同时学习一首新曲子。我们不会要求一年级的学生做代数运算来计算出他们在排队等午餐时的变化。因此，让我们对那些测试自动化的新手进行同样的思考:让他们编写简短的测试。
测试人员必须一次学习多种技能
测试用例越长，编写它的人就越有可能需要自动化工具中更复杂的功能。
学习时，必须首先学习基础概念（语法）。 以后，您将在这些基础上建立并联系起来以学习更多高级技能（逻辑和修辞）。
测试用例越长，您的新自动化人员就越有可能需要学习更多技能来完成测试。 这减慢了进度并激励了人们。 这也延迟了人们在完成测试用例时所获得的奖励。
这种感觉或奖励很重要。 这就是许多程序员继续进行编程的原因，即使他们正在从事的工作很困难。
因此，请缩短测试时间以减少自动化程序必须学习的技能。 他们必须学习很多技能，但不需要一次全部学习。
自动化是一种软件开发活动
测试自动化是一项软件开发活动，很难学习编程。 即使使用无代码工具，测试人员也可以迅速找到工具的局限性，并且必须学习更困难的概念。
我们有许多充分的理由将Scrum团队中的故事缩小。 同样的原因也适用于您自动化的测试。 您的自动化应该是冲刺中的任务或故事。 就像其他故事一样，您应该将它们缩小，以便可以评估进度，对其进行迭代并获得反馈。
如果您没有获得有关自动化如何帮助测试人员，开发人员和产品所有者的反馈，那么您正在开发的软件可能对任何人都没有好处。
从小处开始，收获好处
编写较小的测试有很多好处：更快地学习，更快地做出贡献，创造前进的动力并获得更频繁的反馈。 也更有趣。 因此，从小处着手，然后从那里开始。
