Всем привет! В статье продолжаю давать вредные советы из области автоматизации: по кодингу, коммуникациям, организации процессов, стандартам, визуализации и т. д. Здесь вы найдёте подробную инструкцию о том, что нужно делать автоматизатору, чтобы усложнить жизнь себе и окружающим. Первую часть можно прочитать здесь.
***
Даже если разработчик
Комментарий вносит в код,
Будь уверен: непременно
Что-нибудь сломает он.
Запускай скорее тесты
И api, и к ним ui,
И, конечно, full-регрессом
На всех стендах полирни!
***
3. Группа вредных советов: забудь про необходимость и достаточность!
Эта группа вредных советов об отсутствии меры и о поощрении своего внутреннего перфекциониста.
3.1 ВРЕДНЫЙ СОВЕТ: доводи код до совершенства!
История: есть проект, которому asap понадобились автотесты. В проект зашёл автоматизатор, совместно с командой выделили кейсы, которые нужно покрыть автотестами в первую очередь. Автоматизатор взялся за работу, описал модели данных и методы, и тут ему в голову пришла мысль: «А зачем мне описывать только модели и методы для кейсов, которые выбрали для первичной автоматизации? Всё равно потом нужно будет покрывать и оставшиеся сценарии». И ушёл на месяц описывать модели и методы для всей системы целиком. Потом ещё месяц оттачивал свой код и доводил написанное до совершенства.
Прошло два месяца, продукт пригорает, тесты были нужны ещё вчера, а их всё нет и нет. Недовольство нарастает. А ещё через некоторое время продукт заморозили, и всё, что писал автоматизатор, пошло в мусорку.
Полезный совет: не нужно писать про запас, написанное может никогда не пригодиться. Важно: этот совет не касается построения грамотной архитектуры фреймворка, он больше про наполнение фрейма.
Ещё важный полезный совет: нужно вовремя усмирять свой перфекционизм и помнить, что основная задача тестов – ловить ошибки как можно раньше. И что не очень красивый, но работающий тест вчера всегда лучше красивого и работающего завтра.
3.2 ВРЕДНЫЙ СОВЕТ: не сдерживай себя в запусках тестов!
История: есть продукт с микросервисной архитектурой, есть запрос от команды написать api-тесты на сервисы и встроить их в пайплайн – запускать при принятии MR в проект сервиса тесты, которые этот сервис проверяют. Автоматизатор сделал всё, как хотели: написал тесты, встроил их в пайплайн, и теперь на каждый MR запускаются тесты. Сервисов много, MR-ов много.
В какой-то момент из-за большого количества пайплайнов автотесты начали работать как нагрузочные и стали укладывать стенд – синхронизатор не справлялся с нагрузкой и тихо умирал. Тесты попросили отключить. Автоматизатор взгрустнул – вроде бы он сделал ровно то, что просили. И у команды остался осадочек, что тесты им работать мешают.
Полезный совет: не нужно пытаться встроить автотесты везде, где только можно и запускать их на каждый чих – это не всегда полезно и оправдано.
Проблему в продукте выше решили тем, что тесты теперь запускаются только при деплое сервиса на какой-то из стендов. При этом у разработчиков есть возможность запустить тесты для сервиса вручную по кнопке.
***
Если вдруг в порыве модном
Вы решили на проекте
Все ручные тесты напрочь
Удалить и позабыть,
Гордо бизнесу скажите:
«Мы на острие прогресса!
Только скрипт по новой «фиче»
Через месяц отдадим».
***
4. Вредный совет: избавься от ручного тестирования!
Только автотесты, только хардкор! Ручники – вымирающие динозавры и скоро не будут никому нужны!
Опрометчиво) В наше время, и в ближайшие пару десятков лет, робот не сможет полностью заменить человека в тестировании. Новые фичи, как правило, быстрее и дешевле тестировать руками. Исследовательское тестирование (самый ценный вид тестирования, на мой взгляд), тоже не заменишь машиной.
Возможно, лет эдак через 30 что-то изменится, но на наш с вами век работы хватит. Та же история с usability-тестированием – продукт должен быть удобным, а машина вряд ли сможет оценить удобство по достоинству.
Полезный совет: не избавляйтесь от ручного тестирования там, где оно быстрее, дешевле и эффективнее.
***
Если ты вдруг обнаружил,
Что какой-то кейс отложен
И зачем-то почему-то автотестом не покрыт –
Ты бросай свою работу,
Сна не ведай и покоя,
Всё покрой любой ценою –
Автотестер ты иль нет?
***
5. Вредный совет: автоматизируй вcё подряд!
Всё, что шевелится, должно быть покрыто автотестами. Ни один кейс не должен остаться незамеченным!
А вот и нет, напротив, есть множество кейсов, которые не стоит автоматизировать, а именно:
кейсы, требующие экспертной оценки, результаты которых могут трактоваться только на основании опыта эксперта;
«дорогие кейсы» – затраты на автоматизацию и поддержку которых выше, чем на создание и поддержку ручных кейсов (с учётом количества потенциальных прогонов);
кейсы на меняющуюся функциональность – редизайн, рефакторинг, смена архитектурных решений и бизнес-логики в ближайшее время (<3-х месяцев) и в существенных объемах (> 50%).
Полезный совет: отбирайте кейсы для автоматизации с учётом их специфики и полезности.
***
Станешь ты незаменимым,
И всесильным господином,
И вообще бессмертным пони,
Если тест напишешь так,
Чтоб никто его не понял.
***
6. Группа вредных советов: пиши так, чтобы никто не понял!
В автотестовых землях должен быть только один хозяин, и только он должен понимать, что происходит в его владениях!
6.1 ВРЕДНЫЙ СОВЕТ: создавай непонятные отчёты!
Посмотрите на два отчёта выше: по первому отчёту непонятно, что проверяется в тесте, под каким пользователем проходит тест и на каком стенде. Можно, конечно, по таблице параметров предположить, что тесты проверяют статус-коды ответов на запросы с передаваемыми параметрами. Но построение гипотез – это явно не то, к чему должно приводить прочтение отчёта.
Во втором отчёте подробно расписано, что делает тест, что проверяет, есть содержимое запросов, ответов, логи. Также понятно, на каком стенде и под каким юзером проверяется кейс. Если такой отчёт передать любому члену команды, он сможет с лёгкостью воспроизвести этот кейс по шагам.
Полезный совет: пишите понятные и подробные отчёты, которые можно будет однозначно трактовать, и не возникнет трудностей с воспроизведением сценария по отчету. Коллеги скажут вам за это спасибо.
6.2 ВРЕДНЫЙ СОВЕТ: реализуй сложные и плохо поддерживаемые решения!
Вариантов таких решений может быть масса, я приведу парочку для примера.
Пример 1.
История: есть продукт, в котором никогда не было тестировщиков. Команда продукта зрелая, ответственная, тестируют силами команды. В какой-то момент решили, что нужны автотесты. Выбрали BDD-подход в расчёте на то, что аналитики будут писать сценарии автотестов. Разработчики написали BDD-фреймворк. Получился вот такой процесс:
Сценарий автотеста пишется локально в IDE, затем копипастом переносится в description тест-кейса в Allure. Затем в Allure кейс при необходимости актуализируется и так же, копипастом, изменения переносятся в IDE, чтобы сохранить соответствие.
В какой-то момент команда решила, что выделенная функция тестирования им всё-таки нужна, включая автоматизатора. Когда на продукт зашёл автоматизатор, обнаружилась масса минусов у этого решения:
сценарий нельзя запустить из CI, только из Allure;
двойная работа при создании сценария (копипасты из IDE в Allure);
из отчёта непонятно, на каком шаге упал тест.
Отчёт с ошибкой выглядит так:
Видно, что тест упал, а на каком шаге – непонятно.
Актуализация тестов – отдельная боль, потому как нет признаков, по которым можно понять, что description в Allure изменился и сценарий в IDE тоже нужно изменить. В итоге в IDE сценарии актуализируются уже по факту, после локального падения теста.
А самое обидное, что аналитики так и не вовлеклись в процесс написания сценариев, и сама идея BDD-подхода оказалась неоправданной.
Весь цимус заключается в том, что несмотря на костыльность и явную неэффективность такого решения жило оно довольно долго. И успело нажить больше тысячи кейсов. Потому что было масштабным и давило авторитетом написавших его разработчиков. Даже автоматизатор, зайдя в продукт, не сразу смог оценить масштаб бедствия – казалось, что раз опытные ребята долго и продуктивно таким решением пользуются, значит в нём есть какой-то смысл.
Полезный совет: критически оценивайте архитектуру реализованного решения. Возможно, оно неэффективно и его стоит сменить, как бы масштабно и внушительно оно ни выглядело.
На продукте, собственно, так и сделали. Перешли к единому корпоративному решению. Новые кейсы пишутся уже с использованием корпоративной библиотеки, а старые постепенно переписываются.
Пример 2.
Ещё один пример не самого удачного решения:
Изначально класс имел простую структуру, без всяких логических ветвлений. Постепенно тестовые сценарии разрослись. Вместо того, чтобы внести изменения в имеющийся набор тестовых данных, адаптировав его под изменения, добавили ещё несколько новых наборов данных, по набору на каждое изменение. Это привело к ненужному усложнению логики класса – добавились условия. А можно было просто скорректировать имеющиеся тестовые данные и не плодить новые тестовые наборы, усложняя при этом логику реализации.
Полезный совет: чем проще будет ваше решение, тем лучше. В простоте вся красота.
Пример 3.
И ещё пример напоследок:
На скрине описаны хуки, которые перед началом выполнения автотестов создают тестовый проект для всего набора тестов и передают его id в процессы с тестами. Важно было создавать один проект для всех тестов. Фикстуры для этого не подойдут, потому что для фикстуры максимальный scope=”session”, а нам нужно создать тестовые данные один раз для нескольких сессий.
Вроде бы, решение с хуками справляется с поставленной задачей, но есть нюанс. Хук pytest_configure выполняется перед хуком создания Allure-отчёта, поэтому всё, что будет выполнено в хуке pytest_configure, в отчёт не попадет. Если, например, внутри proj.create() на каком-нибудь из шагов сценария тест упадёт, то в отчёте мы ничего не увидим: в Allure будет просто пустой отчёт, без тестов:
Придется идти в логи джобы и там выяснять, что именно произошло, а это не совсем удобно. А чем сложнее логика внутри proj.create(), тем больше вероятность получить пустой отчет.
Как вариант решения – вынести proj.create() в отдельную джобу, а дальше передать id проекта из этой джобы в джобы с тестами.
Полезный совет: нужно подбирать решения с учётом особенностей вашей реализации и делать их максимально прозрачными.
***
Если в новом ты продукте
Написал крутые тесты
И команде эти тесты
На поддержку передал,
Не давай ты им инструкций,
Не пиши рекомендаций –
Настоящий разработчик
Разобраться должен сам!
***
7. Вредный совет: будь хранителем тайного знания!
И снова история: есть продукт с потребностью в автотестах. Пригласили автоматизатора со стороны сервиса автоматизации тестирования на конкретный объём работ – покрыть автотестами определённый набор кейсов в определённые сроки. Сервис автоматизации – это когда автоматизатор приходит на конкретную работу, делает её, передаёт результаты и уходит.
Поддержку написанных тестов команда решила взять на себя – команда зрелая, решили, что справятся сами. Автоматизатор написал автотесты, передал их команде, все довольны, пожали друг другу руки и разошлись. Проходит какое-то время, и от команды начинает поступать негативная обратная связь, что тесты поломались и как их починить, команда не знает. Куда смотреть и к кому идти тоже не знают – тесты вроде бы и есть, но они не работают и как их починить, никто не знает.
А получилось так потому, что автоматизатор, уходя, понадеялся на зрелость и самостоятельность команды, а в частности, разработчиков. Они же разработчики, разберутся, да и сами же говорили, что смогут тесты поддерживать. А вот нет. Не разобрались. А всего-то нужно было, уходя, провести им краткий инструктаж, как запускать тесты, как отлаживать, как читать отчёты, куда смотреть и как чинить, оставить рекомендации и инструкции по запуску и разбору результатов.
Полезный совет: нужно оцифровывать свои знания и делиться ими с коллегами. Не нужно становиться единственным хранителем тайного знания, без которого в ваших тестах никто не разберётся. Информативные readme можно отнести сюда же как правило хорошего тона.
***
Если разработчик хочет пром спасти за 5 минут
И прислать он просить логи
На телегу и в WhatsApp,
Тормозни его, конечно,
Слишком смело, так нельзя!
Логи можно только в трекер,
Прямо к баге прикрепить.
Ну и пусть страдает юзер, да и бизнес подождёт!
Но зато регламент строгий
Будет нами соблюдён.
***
8. Вредный совет: следуй стандартам неукоснительно!
Например:
Всеми силами стремись к классической пирамиде тестирования! Ну и что, что в реальной жизни такие пирамиды редкость: как правило, чаще встречаются усечённые, перевёрнутые пирамиды, ромбовидные и т. д. И неважно, что от десятка верхнеуровневых ui-тестов пользы намного больше, чем от сотни низкоуровневых unit-тестов.
Пиши unit-тесты вместо разработчиков! Хотя разработчики такие тесты напишут гораздо легче и быстрее. А ты в это время сможешь написать гораздо более полезные интеграционные api-тесты.
Не учитывай особенности команды, продукта, не бери в расчёт имеющиеся ресурсы при построении стратегии АТ!
История: в продукт, в котором ещё не было автотестов, зашёл автоматизатор. В качестве стратегии автоматизации был выбран подход, в котором сначала api-тестами покрываются все эндпоинты приложения. Затем из этих тестов, как из конструктора, собираются интеграционные сценарные тесты, затем уже пишутся верхнеуровневые ui-тесты.
Автоматизатор приступил к работе. Эндпоинтов в приложении оказалось очень много. И соотношение числа автоматизаторов к числу разработчиков неадекватное – один автоматизатор на 17 разработчиков. Через пару месяцев автоматизатор окончательно закопался – микросервисы росли как грибы в лесу после дождя. Автоматизатор не успевал не то, что писать новые тесты, но и актуализировать уже написанное не успевал: тесты ломались, процент покрытия застрял на месте.
Решили сделать паузу и пересмотреть подход. Взяться за покрытие апи-тестами основных сценариев, а разработку тестов на эндпоинты заморозить. Затем были написаны ui-смоуки на все страницы, формы и кнопки. Сценарные api-тесты в комплексе с ui-смоуками позволили существенно сэкономить время на проведение регрессионного тестирования, и такой подход подошёл продукту намного лучше.
Полезный совет: стандарты хороши, чтобы задать фокус и направление, но не нужно слепо следовать им, игнорируя особенности своего продукта.
***
Если вдруг тебе коллеги
поревьювить предложили
Код друг друга и советы с комментариями дать,
Ни за что не соглашайся! Засмеют они тебя же
И советов неприличных раздадут –
испанский стыд!
Годик подожди, подумай,
отшлифуй свой код получше,
Чтоб ни одного совета от коллег не получить!
***
9. Вредный совет: никому не показывай свой код!
У нас в компании нет отдельно выделенных людей, занимающихся код-ревью. На большинстве проектов один автоматизатор, реже встречаются продукты, где автоматизаторов несколько.
Поэтому автоматизаторы ревьювят друг друга: так называемое, кросс-командное ревью.
У такого ревью куча плюсов:
позволяет избавиться от неудачных архитектурных решений ещё в зародыше;
помогает улучшить читаемость и качество кода;
способствует обучению и развитию: автоматизаторы получают рекомендации к своему коду от коллег с одной стороны, а с другой – знакомятся с новыми решениями, когда сами проверяют код у своих коллег.
Полезный совет: не будьте "ревьювным стесняшкой" – нет ничего зазорного в том, чтобы задавать вопросы и получать хорошие советы.
***
Если ты при разработке
Вдруг столкнулся с непонятным
И решение простое
Сходу быстро не найти,
Ты не лезь в проклятый гугл
и ответа не ищи там,
Лучше сам костыль придумай,
Читят только слабаки!
Пусть он будет кривоватым,
Уйму времени отнимет –
Обязательно решенье
Уникальным быть должно!
***
10. Вредный совет: изобретай колесо!
Google- и StackOverflow-разработка уже давно крепко укоренились в наших рабочих буднях. И нет ничего зазорного в том, чтобы воспользоваться чужим удачным решением вместо того, чтобы изобретать свой велосипед.
Разумеется, это не про бессмысленный копипаст, а про осознанное переиспользование. Когда ты понимаешь, что и зачем ты используешь и как это работает.
Полезный совет: используйте готовые решения вместо того, чтобы придумывать свои – это сэкономит вам уйму времени и сил.
***
Если на своём проекте
Сложные покрыл ты фичи
И команде сэкономил
Кучу времени и сил,
Ты молчи об этом скромно,
Чтобы никогда на свете
Вдруг никто бы не подумал,
Что болтун ты и хвастун!
***
11. Вредный совет: не рекламируй свою работу!
История: в продукт, в котором не было автотестов, вышел автоматизатор. Через несколько месяцев пришёл PM этого продукта с вопросом, чем вообще занимается автоматизатор и зачем он нужен команде. Собрали встречу, обсудили. Выяснилось, что автоматизатор написал хорошие smoke- и sanity-тесты, которые гоняются каждый день и находят ошибки. Но о результатах его работы и вообще о какой-то активности с его стороны никто ничего не знал, потому что сам автоматизатор про свои успехи особо не распространялся. Ни об отчётах, ни о частоте запусков, ни о том, что найденные баги были обнаружены автотестами.
Потом, конечно, автоматизатор провёл встречу с командой. На встрече рассказал о том, что он сделал за эти месяцы, как вырос процент покрытия тестами за время его работы. И о том, как любой член команды может запускать автотесты и где потом смотреть отчёты по этим запускам. Больше вопросов к работе автоматизатора не возникало.
Полезный совет: не стесняйтесь рекламировать свою работу! Важно не только делать работу, но ещё и продавать её.
Резюме
Понятно, что это далеко не полный список советов, и каждый наверняка сможет дополнить его чем-то своим.
Понятно также, что одно дело – прочитать статью, а другое дело – набить шишки на собственном опыте. Во втором случае запоминается намного лучше. Но всё же правило «Предупреждён – значит вооружён» никто не отменял.
Эту статью можно использовать как чеклист – если вы отметили себя в каких-то моментах, то есть повод притормозить и подумать, а точно ли вы двигаетесь в нужном направлении. И, возможно, это направление немного скорректировать.
P. S. Стихотворное творчество у нас коллективное и эксклюзивное. Большое спасибо коллегам за стихи!