# Лучшие практики автоматизации

В каждой статье свой топ лучших практик, характеристик хороших тестов и подобного, так что я просто скопировал наиболее полезные на мой взгляд списки.

**7 характеристик отлично написанных тестов**

* **Тест полностью автоматизирован** (очевидно): Иногда попадаются такие тесты, которые автоматизированы не полностью. Самые распространенные причины: либо это очень сложно, либо просто невозможно;
* **Тест повторяем**: тест не ломается, если приложение не поменялось: Это относится к основам генерации уникальных данных. Например, мы тестируем регистрацию. Очевидно, что если не генерировать уникальный емейл, то на продакшене такой тест, скорее всего, не будет работать;
* **Тест заканчивается валидацией**: За исключением случаев, где нужно выполнить действия по зачистке данных и подобных действий, завершение валидацией является лучшей практикой. Это помогает убедиться, что последнее действие прошло успешно;
* **Тест достаточно стабилен, чтобы его использовать в CI/CD**: Если тест регулярно ломается, то он недостаточно стабилен, чтобы использовать его в CI/CD. Так как практически любая компания пытается добиться CI или даже CD, то часто такой тест не просто бесполезен, но даже вреден, так как отнимает большое количество времени и все равно не может использоваться в CI автоматически;
* **Тест очень легко читать**: Мы обычно не пишем тесты в одиночку. Часто это команда людей и нашим коллегам тоже приходится поддерживать наши тесты. Крайне важно, чтобы любой член команды мог разобраться в структуре теста, не тратя на это излишнее количество времени. Даже если мы пишем тесты в одиночку, иногда бывает очень тяжело понять, что тест делает и как, если он не написан специально для облегчения понимания;
* **Тест требует минимальной поддержки**: Пункт очевидный, но не всегда соблюдаемый. Чем меньше мы тратим времени на поддержку, тем больше у нас времени на то, чтобы сделать что-то полезное, как, например, написать больше тестов;
* **Тест работает параллельно с другими тестами и не ломается**: В какой-то момент, особенно для end-to-end тестов, мы сталкиваемся с тем, что прогон тестов занимает слишком много времени, это снижает скорость разработки и приводит к таким эффектам, как неоттестированный патч. На этом этапе мы обычно задумываемся о параллелизации, чтобы ускорить исполнение тестов. Если тесты были написаны так, что они могут быть запущены параллельно в любой последовательности и не пересекаться друг с другом, то это делает задачу параллельного исполнения просто задачей настройки инфраструктуры, а не задачей переписывания тестов.

**Еще десять заповедей автоматизации**

1. **Не автоматизируй только "по тест-кейсам"**

Существует распространенное заблуждение, что тест-автоматизация обязана произрастать из тест-кейсов. Автоматизаторы берут существующие или свежесозданные тест-кейсы и превращают их в автоматизированные сценарии. Это называется "автокафе". В этом подходе может быть смысл, но другие подходы принесут не меньше, а то и больше выгоды. Расширяя определение автоматизации за рамки "тест-кейс - инструмент - тест-скрипт" до "продуманного применения технологии с целью помочь людям выполнять свою работу", мы можем использовать компьютерные мощности для задач, для которых они предназначены, а люди - тестировщики - пусть делают все остальное. К счастью, в большинстве задач, где хороши люди, компьютеры выступают плохо - и наоборот.

**2. Обращайся с разработкой автоматизации, как с разработкой ПО**

Разработка автоматизации - это и есть разработка ПО. Даже если мы используем интерфейс перетаскивания или записи и воспроизведения для создания автоматизации, то где-то под капотом или за занавесом над нашими действиями работает код. Мы должны начать обращаться с автоматизацией как с разработкой ПО, иначе мы окажемся с чем-то неподдерживаемым на руках, и проект умрет, едва родившись. Подход к автоматизации как к разработке ПО означает, что мы должны учитывать большинство (если не все) процессов и видов деятельности, требуемых при разработке ПО. Включая:

* Дизайн - мы должны решить, что внедрять и как это делать, чтобы это было поддерживаемым и пригодным к эксплуатации.
* Внедрение - надо написать код.
* Хранение - код и его артефакты должны где-то храниться.
* Тестирование - тестировать тесты? Естественно! Мы должны быть достаточно уверены, что автоматизация ведет себя так, как нам хочется. Если мы не доверяем автотестам, в них нет смысла.
* Баги - в любом ПО есть баги; автоматизация, как ПО, не исключение. Тестирование поможет нам, но не отловит все баги на свете. Выделите время на исправление багов.
* Логи - это артерия автоматизации. Без них мы не поймем, что автоматизация делает, и не сможем ее починить, когда она сломается. К тому же мы не сможем сказать, в автоматизации ли кроется проблема, или же в тестируемом ПО.

