ThreadQA | Олег Пендрак

TODO позже доделаю... В коде автотеста:

@Test
public void shouldReturnCorrectPrice() {
    // TODO: Временно закомментировал, падает только на CI
    // FIXME: Разобраться после релиза
    // Раскомментировать через 2 недели!!!
    // Не забыть!!!
    
    // assertEquals(expectedResult, actualResult);

    assertTrue(true);
}

Проходит время Сначала проходит релиз Потом ещё один Потом увольняется QA, который это заметил Потом меняется тимлид Потом проект переезжает с Jenkins на GitLab CI Потом весь отдел обсуждает, почему прод периодически отдаёт отрицательные цены Ты открываешь IntelliJ IDEA → Git History — Последнее изменение файла: 1 год назад — Последний коммит автора: 11 месяцев назад — Последний онлайн в Slack: 403 days ago — Статус Jira-задачи: In Progress — Комментарий в задаче:

“Вернусь после отпуска, быстро доделаю”

Отпуск, как выяснилось, был в 2023 Ты начинаешь расследование: — Кто закомментировал assert? — Почему тест зелёный? — Почему TODO никто не увидел? Тимлид говорит "тест проходит же"🤠

Испытательный срок: как не уволить самого себя от страха Сегодня хочу разобрать самый нервный кусочек жизни любого новичка (да и не только новичка) — испытательный срок И особенно то мерзкое состояние, когда тебе кажется, что тебя вот-вот раскусят и с позором выставят за дверь Первое, что нужно зарубить себе на носу: чувствовать себя потерянным на старте — это абсолютно нормально. Почему? Да потому что специфику проекта нельзя нагуглить Местные костыли, архитектура и бизнес-требования не лежат на StackOverflow. Они живут только в головах команды. Ты физически не мог знать это заранее Отсюда вытекает главная стратегия выживания: 1️⃣ Задавать вопросы — это твоя работа Вопросы про устройство проекта — это не слабость, а адекватность. Команде в тысячу раз выгоднее потратить на тебя час времени сейчас, чем смотреть, как ты две недели молча буксуешь на простой таске 2️⃣ Не неси рабочие проблемы «на сторону» Частая ошибка новичков: упереться во внутреннюю проблему компании и от страха пойти спрашивать совета у стороннего ментора или в паблик-чат в телеге, люди там не знают твоего контекста Самый короткий и правильный путь — идти к своим ребятам, которые этот код писали 3️⃣ Не бойся просить помощи с настройкой Нормально, что ты не понимаешь, как поднять этот звездолёт локально, ведь везде свои хитрые конфиги, VPN-ы и доступы Просто подойди к мидлу или сеньору и попросите помочь с сетапом — это сэкономит дни слепого тыканья в консоль 📲 Но держим границы Вопросы уровня «как работает цикл for» или «как сделать git push» мы гуглим сами. А вот специфику баз данных, стендов и флоу релизов — смело спрашиваем у команды И небольшой инсайд со стороны нанимающего менеджера: хорошие рабочие вопросы делают тебя заметным и вовлечённым в глазах команды Поверьте, на испытательном сроке долгое молчание пугает лида гораздо больше, чем ваши вопросы Испытательный срок — это не экзамен на всезнание. Никто не ждёт от тебя магии в первый месяц, а ждут, что ты будешь быстро разбираться и бить тревогу, когда упёрся в стену Так что не бойся спрашивать, лучше бойся молчать Ребят, расскажите, какой самый «глупый» или нелепый вопрос вы задавали в первые дни на новой работе (ток не стесняйтесь, мы все наваливали кринжа)👇

