![](https://habrastorage.org/getpro/habr/upload_files/6de/59d/b78/6de59db78cc33a9bb694ae5d62d30bc1.jpg)
Привет, Хабр! Меня зовут Мария Снопок, я отвечаю за автоматизацию тестирования на Python в X5 Tech. Я, конечно, не Остер, но могу дать с десяток вредных советов из области автоматизации. В частности, о том, как испортить жизнь себе и окружающим.
В статье я собрала вредные советы по кодингу, коммуникациям, организации процессов, стандартам, визуализации и пр.: что нужно делать, чтобы тебя закидали помидорами. Смело наступаем на грабли – советы подкреплены реальными кейсами.
Наверняка каждый слышал про Григория Остера и его «Вредные советы» – это серия детских книжек, в которых автор идёт от противного: даёт смешные «плохие» советы, чтобы научить детей полезным и правильным вещам. Давайте представим, какие советы давал бы Остер, если бы писал для автоматизаторов.
***
Если вдруг при разработке вы столкнулись
с непонятным,
И уже вопросов масса зародилась в голове,
Не бегите вы к разрабам и девопсам
не пишите.
Лучше 6 часов подумать в тишине и одному.
***
1. Группа вредных советов: не верь, не бойся, не проси!
Никогда и ни о чём не проси разработчиков/девопсов/команду. Они же такие занятые, зачем их лишний раз беспокоить? Справлюсь сам. А зря! Не со всем вы можете справиться самостоятельно, а главное, в адекватные сроки.
О чём же не нужно просить своих коллег?
1.1 ВРЕДНЫЙ СОВЕТ: не настаивай на доработках DOM-дерева!
Эта группа вредных советов относится к разработке UI-тестов. Немного подробней о том, что именно не стоит просить доработать в DOM-дереве:
· тестовые атрибуты
Сравните 2 страницы:
![](https://habrastorage.org/getpro/habr/upload_files/b52/64c/9b8/b5264c9b85b1dde3c9e0e0fa7b079185.png)
![](https://habrastorage.org/getpro/habr/upload_files/659/7d2/57e/6597d257e8cf191e268197da56a8dd59.png)
На первом скрине есть тестовые атрибуты, а на втором нет.
Тестовые атрибуты не меняются при изменении вёрстки страницы. Это позволяет стабилизировать тесты и сэкономить время на их актуализацию. А локаторы становятся более красивыми и удобными.
Сравните локаторы для элементов:
![](https://habrastorage.org/getpro/habr/upload_files/46a/164/0c6/46a1640c6497e6d81c11fb2e69715635.png)
![](https://habrastorage.org/getpro/habr/upload_files/eb9/cbb/398/eb9cbb398dad071efcb7773c46a0ee00.png)
Очевидно, что локаторы на втором скрине короче, понятнее и актуализировать их проще. Поэтому если договориться с разработчиком о внедрении таких атрибутов, разрабатывать и актуализировать тесты будет намного проще.
Кто-то скажет, что можно автоматизатору и самому добавлять тестовые атрибуты. Возможно, но не всегда front-код прост и понятен, и можно явно определить строку кода, в которую нужно добавить тестовый атрибут. При этом front-разработчику при реализации страницы добавить атрибут не составит труда – нужно просто договориться с разработчиком заранее.
Полезный совет: не стесняйтесь попросить коллег добавить тестовые атрибуты – прививайте культуру тестирования команде.
элементы для отслеживания состояния страницы (прогресс-бары, спиннеры, подписи состояния на кнопках)
Нам, как автоматизаторам, важно понимать, в какой момент со страницей можно начинать работать, а спиннеры и прогресс-бары отлично нам в этом помогают:
![](https://habrastorage.org/getpro/habr/upload_files/d34/fec/114/d34fec1141a7dad426522b442963ac81.png)
Интересно, что пользователю эти элементы будут полезны ничуть не меньше, чем автоматизаторам.
Представьте ситуацию – заходите вы на сайт и видите такой вот серый экран:
![](https://habrastorage.org/getpro/habr/upload_files/d17/7ec/1a2/d177ec1a2ce79f23c58eb4dadad0b804.png)
И не понятно, что происходит: то ли прав не хватает, то ли страница ещё за загрузилась, то ли ещё что-то.
Полезный совет: договаривайтесь с front-разработчиками о добавлении элементов для отслеживания состояния страницы. Так вы облегчите жизнь не только автоматизаторам, но и пользователям вашего приложения.
1.2 ВРЕДНЫЙ СОВЕТ: не проси написать тестовые ручки!
Эта группа советов относится к разработке API-тестов и использованию запросов к БД. О каких ручках речь?
· апи-эндпоинты исключительно под тестовые нужды
История: есть облачное приложение, которое позволяет создавать проекты с инфраструктурой. Удаление таких проектов бизнес-логикой не предусмотрено. Автотесты в процессе своей работы также создают проекты. Тесты гоняются часто, поэтому довольно быстро встал вопрос о том, как удалять данные, создаваемые автотестами, т. к. они замусоривали систему. По просьбе автоматизатора back-разработчики написали ручку для удаления проектов:
![](https://habrastorage.org/getpro/habr/upload_files/fcd/e65/340/fcde65340c1466e536c72db2b8c374d0.png)
Супер! Автотесты больше не засоряют систему создаваемыми данными. Интересно, что функциональность удаления проектов в дальнейшем была внедрена и в пользовательский сценарий, так что ручка для автотестов оказалась полезна не только автоматизаторам.
Полезный совет: не стесняйтесь попросить коллег-бэкендеров добавить тестовые api-ручки. Такие ручки облегчат автоматизацию и могут в дальнейшем стать полезными для приложения.
тестовые функции БД для нужд автотестов
История: есть продукт, в котором регулярно гоняются автотесты. Тесты в начале своего выполнения прогоняют sql-скрипт на 400 строк кода, который приводит систему в исходное состояние, пригодное для автоматизации. Регулярные изменения в структуре БД требуют актуализации скрипта. Скрипт сложный, его поддержка лежит на плечах автоматизаторов и отнимает много времени.
Автоматизатор договорился с db-разработчиками о создании функции в БД, которая реализует логику скрипта. Поддержка функции теперь на db-разработчиках и занимает гораздо меньше времени, т. к. они сами инициируют изменения в БД. А ещё функцию оптимизировали и теперь подготовка данных занимает на 20 минут меньше для каждого прогона автотестов.
Полезный совет: договаривайтесь с db-разработчиками о переносе тяжелых тестовых sql-скриптов в функции. Такие функции упростят автоматизацию и передадут трудоёмкую поддержку тяжёлых скриптов в руки более компетентных коллег.
1.3 ВРЕДНЫЙ СОВЕТ: не требуй отдельную среду/учётки под автотесты!
Сравните две схемы:
![](https://habrastorage.org/getpro/habr/upload_files/88a/c87/fc8/88ac87fc8f95cd94d3b694eaafb62944.png)
![](https://habrastorage.org/getpro/habr/upload_files/494/8ca/c96/4948cac967d73426eb2237723ad53536.png)
На первой схеме автотесты гоняются на том же стенде, который используют и другие члены команды, на второй под автотесты выделен отдельный стенд. Первый вариант подарит вам конфликты, неконсистентные данные, ложные срабатывания, неожиданные результаты и много других сюрпризов. Второй позволит стабилизировать выполнение тестов и исключить все неприятные ситуации, описанные выше.
Вывод: отдельный стенд нужен. Очень. Но что делать, если ресурсов на выделение отдельного стенда нет? Или договориться совсем не получается?
![](https://habrastorage.org/getpro/habr/upload_files/8d0/6f4/fda/8d06f4fda1930a744a1192d24679d358.png)
Можно разделиться по другим критериям, например, по данным: каждый пользователь работает в рамках своих объектов. И объекты, используемые в автотестах, помечены системным признаком и недоступны другим пользователям. Или использовать критерий разделения по времени (этот вариант популярен у нагрузочников): например, автотесты гоняются ночью, а ручные тесты днём.
С тестовыми учётками такая же история.
Полезный совет: договаривайтесь о выделении отдельного тестового стенда и учёток под автотесты, это избавит вас от конфликтов, неожиданных результатов и других неприятностей.
1.4 ВРЕДНЫЙ СОВЕТ: довольствуйся неактуальной спецификацией!
Как пример, не проси пометить неиспользуемые методы в сваггере.
История: в одном из микросервисов продукта решили отключить функциональность, затрагивающую контроллер и несколько методов. Методы из кода бэка решили не выпиливать, потому что они могли понадобиться в качестве наработок в будущем. О потери актуальности этих методов автоматизатор не знал и покрыл их api-тестами, потратив на это рабочий день. Вскрылось, что методы не нужны и тесты тоже:
![](https://habrastorage.org/getpro/habr/upload_files/db7/a78/57b/db7a7857b6a4f53313cd80da560ff7c7.png)
Получился мартышкин труд и 8 часов работы автоматизатора.
Полезный совет: настаивайте на поддержании спецификации приложения в актуальном состоянии. Это позволит избежать бесполезной работы.
***
Если ваши чудо-тесты изо дня в день зеленеют
И стабильно запускать их могут все, кому не лень,
То, когда они сломались – вы чинить их не спешите.
Не спешите их исправить, полежат пускай немного,
Отдыхать ведь должен каждый!
Пусть и тесты отдохнут.
***
2. Группа вредных советов: обнули кредит доверия к автотестам
Доверие к тестам – это про репутацию тестов и их авторитет. Если доверия к тестам нет, никто не будет обращать внимания на результаты прогонов. Можно ли потерять доверие к тестам? Да на раз-два! Вот с этими советами:
2.1 ВРЕДНЫЙ СОВЕТ: забей на актуализацию автотестов!
Часто нас накрывает работой с головой, и в погоне за написанием новых кейсов мы не успеваем актуализировать то, что написали раньше. Неактуальные тесты падают, и такие регулярные падения подрывают доверие к нашим автотестам. У нас в компании в качестве TMS используется Allure TestOPS, поэтому примеры возьму оттуда.
Сравните два скрина:
![](https://habrastorage.org/getpro/habr/upload_files/595/f38/9e0/595f389e09ba22d43f76368948fcb48e.png)
![](https://habrastorage.org/getpro/habr/upload_files/859/6cb/bba/8596cbbba7165d5c945ae5b9c17a2db0.png)
На первом скрине у нас регулярно были зелёные прогоны. Поэтому, когда появился прогон с ошибками, на ошибки сразу обратили внимание и побежали разбираться, почему упал тест. Во втором случае у нас все прогоны жёлто-красно-зеленые, стабильности в прогонах нет, поэтому ошибки последнего прогона уже не будут разбирать с такой скоростью и оперативностью, как в первом случае.
Полезный совет: своевременно актуализируйте тесты, иначе никто не будет воспринимать их результаты всерьёз.
2.2 ВРЕДНЫЙ СОВЕТ: не настаивай на исправлении багов, обнаруженных автотестами!
История: есть продукт с автотестами, тесты регулярно находят ошибки, но у разработчиков не всегда есть время на оперативное исправление этих ошибок. Как результат, баги накапливаются и зафейленные тесты тоже. Отчёты по тестам в итоге не зелёные, а зелёно-жёлто-красные. Из-за регулярной радуги в ланчах новые ошибки в тестах уже не привлекают столько внимания.
Тесты падают, а значит надо оперативно поправить баги, из-за которых они падают, иначе тесты простаивают. Как ускорить исправление ошибок?
В Allure TestOPS есть удобная, на мой взгляд фича: счётчик поломанных кейсов, который показывает, сколько кейсов ломает тот или иной баг.
![](https://habrastorage.org/getpro/habr/upload_files/516/122/af7/516122af7da06a671ef1ff071a969dad.png)
Можно использовать этот счётчик в качестве аргумента для фикса в диалоге с разработчиком: мол, посмотри, твой баг ломает 14 кейсов, и пока ты его не починишь, эти кейсы совершенно бесполезны. Иногда такой аргумент помогает.
Полезный совет: настаивайте на исправлении багов, которые регулярно ломают ваши тесты и тем самым подрывают доверие к ним.
Кстати, по двум последним советам есть лайфхак: можно скипать тесты с ошибками и тесты, которые не успеваете актуализировать – прогон останется зелёным и доверия к нему будет больше. Главное, сильно не увлекаться пропусками.
2.3 ВРЕДНЫЙ СОВЕТ: не способствуй стабилизации инфраструктуры!
История: есть продукт, который включает интеграцию со сторонними системами. Есть хорошо написанные автотесты, которые проверяют функциональность, затрагивающую интеграцию. Из-за того, что интеграция регулярно сбоит, тесты регулярно падают:
![](https://habrastorage.org/getpro/habr/upload_files/ba2/e3f/634/ba2e3f634f5e405d0b794104a9333053.png)
Настолько регулярно, что команда перестала обращать внимание на падения.
Вывод: недоступные стенды, перезапускающиеся сервисы и мигающая сеть могут изрядно потрепать репутацию ваших тестов. Хотя автотесты тут ни при чём и работают они исправно, но! Вы же не будете обходить каждого члена команды и доказывать ему, что тесты на самом деле хорошие, а инфраструктура не очень. К сожалению, ассоциироваться падающие тесты будут с нестабильностью теcтов, а не стендов.
Есть два варианта решения этой проблемы:
а) обратиться за помощью к девопсам или к владельцам нестабильной системы с просьбой эту систему/стенд/сеть стабилизировать;
б) плюнуть на это дело и замокать ломающиеся сервисы. Но! И тут есть подвох: с моками можно переборщить и потом увязнуть в их поддержке. Как мышка в болоте.
Полезный совет: делайте всё возможное, чтобы инфраструктура, в которой бегают ваши тесты, была стабильной: сигнализируйте о проблемах и/или используйте моки.
Подытожу
Вот такие вредные и, в противовес им, полезные советы я выделила на основе своего опыта и наблюдений. Конечно, их намного больше и это только начало.
Если вы узнали себя в каком-то из этих советов, это повод сделать паузу и посмотреть на свою работу критически: возможно, что-то всё-таки стоит изменить.
Не стесняйтесь обращаться к коллегам за разумной помощью! Будь то доработки DOM-дерева, тестовые ручки, организация стендов или актуализация продуктовой спецификации. Это поможет привить здоровую культуру тестирования команде. Да и часто коллеги сами рады оказать вам услугу. И не позволяйте никому подрывать доверие к вашим тестам: восстановить его потом будет намного сложнее.
Продолжение вредных советов можно найти здесь.
P.S. За коллективное стихотворчество спасибо моим коллегам!