**3. Следуй стандартам и идиомам программирования**

Помимо обращения с автоматизацией как с разработкой ПО, мы должны встраивать в нее соответствующие идеи по внедрению. Каждый инструмент и язык имеют свои собственные идиомы и хитрости, но общепринятые подходы к проектированию и внедрению обычно годятся для всего. Эта статья про инкапсуляцию и абстракцию рассказывает об образцовых практиках, которое можно переносить в другие специфичные области.

**4. Не забывай про поддержку и обслуживание**

ПО не идеально и никогда не бывает полностью готово; с автоматизацией то же самое. В ней будут баги. С изменением тестируемого приложения нужно будет соответственно менять автоматизацию. Мы не можем это предотвратить, но можем разработать наше ПО так, чтобы снизить затраты на его поддержку и обслуживание; и на них тоже надо выделить время. Эта статья и этот пост в блоге рассказывают о факторах, которые надо учитывать, планируя будущую поддержку.

**5. Не делай скрипты зависимыми друг от друга**

Создание тест-скрипта, зависимого от результатов другого теста - как правило, мощный анти-паттерн. Если скрипты зависят друг от друга, их нельзя прогонять поодиночке, и это усложняет дебаг автоматизации и проблем приложения. К тому же зависимые скрипты нельзя запускать параллельно с теми, от которых они зависят. Тут есть граничный случай, когда абсолютно все скрипты зависят от одного-единственного. Этот единичный скрипт обычно настраивает тест-окружение и тестовые данные. В условиях современных фреймворков автоматизации и непрерывной развертки это все большая редкость, но этот сценарий может быть уместен в ситуациях, когда фреймворки недоступны или не подходят для специфической автоматизационной задачи.

**6. Внедряй грамотное логирование и отчеты**

Как описано здесь, грамотные логи, результаты и сообщения об ошибках критично важны для понимания, доверия к, и поддержки автоматизации. Эти логи - наш детализированный образ прогона автотестов: что запускалось, как именно, что упало, как оно упало, как оно преуспело, и т. д. Конечно, если мы тщательно внедрили грамотное логирование, которое дает нам эту информацию в читабельной форме.

**7. Влияй на тестируемость и автоматизируемость**

Тестируемость, та степень, до которой приложение или фича могут быть протестированы, и автоматизируемость, степень, до которой тест-деятельность может выполняться автоматически - это не то, что могут создавать тестировщики, QA и QE, но, конечно, есть вещи, на которые мы можем повлиять. Осуществление этого влияния - наша обязательная задача. Разработчики не всегда знают, что нам нужно для тестирования и для создания автотестов. Мы должны донести это до них. Статьи здесь и здесь рассказывают о некоторых аспектах тестируемости и автоматизируемости.

**8. Не попадайся в ловушку невозвратных затрат**

Иногда мы делаем ошибки. Иногда это крупные ошибки. Мы извлекаем максимум из информации, которой располагаем в моменте, но это не всегда срабатывает. Когда что-то в нашем плане идет не так, мы инстинктивно стараемся это исправить и продолжать исправлять. Однако иногда стоит начать заново, иначе мы рискуем выбросить хорошие деньги вслед за плохими. Это называется "ловушкой невозвратных затрат". Если кратко, она заключается в мнении, что мы уже потратили столько денег на этот проект, что обязаны потратить еще для его реабилитации, дабы извлечь выгоду из уже потраченных, невозвратных затрат на него. Возможно, мы эмоционально привязаны к нашему программному "ребенку"; мы потратили на него столько времени и денег, что не в силах выбросить его и начать заново. Возможно, мы боимся; руководство, скорее всего, не придет в восторг, захоти мы бросить все и снова сделать "то же самое". Мы должны рассматривать такие ситуации с точки зрения бизнеса, а не предаваться эмоциям.

**9. Опасайся хитроумных приспособлений**

Машины Руба Голдберга - это сложные машины, выполняющие сравнительно простые задачи, вроде "Автономного платочка". В мире автоматизации создание таких машин - очень веселое дело, и они могут делать крутые штуки вроде увязывания вместе разных инструментов для выполнения тест-задач. Минус в том, что это сложно понимать и поддерживать; надо опасаться создания того, что сложнее поддерживать, нежели выполнять эти задачи вручную. Эта статья расскажет больше об автоматизированных машинах Руба Голдберга; этот пост размышляет о состоянии "автоматизированности".

**10. Не делай тестовые данные зависимыми от временных данных**

