Я часто работаю с клиентами, которые либо только начинают, либо пытаются развивать свои навыки в автоматизации тестирования, и чаще всего все они совершают одни и те же фатальные ошибки. Хотя они могут понимать основы автоматизации тестирования, они по-прежнему считают ценность скриптовых тестов экономией времени за счет автоматического выполнения сценариев, а не вручную. Они считают, что если автоматизированные сценарии выполняются быстрее, чем это могут сделать люди, то наибольший выигрыш в эффективности должен быть достигнут за счет автоматизации самых длительных тестов. И если бы время исполнения было единственным временем для оценки, они были бы правы. Но время выполнения теста — это всего лишь одна проблема, связанная со временем. Вам также нужно подумать о времени, необходимом для написания автоматизированных тестов, и о времени, которое вам нужно, чтобы научиться писать тесты.  Команды добиваются успеха чаще, когда они перерабатывают большие тесты в меньшие, более короткие. Вот как вы можете извлечь выгоду из этой не интуитивной идеи. Малыши учатся балансировать, прежде чем они смогут встать. Они стоят перед тем, как научатся ходить. Программисты пишут «Hello world» каждый раз, когда изучают новый язык программирования. Команды, обучающиеся автоматизации, могут проходить через несколько кривых обучения одновременно: язык программирования, концепции программирования, инструмент или фреймворк автоматизации тестирования, управление исходным кодом и совместная работа над программным проектом. Каждый раз, когда вы добавляете параллельную цель обучения, вы увеличиваете время, необходимое для оттачивания мастерства владения языком.  Недавно, планируя глобальный переход к автоматизации тестирования в крупной страховой компании, я понял, что только понятие «условные операторы» может занять у людей дни или недели, чтобы усвоить. Вспоминая колледж , мы потратили целую неделю на условные операторы. Сейчас в это трудно поверить. Концепция настолько фундаментальна для меня, что кажется простой. Но это не так для того, кто никогда не обучался этому.  Помните, что время, необходимое для изучения концепции, гораздо легче недооценить, чем вы думаете. Часто компании ожидают, что люди научатся программировать за неделю и немедленно начнут производить хорошую автоматизацию тестирования. Это безумие. Почему мне дается неделя, чтобы узнать об «ifs» и «elses» в колледже, но человеку без опыта дается всего одна неделя, чтобы изучить все инструменты, необходимые для базового программирования? Урок здесь: Следите, чтобы тесты были короткими, чтобы ваши сотрудники были вынуждены изучать меньше концепций. Это ускорит обучение и производительность. Это единственный наиболее недооцененный вклад в серьезные усилия по автоматизации тестирования. Команда либо стоит на месте, либо движется. Если она движется вперед, даже немного, вы находитесь в лучшей ситуации во время вашего путешествия. Почему бы не сделать первый шаг маленьким? Почему бы не начать с небольшого теста в качестве первого, который напишут ваши люди? Небольшой тест в качестве первого для новой функции? Простой крошечный запрос GET к новому endpoint-y в тестировании API? Ожидание идеального выбора инструмента, идеального варианта использования, идеального набора ресурсов не является прогрессом. Это остановка. Это отсутствие импульса — ноль, стояние на месте — поощряет продолжать стоять на месте. Идеальное слишком часто является врагом «достаточно хорошего», которое движется вперед, набирает движение и увеличивает импульс в направлении. Небольшой тест, который является «почти правильным», даже в немного неправильном направлении, может быть изменен и исправлен. Пусть ваша команда испытает прогресс, импульс и небольшие победы, сначала написав небольшие тесты. Когда ваши сотрудники работают над более длительным тестовым сценарием, вполне вероятно, что эти тестовые сценарии состоят из более сложных сценариев. Когда люди, новички в автоматизации тестирования, тратят свою энергию на изучение сложных сценариев, а не на создание автоматизации тестирования, они чувствуют ограниченную умственную нагрузку.  Когда вы сосредоточите свое мышление на механике автоматизации тестирования, вы быстрее освоите автоматизацию тестирования. И когда вы делаете это для сложной бизнес-логики, вы быстрее изучите сложную бизнес-логику. Команды, изучающие автоматизацию тестирования, должны сосредоточиться в первую очередь на обучении автоматизации тестирования. Не позволяйте сложной бизнес-логике доминировать в вашем мышлении , когда вы работаете над изучением навыков автоматизации. Оставьте эти длинные, сложные тесты для тех, кто обладает большими навыками. Мы не просим новых музыкантов играть с другими, выступать на сцене и изучать новое произведение сразу. Мы не просим первоклассников делать алгебру в уме, чтобы выяснить, какую сдачу они получат обратно, когда заплатят за обед. Так что давайте будем так же внимательны к тем, кто только начинает заниматься автоматизацией тестирования: пусть они напишут короткие тесты.  Чем длиннее тестовый сценарий, тем больше вероятность того, что человеку, написавшему его, понадобятся более сложные функции в инструменте автоматизации.  Когда вы учитесь, вы должны сначала выучить основополагающие понятия (грамматику). Позже вы опираетесь на них и соединяете их, чтобы освоить более высокоуровневые навыки (логика и риторика). Чем длиннее тестовый сценарий, тем больше вероятность того, что вашим новым автоматизаторам потребуется освоить больше навыков для его завершения. Это замедляет прогресс и демотивирует людей. Это также отдаляет вознаграждение, которое люди чувствуют, когда они заканчивают тестовый сценарий. И это чувство, или награда, важно. Это причина, по которой многие программисты  продолжают программировать, даже когда они работают над чем-то сложным. Поэтому сделайте тесты короче, чтобы уменьшить навыки, которые автоматизатор должен освоить. Они должны освоить много навыков, но им не нужно изучать их все сразу.  Автоматизация тестирования — это деятельность по разработке программного обеспечения, и научиться программировать трудно. Даже с помощью инструментов, не использующих код как таковой, тестировщики быстро находят ограничения инструмента и должны изучать более сложные концепции. Мы делаем небольшие сценарии в Scrum-командах по многим веским причинам. Те же причины относятся и к тестам, которые вы автоматизируете. Ваша автоматизация должна быть задачами в ваших спринтах. Вы должны сделать их маленькими, как и другие сценарии, чтобы вы могли оценить прогресс, повторить их и получить обратную связь по ним. Если вы не получаете отзывы о том, как ваша автоматизация помогает тестировщикам, разработчикам и владельцам продуктов, вы разрабатываете программное обеспечение, которое, вероятно, никому не пригодится.  Есть много преимуществ написания небольших тестов: вы учитесь быстрее, вносите свой вклад раньше, создаете импульс вперед и получаете более частую обратную связь. Это также веселее. Так что начинайте с малого и стройте оттуда.