Главный парадокс собесов: почему офферы забирают те, кто «на чиле»? Один человек сидит ночами, зубрит теорию тестирования, знает наизусть все паттерны и устройство коллекций под капотом, а потом приходит на собес, потеет, выдает идеальные формулировки — и получает дежурный отказ А другой залетает на созвон в худи и с кружкой кофе, вообще не парится, где-то тупит, где-то отшучивается, просто рассуждает вслух — и через день ему прилетает жирный оффер Кажется, что это жутко несправедливо, но на самом деле в этом есть железобетонная логика рынка Собес в айти — это не экзамен в универе Интервьюер не ищет ходячую Википедию, в которую можно загрузить запрос и получить словарный ответ. Он ищет адекватного коллегу, с которым ему предстоит каждый день работать, спорить на планировании и чинить падающий прод Что не так с «зубрилами»? Когда человек слишком сильно хочет понравиться и боится ошибиться, он зажимается. Любой шаг влево от заученного скрипта или нестандартная задача вызывают у него панику и синий экран смерти С ним тяжело вести диалог, потому что он не общается, а «отвечает по билету» В чем секрет тех, кто расслаблен? Они приходят просто поболтать о технологиях. Инженер пришел поговорить с другим инженером Спрашивают то, чего он не знает? Он не краснеет, не мычит и не извиняется. Он спокойно говорит: «Слушай, руками такое не трогал. Но если бы припекло — пошел бы гуглить вот это и попробовал бы решить так» И это то что надо, потому что ровно это мы и делаем на реальной работе каждый день Такая уверенность и расслабленность транслирует нанимающему менеджеру самое главное: «я адекватный, со мной комфортно работать, я не впаду в ступор от непонятной таски». И поверьте, эти качества часто перевешивают десяток зазубренных терминов Поэтому главный чит-код для прохождения собесов — искусственно снизить их значимость в своей голове. Идите на созвон так, будто вы уже работаете в этой команде и просто созвонились с лидом обсудить какую-то рабочую задачку В комментариях можете рассказать, к какому типу вы относитесь: потеете перед каждым созвоном или залетаете на расслабоне?👇

Когда решил помочь разработчикам - Несколько вечеров изучал оптимизацию производительности - Читал про кэширование - Про многопоточность - Про очереди сообщений - Про уменьшение нагрузки на сервисы Решил оптимизировать конфиг проекта, поэтому просто убрал "лишний" нолик Было:

timeout=30000

Стало:

timeout=3000

Теперь запросы действительно выполняются быстрее Потому что не успевают выполниться вообще🤡

Снимаем напряжение по поводу собесов по автотестам В прошлый раз я немного побомбил с душных вопросов на интервью, а сегодня, пожалуй, «надо брат расслабиться...» На самом деле всё далеко не так страшно, потому что собесы — это дико предсказуемая штука Если отходить на пару десятков интервью, вы заметите прикольную вещь: 90% собесов по автоматизации идут по одному и тому же сценарию, вопросы буквально ходят из компании в компанию. Это просто система, а любую систему можно выучить и хакнуть Обычно бывает так: первые 2–3 собеса вы тупите, потеете и собираете шишки — это база. На пятом уже почти не трясутся руки, а к десятому вы отвечаете на большинство вопросов на автопилоте Так что отказы на старте — это не «ты плохой инженер», это тупо разгон и сбор статистики Чтобы вам было спокойнее, вот классический сценарий, по которому вас будут гонять 👇 1️⃣ «Расскажите о себе» и прощупывание процессов Просят короткую выжимку про опыт и последний проект, а дальше копают в процесс: как задача ехала от аналитики до прода, что там по CI/CD, как часто катили релизы. Тут проверяют не теорию, а ищут подтверждение, что вы реально варились в живой разработке Лайфхак: заранее подготовьте складную историю одной реальной задачи от постановки до выкатки 2️⃣ База по ручному тестированию Да, автоматизаторов по ней гоняют почти всегда. Техники тест-дизайна, граничные значения, пирамида тестирования, разница между тест-планом и чек-листом, Definition of Done. Звучит банально, но по этим ответам за 5 минут видно ваш инженерный фундамент 3️⃣ Язык программирования (самый душный блок) Если вы пишете на Java, готовьтесь к классическому Java Core. ООП, типы данных, коллекции, исключения и стримы. Глубина копания зависит от грейда (джун/мидл/сеньор), но базу тут надо отскакивать от зубов. Это любимая часть большинства техлидов 4️⃣ Инструменты и суровая практика Пробегутся по вашему стеку: Selenium, REST Assured, JUnit/TestNG, Allure. И тут почти со 100% вероятностью всплывёт тема флаки-тестов — откуда берутся и как вы их лечили Лайфхак: держите в рукаве 2–3 живых примера из практики, как вы героически спасали нестабильные тесты 5️⃣ Ваши вопросы к компании В конце вам рассказывают про проект и спрашивают: «Есть вопросы?». Ответить «нет» — это прям упущенная возможность и небольшой редфлаг Нормальные вопросы технаря: как у вас устроено код-ревью? где сейчас главная боль в автотестах? как генерите тестовые данные? что по тестовым стендам? Вот и всё, никакой магии нет. Пять понятных этапов, которые ждут вас почти везде. Подготовьтесь по этому плану, сходите на пару собесов чисто ради тренировки — и вы поймёте правила игры Каждый собес — это не экзамен всей вашей жизни, это просто рабочий митинг. Выдыхаем и идём забирать свои офферы🤝