Скрипт, с которым я столкнулся недавно, в один прекрасный день начал падать. Исследуя вопрос, мы выяснили, что падал он из-за смены месяца с июля на август. Скрипт был написан таким образом, что оракул проверял даты в июле, и в июле все было хорошо - приложение возвращало даты текущего месяца, июля. Когда дата сменилась на август, приложение начало возвращать даты августа, и тест падал. В этом случае надо не жестко кодировать даты июля, а динамически генерировать данные на основании текущего месяца.

**Как можно и нельзя автоматизировать**

**Нельзя**:

* **Автоматизировать все ручные тесты**: ручные тесты прекрасны - они находят проблемы, о которых вы даже не помышляли. Но ручной подход к тестированию не всегда можно напрямую перенести на автоматизированные проверки. Возможно, стоит создать новые сценарии специально для автоматизации.
* **Делать автотесты задачей одного-единственного человека**: когда вы только начинаете, найм консультанта по автоматизации - хорошая мысль, однако убедитесь, что соответствующие знания доступны всем участникам проекта. В один прекрасный день консультант или ключевой исполнитель покинет вас, и разбираться с тест-набором придется всем остальным.
* **Автоматизировать все на свете**: сценарий автоматизируется не просто так - на это есть причины, его автоматизация каким-то образом ценна для проекта. Начните с рутинных задач, которые все равно выполняются ежедневно - и вы сразу увидите первую, мгновенную выгоду от усилий по автоматизации.
* **Автоматизировать, просто чтобы автоматизировать**: подумайте, что вам нужно, и что нужно прямо сейчас. Если вы настроены на 80-100% автоматизацию во всех проектах просто потому, что "это круто и так хочет генеральный директор, или "это хорошо звучит на собраниях совета директоров", то вы попусту тратите время и деньги.
* **Покупать лидирующий по рынку, наилучший инструмент автоматизации**: найдите инструмент, который подходит под ваши задачи, и убедитесь, что он действительно делает то, что обещает. Не поддавайтесь на уговоры продавцов купить дорогостоящую программу, которая очень крута прямо сейчас в этом конкретном проекте или на этой конкретной платформе. И не заставляйте другие проекты использовать инструмент, если он им не нужен.
* **Думать в терминах "прошел" и "упал"**: у вас будут упавшие кейсы. Это не значит, что там есть ошибка. Не воспринимайте упавший тест как сигнал о баге - вам нужно разобраться, ПОЧЕМУ тест упал. Также подумайте, действительно ли категории "прошел/упал" подходят для отчетности об автотестах? Возможно, стоит подумать о другой классификации, которая лучше опишет происходящее?
* **Запускать все подряд каждый божий раз**: подумайте о цели прогона ваших тестов. Если вам не нужно тестировать отдельную область - не делайте этого, тестируйте только ту функциональность, которая в этом нуждается. Прочее тестирование - это лишняя трата времени и сил, которая замусорит ваш отчет ненужными данными. Конечно, некоторые проверки могут гоняться постоянно, но убедитесь в том, что это оправданные меры.
* **Забывать тестировать собственные тесты**: привыкайте к идее тестировать свои тесты. Автоматизированный тест-сценарий не должен выпускаться в мир, пока вы не увидели, как он несколько раз упал. Запускайте тест в обстоятельствах, когда он безусловно упадет, чтобы учесть это, когда он будет выпущен в релиз.
* **Недооценивать усилия по поддержке автоматизированного набора тестов**: автоматизированный тест-сьют - не та штука, которую сделал и забыл, а она бегает себе там. Ваша система постоянно меняется, и тест-набор нужно обновлять и пополнять беспрестанно. Не сваливайте эту ответственность на единственного тех-тестировщика в вашей компании.

**Нужно**:

