Привет, Хабр! Меня зовут Мария Снопок, я отвечаю за автоматизацию тестирования на Python в X5 Tech. Я, конечно, не Остер, но могу дать с десяток вредных советов из области автоматизации. В частности, о том, как испортить жизнь себе и окружающим. 

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

Наверняка каждый слышал про Григория Остера и его «Вредные советы» – это серия детских книжек, в которых автор идёт от противного: даёт смешные «плохие» советы, чтобы научить детей полезным и правильным вещам. Давайте представим, какие советы давал бы Остер, если бы писал для автоматизаторов.

***

Если вдруг при разработке вы столкнулись

с непонятным, 

И уже вопросов масса зародилась в голове, 

Не бегите вы к разрабам и девопсам

не пишите. 

Лучше 6 часов подумать в тишине и одному. 

***

1. Группа вредных советов: не верь, не бойся, не проси!

Никогда и ни о чём не проси разработчиков/девопсов/команду. Они же такие занятые, зачем их лишний раз беспокоить? Справлюсь сам. А зря! Не со всем вы можете справиться самостоятельно, а главное, в адекватные сроки.

О чём же не нужно просить своих коллег?

1.1  ВРЕДНЫЙ СОВЕТ: не настаивай на доработках DOM-дерева! 

Эта группа вредных советов относится к разработке UI-тестов. Немного подробней о том, что именно не стоит просить доработать в DOM-дереве:

·       тестовые атрибуты

Сравните 2 страницы:

На первом скрине есть тестовые атрибуты, а на втором нет.

Тестовые атрибуты не меняются при изменении вёрстки страницы. Это позволяет стабилизировать тесты и сэкономить время на их актуализацию. А локаторы становятся более красивыми и удобными.

Сравните локаторы для элементов:

Очевидно, что локаторы на втором скрине короче, понятнее и актуализировать их проще. Поэтому если договориться с разработчиком о внедрении таких атрибутов, разрабатывать и актуализировать тесты будет намного проще.

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

Полезный совет: не стесняйтесь попросить коллег добавить тестовые атрибуты – прививайте культуру тестирования команде.

• элементы для отслеживания состояния страницы (прогресс-бары, спиннеры, подписи состояния на кнопках)

Нам, как автоматизаторам, важно понимать, в какой момент со страницей можно начинать работать, а спиннеры и прогресс-бары отлично нам в этом помогают:

Интересно, что пользователю эти элементы будут полезны ничуть не меньше, чем автоматизаторам.

Представьте ситуацию – заходите вы на сайт и видите такой вот серый экран:

И не понятно, что происходит: то ли прав не хватает, то ли страница ещё за загрузилась, то ли ещё что-то. 

Полезный совет: договаривайтесь с front-разработчиками о добавлении элементов для отслеживания состояния страницы. Так вы облегчите жизнь не только автоматизаторам, но и пользователям вашего приложения. 

1.2  ВРЕДНЫЙ СОВЕТ: не проси написать тестовые ручки! 

Эта группа советов относится к разработке API-тестов и использованию запросов к БД. О каких ручках речь?

·       апи-эндпоинты исключительно под тестовые нужды

История: есть облачное приложение, которое позволяет создавать проекты с инфраструктурой. Удаление таких проектов бизнес-логикой не предусмотрено. Автотесты в процессе своей работы также создают проекты. Тесты гоняются часто, поэтому довольно быстро встал вопрос о том, как удалять данные, создаваемые автотестами, т. к. они замусоривали систему. По просьбе автоматизатора back-разработчики написали ручку для удаления проектов:

Супер! Автотесты больше не засоряют систему создаваемыми данными. Интересно, что функциональность удаления проектов в дальнейшем была внедрена и в пользовательский сценарий, так что ручка для автотестов оказалась полезна не только автоматизаторам.

Полезный совет: не стесняйтесь попросить коллег-бэкендеров добавить тестовые api-ручки. Такие ручки облегчат автоматизацию и могут в дальнейшем стать полезными для приложения.

• тестовые функции БД для нужд автотестов

История: есть продукт, в котором регулярно гоняются автотесты. Тесты в начале своего выполнения прогоняют sql-скрипт на 400 строк кода, который приводит систему в исходное состояние, пригодное для автоматизации. Регулярные изменения в структуре БД требуют актуализации скрипта. Скрипт сложный, его поддержка лежит на плечах автоматизаторов и отнимает много времени.

 Автоматизатор договорился с db-разработчиками о создании функции в БД, которая реализует логику скрипта. Поддержка функции теперь на db-разработчиках и занимает гораздо меньше времени, т. к. они сами инициируют изменения в БД. А ещё функцию оптимизировали и теперь подготовка данных занимает на 20 минут меньше для каждого прогона автотестов.

Полезный совет: договаривайтесь с db-разработчиками о переносе тяжелых тестовых sql-скриптов в функции. Такие функции упростят автоматизацию и передадут трудоёмкую поддержку тяжёлых скриптов в руки более компетентных коллег.

1.3  ВРЕДНЫЙ СОВЕТ: не требуй отдельную среду/учётки под автотесты!

Сравните две схемы:

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