Собесы по автотестам: ожидание vs реальность Думаю для многих знакомая история, когда приходишь на собес, настраиваешься обсуждать архитектуру, подходы, CI/CD, а тебе с порога говорят:

«Так, расскажи-ка, в чём разница между LinkedList и ArrayList? А как там HashMap внутри устроен? Что по коллизиям?»

Сидишь и думаешь: вы вообще представляете, чем я у вас заниматься буду, и видели ли вы реальные задачи автоматизатора? 90% нашей рутины в API-автотестах — это дёрнуть ручку, замапить ответ в модельку, вытащить нужное поле и написать пару ассертов и всё. Тот же HashMap под капотом можно годами руками не трогать А вот про реальную боль автоматизатора почему-то почти не спрашивают, например:

🔘 Упал тест, вот тебе лог и стектрейс — с чего начнешь чинить? 🔘 Как отревьюишь этот пулл-реквест от джуна? 🔘 Что делаешь с тестовыми данными? Как чистишь базу за собой? 🔘 Как прокинуть авторизацию в UI-тестах без костылей и магии?

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

Где практиковаться искать локаторы для UI автотестов и писать API тесты? 1️⃣ XPath Practice Hub Это мой личный бесплатный тренажёр для поиска локаторов на странице, без которого UI автотесты не пишутся Внутри есть теория по тому, как искать элементы на странице, и куча практики в виде самых разных сценариев, прям как в реальных компаниях. Ты не читаешь сухую документацию, а сразу руками тренируешься находить элементы Итог простой: научишься уверенно находить элементы и по XPath, и по CSS, а это базовый навык любого UI автоматизатора Ссылка: https://lms.threadqa.ru/xpath-practice-hub 2️⃣ XPath Dinner — игра для тренировки локаторов Наверное моя любимая часть, так как тренироваться тут реально весело Это интерактивная игра, где ты ищешь фрукты на тарелках с помощью локаторов и сразу видишь результат своих действий. Ты не зубришь синтаксис, а играешь и в процессе намертво запоминаешь, как строятся селекторы Кайфовый варик, когда надоела душная теория, но хочется прокачать навык Ссылка: https://lms.threadqa.ru/xpath-practice-hub/xpath-dinner Помимо локаторов есть также куча открытых вещей, на которых можно набивать опыт: — Публичные тестовые API вроде учебных песочниц https://shawarma.threadqa.ru/, где можно безопасно дёргать ручки и тренировать REST Assured — Открытые демо сайты с формами, корзинами и логином, на которых удобно писать первые UI тесты — Открытые проекты на GitHub с готовыми автотестами, чтобы смотреть, как всё устроено у других Вывод Начни с локаторов, потому что без них UI тесты не сдвинутся, прогони теорию в Practice Hub, закрепи игрой, а дальше иди писать тесты на демо сайт, так навык сразу пойдет в реальную практику Самое классное в практике это то, что прогресс чувствуется почти сразу. Сегодня ты мучаешься с одним селектором полчаса, а через неделю строишь их на автомате и сам не замечаешь как Главное не просто читать, а трогать руками, и тренажёры как раз для этого и существуют🤝

Накидайте в комментариях свои вопросы и на какие темы хотите подробный разбор Сделаю для вас полезные постики и разберу самые важные темы👇

Охраняю зеленый пайплайн в CI/CD от нестабильных тестов Придумайте в комментах свою подпись к этой фотке😁👇

Вчера был в тире 💥 Пострелял из глока, СВД и АКМ — чистый кайф И ведь кучно кладу, однако

Стало интересно, какими библиотеками вы сами чаще всего пользуетесь Накидайте в комментариях топ-3, обменяемся опытом и соберем базу работающих инструментов. Чтобы каждый мог взять что-то под себя)