* **Дробить тесты на независимые сценарии**: куда легче определить, где гнездятся проблемы и ошибки, если ваш тест-набор состоит из кратких, конкретных тест-сценариев. Не пытайтесь впихнуть все в один сценарий. Очень, ОЧЕНЬ трудно разобраться, что же пошло не так, если вам надо докопаться до всего на свете, проверяющегося в вашем тесте. Пусть тесты будут краткими и простыми.
* **Сделать автоматизацию задачей всей команды проекта**: почему бы не дать возможность всем, а не только тестировщикам, влиять на набор автотестов? Разработчики, менеджеры проекта, продакт-оунеры - всем им есть что сказать на предмет автоматизированного тестирования, и они могут принести ему пользу.
* **Донести информацию о результатах автоматизированного тестирования до всех - и подумать, кто получает эти результаты**: предоставьте разную информацию разным людям в проекте. Разработчику нужна специфическая информация о прогоне автотестов, и она безразлична менеджеру проекта. Опросите всех заинтересованных лиц, выясните, какая информация им требуется.
* **Начинать с простых вещей и пополнять тест-сьюты по ходу дела**: начните с того, что вам необходимо, и следуйте по воркфлоу проекта. Проекты постоянно меняются - не надо тратить время, силы и деньги на то, что не будет использовано или изменится в последний момент. Создавайте набор тестов по кусочкам, шаг за шагом.
* **Заставить ваш фреймворк работать на износ**: вы приобрели дорогую программу, настроили ее и потратили время на создание и обновление наборов тестов. Пользуйтесь этим! Создайте набор, который может прогоняться часто и при этом ценен для проекта! Набор автотестов, который не запускается - это пустая трата денег.
* **Учитывать проектные и организационные изменения**: найдите программу, которая способна расти вместе с вашими проектами и вашей организацией, и выясните, что вы можете - и не можете - с ней делать. Если она вам не подходит, отбросьте ее. Нет смысла тратить силы и время на неподходящие вам ресурсы.
* **Разгрузить ручных тестировщиков**: думайте о наборе автотестов как о помощи мануальным тестировщикам. Освободите их от нудных повторяющихся задач, пусть они делают то, в чем они звезды - тестируют, а не тупо следуют сценариям.
* **Сделать запуск тестов простым и быстрым**: настройка и старт набора автотестов должна быть простой задачей и давать мгновенную обратную связь. Если ваш тест-набор замедлен или очень сложен, люди просто не будут заморачиваться с запуском.
* **Постоянно обновлять тест-набор**: если меняется ваш код - меняются автотесты, и это ваше золотое правило. Оно верно для ВСЕХ изменений базы кода. Правки багов, внедрение фич - все это ведет к изменениям тест-набора.

_О паттернах проектирования/архитектуре есть ссылки в доп. материалах ниже. О создании фреймворка в теме про виды и инструменты._

Источники:

* [7 характеристик хороших тестов](https://habr.com/ru/post/599507/)
* [Еще десять заповедей автоматизации](https://software-testing.ru/library/testing/testing-automation/3492-ten-more-commandments-of-automation)
* [Как можно и нельзя автоматизировать](https://software-testing.ru/library/testing/testing-automation/2940-starting-up-test-automation)

Доп. материал:

* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software_testing_book/) 3.2.2. Особенности тест-кейсов в автоматизации
* [**Паттерны проектирования в автоматизации тестирования**](https://habr.com/ru/company/jugru/blog/338836/)
* [21 распространённая ошибка в автоматизированном тестировании и способы борьбы с ними](https://habr.com/ru/post/662211/)
* [YAMP 30.04.2022 - Разберем культуру написания автотестов с Рустамом Кенджаевым (Яндекс Маркет) и Дмитрием Мовчаном (Автор Cookbook для UI-тестов)](https://www.youtube.com/watch?v=n3OfjZxFo04\&t=12643s)
* [Чистая архитектура в автотестах](https://www.youtube.com/watch?v=ZIg-yFJx2A8)
* [Элементы хорошего автотеста](https://software-testing.ru/library/testing/testing-for-beginners/3714-what-makes-a-good-automated-test)
* [Ловушки автоматизации (и 9 советов, как в них не попасть)](https://testengineer.ru/sovety-avtomatizacii/)
* [7 характеристик хороших тестов](https://habr.com/ru/post/599507/)
* [UI-автотесты: как делать не стоит](https://habr.com/ru/company/badoo/blog/419419/)
* [7 способов повысить эффективность автоматизации тестирования в Agile разработке](https://habr.com/ru/company/otus/blog/520712/)
* [UI-автотесты: как делать не стоит](https://habr.com/ru/company/badoo/blog/419419/)
* [ТОП-5 вопросов начинающего автоматизатора про автотесты](https://habr.com/ru/company/hh/blog/584574/)
* [Top 10 Test Automation Strategies And Best Practices](https://www.softwaretestinghelp.com/automation-testing-tutorial-7/)
* [Пожалуй, лучшая архитектура для UI тестов](https://habr.com/ru/company/protei/blog/523802/)
* [Распространенные паттерны и методологии UI-автоматизации: реальные примеры](https://telegra.ph/Rasprostranennye-patterny-i-metodologii-UI-avtomatizacii-realnye-primery-01-31)
* [SOLID и другие принципы объектно-ориентированного проектирования в контексте автоматизации](https://www.youtube.com/watch?v=xG6NOxiOLhU)
* [ООП, «святая троица» и SOLID: некоторый минимум знаний о них](https://habr.com/ru/post/446816/)
* [Принцип открытости-закрытости](https://habr.com/ru/company/tinkoff/blog/472186/)
* [Переписываем API тесты](https://habr.com/ru/post/669880/)
* [Взгляд тестировщика на SOLID](https://habr.com/ru/company/lineate/blog/674144/)