Вывод: отдельный стенд нужен. Очень. Но что делать, если ресурсов на выделение отдельного стенда нет? Или договориться совсем не получается? 

Можно разделиться по другим критериям, например, по данным: каждый пользователь работает в рамках своих объектов. И объекты, используемые в автотестах, помечены системным признаком и недоступны другим пользователям. Или использовать критерий разделения по времени (этот вариант популярен у нагрузочников): например, автотесты гоняются ночью, а ручные тесты днём. 

С тестовыми учётками такая же история.

Полезный совет: договаривайтесь о выделении отдельного тестового стенда и учёток под автотесты, это избавит вас от конфликтов, неожиданных результатов и других неприятностей.

1.4  ВРЕДНЫЙ СОВЕТ: довольствуйся неактуальной спецификацией!

Как пример, не проси пометить неиспользуемые методы в сваггере.

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

Получился мартышкин труд и 8 часов работы автоматизатора.

Полезный совет: настаивайте на поддержании спецификации приложения в актуальном состоянии. Это позволит избежать бесполезной работы.

***

Если ваши чудо-тесты изо дня в день зеленеют

И стабильно запускать их могут все, кому не лень,

То, когда они сломались – вы чинить их не спешите.

Не спешите их исправить, полежат пускай немного, 

Отдыхать ведь должен каждый!

Пусть и тесты отдохнут.

***

2. Группа вредных советов: обнули кредит доверия к автотестам

Доверие к тестам – это про репутацию тестов и их авторитет. Если доверия к тестам нет, никто не будет обращать внимания на результаты прогонов.  Можно ли потерять доверие к тестам? Да на раз-два! Вот с этими советами:

2.1  ВРЕДНЫЙ СОВЕТ: забей на актуализацию автотестов!

Часто нас накрывает работой с головой, и в погоне за написанием новых кейсов мы не успеваем актуализировать то, что написали раньше. Неактуальные тесты падают, и такие регулярные падения подрывают доверие к нашим автотестам. У нас в компании в качестве TMS используется Allure TestOPS, поэтому примеры возьму оттуда.

 Сравните два скрина:

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

Полезный совет: своевременно актуализируйте тесты, иначе никто не будет воспринимать их результаты всерьёз.

2.2  ВРЕДНЫЙ СОВЕТ: не настаивай на исправлении багов, обнаруженных автотестами!

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

Тесты падают, а значит надо оперативно поправить баги, из-за которых они падают, иначе тесты простаивают. Как ускорить исправление ошибок? 

В Allure TestOPS есть удобная, на мой взгляд фича: счётчик поломанных кейсов, который показывает, сколько кейсов ломает тот или иной баг.

Можно использовать этот счётчик в качестве аргумента для фикса в диалоге с разработчиком: мол, посмотри, твой баг ломает 14 кейсов, и пока ты его не починишь, эти кейсы совершенно бесполезны. Иногда такой аргумент помогает.

Полезный совет: настаивайте на исправлении багов, которые регулярно ломают ваши тесты и тем самым подрывают доверие к ним.

Кстати, по двум последним советам есть лайфхак: можно скипать тесты с ошибками и тесты, которые не успеваете актуализировать – прогон останется зелёным и доверия к нему будет больше. Главное, сильно не увлекаться пропусками.

2.3  ВРЕДНЫЙ СОВЕТ: не способствуй стабилизации инфраструктуры!

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

Настолько регулярно, что команда перестала обращать внимание на падения. 

Вывод: недоступные стенды, перезапускающиеся сервисы и мигающая сеть могут изрядно потрепать репутацию ваших тестов. Хотя автотесты тут ни при чём и работают они исправно, но! Вы же не будете обходить каждого члена команды и доказывать ему, что тесты на самом деле хорошие, а инфраструктура не очень. К сожалению, ассоциироваться падающие тесты будут с нестабильностью теcтов, а не стендов. 

Есть два варианта решения этой проблемы:

а) обратиться за помощью к девопсам или к владельцам нестабильной системы с просьбой эту систему/стенд/сеть стабилизировать;

 б) плюнуть на это дело и замокать ломающиеся сервисы. Но!  И тут есть подвох: с моками можно переборщить и потом увязнуть в их поддержке. Как мышка в болоте.

Полезный совет: делайте всё возможное, чтобы инфраструктура, в которой бегают ваши тесты, была стабильной: сигнализируйте о проблемах и/или используйте моки.

Подытожу

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

Если вы узнали себя в каком-то из этих советов, это повод сделать паузу и посмотреть на свою работу критически: возможно, что-то всё-таки стоит изменить.

Не стесняйтесь обращаться к коллегам за разумной помощью! Будь то доработки DOM-дерева, тестовые ручки, организация стендов или актуализация продуктовой спецификации. Это поможет привить здоровую культуру тестирования команде.  Да и часто коллеги сами рады оказать вам услугу. И не позволяйте никому подрывать доверие к вашим тестам: восстановить его потом будет намного сложнее.

Продолжение вредных советов ищите в моей следующей статье «Если бы Остер раздавал советы автоматизаторам. Часть 2», которую я планирую опубликовать совсем скоро.

P.S. За коллективное стихотворчество спасибо моим коллегам!