Что стоит автоматизировать, а что нет? Окей, я научился писать автотесты, но что именно покрывать, мб вообще всё подряд? Нет, всё подряд это прямой путь к ошибкам и лишней трате времени Сначала главный принцип Автотест — это вложение, он стоит времени на написание и на поддержку Поэтому покрывать стоит то, что часто проверяется и больно ломается. Если сценарий важный и повторяется из релиза в релиз, то он окупится, а если редкий и копеечнй, тест съест больше, чем принесёт Что покрывать в первую очередь Критичные бизнес сценарии, без которых продукт не живёт Авторизация, оформление заказа, оплата, регистрация. Если это сломается, у компании сразу проблемы и деньги, поэтому такие кейсы автоматизируем первыми и бережём как зеницу ока Что покрывать обязательно Регрессионные сценарии, которые проверяются вручную каждый релиз Именно тут автоматизация раскрывается лучше всего, ты один раз пишешь тест и больше не гоняешь руками одно и то же по сто раз. Сюда же критичные API, на которых держится логика продукта Что стоит покрывать Места, где баги вылезают чаще всего Если какой то модуль регулярно ломается, это прямой кандидат на тесты. И ещё граничные случаи в важной логике, пустые значения, лимиты, некорректные данные, где ошибки особенно вероятны НЕ автоматизируй то, что постоянно меняется Если фича ещё сырая и интерфейс переделывают каждую неделю, тесты будут падать не из за багов, а из за вечных изменений Подожди, пока всё устаканится, и только потом покрывай, иначе будешь чинить тесты быстрее, чем команда меняет дизайн НЕ автоматизируй разовые и редкие сценарии Если что то проверяется раз в полгода руками за пять минут, нет смысла писать и потом годами поддерживать тест Здесь ручная проверка честно дешевле и проще, и это нормально Не лезь автотестами в чистую визуалку и UX Красиво ли смотрится кнопка, удобно ли расположены элементы, приятная ли анимация, — это про человеческий глаз Автотест проверяет логику и факты, а ощущения и внешний вид лучше отдавать живому тестировщику или специальным инструментам визуального сравнения Осторожнее с UI там, где хватает API Если логику можно проверить быстрым и стабильным API тестом, не дублируй это тяжёлым UI сценарием UI оставляй для того, что реально живёт только в интерфейсе, а основную проверку логики уводи на уровень API 📲Простое правило, чтобы решить Перед каждым тестом задай себе три вопроса: — Насколько это критично — Как часто это проверяется — Стабильна ли уже сама фича Если важно, часто и стабильно, автоматизируй смело Если нет, то спокойно оставь это ручной проверке Хороший автоматизатор — это не тот, кто покрыл сто процентов, а тот, кто покрыл то, что приносит максимум пользы при разумной поддержке Автотесты должны экономить время команде, а не превращаться в ещё одну работу, которую все боятся трогать.

С чего начинать автоматизацию тестирования на новом проекте, где еще ничего нет 1️⃣ Сначала не пиши ни одного теста Звучит странно, но первый шаг это не код Сначала разберись, как вообще устроен продукт, где фронт, где бэк, какие сервисы общаются между собой, где база, где очереди. Без этой картины ты будешь автоматизировать вслепую и потом всё переделывать 2️⃣ Поговори с командой и собери боль Иди к ручным тестировщикам и разработчикам и спрашивай, где чаще всего ломается, что проверяют руками каждый релиз, какие баги вылезают регулярно и тд Это и есть твои первые кандидаты на автоматизацию, потому что они дадут максимум пользы сразу 3️⃣ Определись со стеком заранее Не бросайся писать на том, что под рукой, выбери стек осознанно Язык, например Java, фреймворк для запуска, инструменты под API и UI, систему отчётов Лучше потратить день на нормальный выбор, чем через полгода больно переезжать на другой стек 4️⃣ Начни с API, а не с UI Это главный совет, который экономит кучу нервов, API тесты быстрее, стабильнее и проще в поддержке, а UI капризный и любит флакать Покрой сначала ключевую логику через API, получи быстрый результат и доверие команды, а уже потом берись за интерфейс 5️⃣ Сразу заложи нормальную структуру Не лепи всё в один класс, даже если тестов пока три С самого начала раздели код по смыслу, отдельно работа с API, отдельно проверки, отдельно данные. На старте это кажется лишним, но именно это спасает проект, когда тестов станет двести 6️⃣ Покрой сначала smoke сценарии Не пытайся покрыть всё и сразу, это путь в никуда Возьми несколько самых критичных сценариев, без которых продукт просто не живёт, авторизация, главный бизнес поток, оплата. Это твой smoke набор, который первым же ловит, что всё развалилось 7️⃣ Встрой тесты в CI как можно раньше Тесты, которые гоняются только у тебя на ноуте, почти бесполезны Подключи прогон в пайплайн с самого начала, даже если тестов пока мало. Чтобы они запускались автоматически и команда видела результат, иначе про автоматизацию быстро забудут 8️⃣ Договорись с командой Договоритесь, что упавший тест чинят, а не игнорируют, что новые фичи покрываются тестами. Иначе ты в одиночку будешь латать то, что ломают все остальные Строить автоматизацию с нуля это не про то, чтобы за неделю написать сто тестов, это про фундамент: разобрался в продукте, выбрал стек, заложил структуру, покрыл самое важное через API и встроил всё в CI Если сделать все четко на старте, дальше проект будет расти легко, а не превращаться в этакую свалку мусора, которую не хочется открывать

Типичное резюме Senior QA Automation Engineer: - Оптимизация фреймворка UI тестов за счет внедрения умных ожиданий - Ускорение процессов тестирования - Внедрение best practices - Повышение надёжности CI/CD Собеседующий: — Что вы понимаете под умными ожиданиями? Я: — В коде сами указываем сколько времени надо ждать Также последний коммит на гитлабе

+ Thread.sleep(5000);
+ Thread.sleep(1000);
+ Thread.sleep(12000);
+ Thread.sleep(7000);
+ Thread.sleep(8000);

Что такое CI/CD? Когда я был джуном, я реально думал, что CI/CD это какая то жуткая штука для избранных, но на деле всё намного проще и понятнее 1️⃣ CI — это continuous integration, непрерывная интеграция 2️⃣ CD — это continuous delivery или deployment, непрерывная доставка или выкатка Звучит мудрёно, но если совсем просто, это конвейер, который сам собирает, проверяет и выкатывает твой код, без ручной возни Зачем это вообще придумали Если представить команду, где каждый сам собирает проект на своём ноутбуке и руками заливает на сервер, то кто-то в ней забудет прогнать тесты, кто то выкатит не ту версию, и всё развалиться CI/CD убирает человеческий фактор и делает выкатку предсказуемой и повторяемой Что делает CI, непрерывная интеграция Это первая половина конвейера, которая отвечает за сборку и проверку Вы залили код в репозиторий, и пайплайн автоматически собирает проект, прогоняет тесты и проверяет качество. Если что то красное, изменения дальше не идут, и ты узнаёшь о проблеме сразу, а не через неделю Что делает CD, непрерывная доставка Это вторая половина, которая отвечает за выкатку Когда сборка прошла все проверки, код автоматически едет на нужное окружение, на тест, на стейдж, а иногда сразу на прод. Никто не заливает руками, всё делает конвейер по чёткому сценарию Как выглядит пайплайн на практике Пайплайн — это и есть та самая последовательность шагов Обычно так: собрали проект, прогнали юнит тесты, проверили качество кода, прогнали автотесты, собрали отчёт, выкатили на окружение. Каждый шаг должен пройти, иначе конвейер останавливается Где тут место тестировщику Вот тут начинается ваша территория Автотесты живут именно в пайплайне и запускаются автоматически на каждом прогоне. Вааша задача встроить тесты в этот конвейер так, чтобы они ловили баги до прода, а не после. Хороший автоматизатор обязан понимать CI/CD, без этого никак Популярные инструменты Чаще всего вы встретите GitHub Actions, GitLab CI и Jenkins Принцип у всех один, вы описываете шаги пайплайна в конфиге, а система сама их выполняет при каждом изменении кода CI/CD — это не страшная магия, а просто умный конвейер, который берёт на себя рутину сборки, проверки и выкатки Как только вы один раз увидите, как ваш тест автоматически запускается после заливки кода и краснеет при поломке, то уже не захотите возвращаться к ручной возне Это именно та штука, которая превращает набор скриптов в настоящую автоматизацию.

Часто используемые библиотеки в автотестах Когда я только начинал писать автотесты на Java, меня наверное больше всего пугало количество разных библиотек Поэтому разложу основные библиотеки автоматизатора на Java простыми словами, чтобы все сразу понимали, кто за что отвечает 1️⃣ JUnit — это самый популярный фреймворк для запуска тестов. Он даёт аннотации, жизненный цикл теста и структуру, с него обычно и начинают знакомство с автотестами 2️⃣ TestNG — это альтернатива JUnit, чуть менее мощный из коробки. Удобен, когда нужны простые сценарии запуска, группы тестов, приоритеты и параметризация 3️⃣ AssertJ — это библиотека для красивых и читаемых проверок. Вместо сухих ассертов ты пишешь цепочки вроде assertThat объекта, и тест читается почти как обычный текст, а ошибки становятся понятнее 4️⃣ Selenium — это база UI автоматизации в браузере. Через него ты находишь элементы на странице, кликаешь, вводишь текст. Мощный, но местами многословный и капризный 5️⃣ Selenide — это надстройка над Selenium, которая убирает большую часть боли. Умные ожидания, короткий синтаксис, меньше флакающих тестов. Я почти всегда советую новичкам начинать именно с него, а не с голого Selenium 6️⃣ Playwright — это современный инструмент для UI тестов от Microsoft. Быстрый, стабильный, умеет работать с несколькими вкладками и сложными сценариями. Серьёзный конкурент связке Selenium и Selenide 7️⃣ Jackson — это библиотека для работы с JSON. Она превращает json в Java объекты и обратно, что в API тестах нужно постоянно, когда разбираешь ответы сервера 8️⃣ REST Assured — это главный инструмент для API тестов на Java. Дёрнуть ручку, передать параметры, проверить статус и тело ответа, всё это пишется коротко и читаемо 9️⃣Lombok — это библиотека, которая убирает рутину из кода. Геттеры, сеттеры, конструкторы генерируются за тебя через аннотации, и классы моделей перестают раздуваться до сотни строк 1️⃣0️⃣ Awaitility — это спасение для асинхронных проверок. Когда результат появляется не сразу, например прилетает в очередь или базу с задержкой, ты красиво ждёшь нужное условие, а не пихаешь в код грубые паузы 1️⃣1️⃣ Faker — это генератор тестовых данных. Имена, почты, телефоны, адреса создаются автоматически, и тебе не нужно вручную выдумывать данные для каждого прогона Как это всё это уживается вместе? В реальном проекте они обычно работают в связке: JUnit или TestNG запускают тесты, REST Assured дёргает API, Jackson разбирает ответы, AssertJ проверяет результат, Selenide кликает по интерфейсу в браузере, Faker подкидывает данные, Awaitility ждёт асинхронные штуки, а Lombok держит код чистым Не пытайтесь выучить всё разом, это бессмысленно, берите их по мере появления реальных задач, и очень скоро каждая из них ляжет в голову сама собой.

Типичное собеседование на Middle Java Automation: — Расскажите про ClassLoader — Чем отличается HashMap от ConcurrentHashMap? — Как работает сборщик мусора и что такое ShutdownHook? — Как не словить deadlock в многопоточке, про volatile и synchronized? Спустя час собеса... — Отлично, предварительно вы нам подходите — Какие тесты будем писать и как выглядит проект? — У нас крутой современный проект с большими возможностями развития Пример наших тестов на примере файла login.feature:

Функция: Авторизация

Сценарий: Успешный вход

Допустим пользователь открыл сайт
Когда пользователь вводит логин
И пользователь вводит пароль
Тогда пользователь видит главную страницу

— А Java? — Какая Java? У нас Cucumber🥒🤡

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

Почему стоит выбрать Java для автотестов Когда я начинал вкатываться в айти, я где-то месяц метался между языками, неделю учил Python, потом бросал и хватался за что то ещё, и в итоге не двигался вообще никуда Но когда сел за Java и перестал суетиться, дело резко пошло в гору Поэтому, когда меня спрашивают, на чём писать автотесты, я всегда отвечаю: бери Java И вот почему: 1️⃣ Под автотесты собран самый зрелый стек Когда ты пишешь автотесты на Java, у тебя под рукой уже всё готовое JUnit и TestNG для запуска, Selenide и Selenium для UI, REST Assured для API, Allure для отчётов. Это не набор случайных библиотек, а проверенная временем связка, которую крутят тысячи команд каждый день 2️⃣ Огромное количество материалов и примеров По Java автоматизации написано столько, что с любой проблемой ты не остаёшься один Застрял на флакающем тесте или поймал непонятную ошибку, и почти наверняка кто то это уже разбирал до тебя. Для новичка это кайф, ты не выгрызаешь решения в одиночку по ночам 3️⃣ Java правит в крупных компаниях Большая часть серьёзного энтерпрайза живёт именно на Java Банки, маркетплейсы, корпоративные системы, всё это чаще всего написано на ней. А раз так, то и автотесты там ждут на Java, и спрос на таких автоматизаторов держится стабильно высоким 4️⃣ Строгость языка играет тебе на руку Да, Java строже Python, и поначалу это бесит, в том числе бесило и меня Но именно эта строгость не даёт наделать глупостей и приучает писать аккуратно. На больших проектах это окупается сторицей, потому что код остаётся читаемым даже спустя полгода 5️⃣ Отлично масштабируется на больших проектах Когда тестов становится сотни и тысячи, главное, чтобы всё это не превратилось в свалку Java со своей структурой, типами и зрелыми инструментами помогает держать порядок. Архитектуру на ней строить удобно, и она не рассыпается с ростом проекта 6️⃣ Деньги и вакансии Java автоматизаторов ищут постоянно, вакансий море, и платят очень хорошо, ты вкладываешься в язык, под который всегда есть денежный и стабильный спрос Если учишь Java, то будет чуть тяжелее войти, зато потом перед тобой открывается рынок, который реально тебя ждёт Лично я ни разу не пожалел о том, что сделал этот выбор, и вам также советую🤝

Пошаговый план как начать работать в IT с нуля Продолжаем серию постов для новичков, сегодня решил дать подробный план, как и с чего начинать работу в IT 1️⃣ База по клиент серверной архитектуре Прежде чем писать тесты, нужно понимать, как вообще устроены приложения Что такое клиент и сервер, как они общаются между собой, что такое запрос и ответ, зачем нужны статус коды. Без этой картины в голове всё остальное будет просто набором непонятных слов 2️⃣ Язык программирования Дальше выбираешь один язык и качаешь его, например Java или Python Переменные, циклы, ООП, коллекции, работа с функциями. Не нужно становиться разработчиком, но базу надо чувствовать уверенно, потому что на ней держится вообще всё 3️⃣ Библиотеки для тестирования Теперь учишься писать настоящие тесты, а не просто скрипты Это фреймворки вроде JUnit или pytest. Тут появляются ассерты, структура тестов и жизненный цикл, и ты впервые понимаешь, как всё работает под капотом 4️⃣ Автоматизация браузера Дальше идёт UI автоматизация, например Selenium или Selenide Ты учишься находить элементы на странице, кликать, заполнять формы и проверять результат кодом. Здесь же встретишь первые флакающие тесты, через которые проходят вообще все 5️⃣CI/CD Когда тесты запускаются только у тебя на компьютере, это ещё не автоматизация Нужно уметь прогонять их в пайплайне, например в GitHub Actions или Jenkins, видеть общий отчёт и понимать, почему сборка упала ночью перед релизом 6️⃣ Моки Дальше учишься подменять внешние сервисы заглушками Это нужно, когда реальная система недоступна или её дорого дёргать. Моки делают тесты стабильнее и быстрее, и это уже уровень крепкого автоматизатора 7️⃣ Kafka и всё остальное А вот это уже про более взрослые проекты Очереди сообщений вроде Kafka, работа с базами напрямую, разные протоколы интеграций. Это приходит позже, когда база уже твёрдо стоит на ногах 📲Не пытайся учить всё сразу, это самый верный способ перегореть на старте Иди по шагам, от архитектуры к языку и дальше вглубь. Каждый следующий пункт ложится на предыдущий, и в какой то момент ты вдруг понимаешь, что уже умеешь то, что полгода назад казалось магией.