Валерий | AQA Engineer | Автотестирование на Python | REST, gRPC, GraphQL

Привет! Уже на следующей неделе у меня стартуют. Автоматизация тестирования брокеров сообщений Результат: Научитесь автоматизации тестирования сложных асинхронных систем. Напишите клиенты для kafka и rabbitmq, автоматизируете длинные интеграционные сценарии, проходящие проходящие через 2 API, 2 Брокера сообщений, почтовый сервер. Научитесь работать с многопоточностью. Изучите новые архитектурные приемы и паттерны, овладеете сложной темой востребованной на рынке. Да и просто станете круче как инженеры. 🗓 Неделя 1: Kafka Producer 7 Уроков. Поговорим про брокеры сообщений, как они устроены, научимся публиковать сообщения в топики, узнаем когда нужно работать с кафка в автотестах и зачем. 🗓 Неделя 2: Kafka Consumer 5 Уроков. Научимся использовать паттерны проектирования singleton и observer, будем использовать python потоки и примитивы синхронизации. Будем слушать топики и научимся работать с блокирующими задачами. И рассмотрим проблемы которые возникают при тестировании брокеров сообщений. 🗓 Неделя 3: RabbitMQ 5 Уроков. Научимся работать RabbitMQ, узнаем что такое обменники, очереди, будем публиковать и слушать сообщения из очереди. REST API Advanced Результат: Вы создадите production-ready фреймворк с архитектурой уровня энтерпрайз систем. Сможете с нуля настроить CI/CD pipeline с метриками и уведомлениями. Одного моего друга пригласили на Senior позицию, после того как он показал свой проект и рассказал, что и как он сделал. 🗓 Неделя 1: Введение в автоматизацию тестирования 10 уроков. Повторим основы Python, научимся генерировать простой код, рассмотрим базу API тестирования, напишем первые тесты и настроим автоматический прогон тестов в GitHub. 🗓 Неделя 2: Архитектура и работа с данными 4 урока. Научимся использовать паттерны проектирования для решения наших задач. А также научимся подготавливать тестовые данные и рассмотрим различные виды фикстур. 🗓 Неделя 3: Проверки 7 уроков. Рассмотрим все возможные виды проверок для API, научимся валидировать структуру данных и значения. Мягкие проверки, функции-чекеры, менеджеры контекста. Будем внедрять так, чтобы не засорять код и делать его более читаемым и поддерживаемым. 🗓 Неделя 4: Работа с конфигурациями и репортинг 7 уроков. Завершающая неделя: научимся собирать Docker образы, настраивать пайплайны, дорабатывать сторонние библиотеки, собирать coverage покрытия сервиса автотестами, строить красивые и информативные отчёты. Научимся отправлять отчёты о прохождении тестов в Telegram и перепишем пайплайн для GitLab CI. REST API Professional Результат: Вы научитесь создавать инструменты, которые делают работу за целые команды. Пока другие пишут код руками, вы генерируете готовые решения одной командой. Компании будут переманивать вас не за навыки, а за инструменты, которые вы умеете создавать. 🗓 Модуль 1: Поговорим, что такое платформа и для чего она нужна 🗓 Модуль 2: Научимся управлять зависимостями как профессионалы. Перепишем код, используя асинхронную парадигму, и рассмотрим, для каких задач она применима. 🗓Модуль 3: Научимся поддерживать стандарты и качество кода, разработаем общий пайплайн для контроля качества кода всех проектов, будем использовать линтеры и форматтеры. 🗓 Модуль 4: Рассмотрим различные инструменты для генерации структуры проекта и кода. Научимся собирать свои библиотеки и дорабатывать опенсорс инструменты, выдавая стабильный результат в отличие от использования ИИ. 🗓 Модуль 5: Соберём CLI инструмент, который генерирует всё: проект, клиенты, тесты, фикстуры. Стань еще круче как инженер. Приходи)

Несколько месяцев назад я спросил, какой технический тренинг вам был бы действительно интересен. Из всех вариантов больше всего реакций и комментариев собрала тема брокеров сообщений. Это не удивительно. Знания Kafka, RabbitMQ встречаются всё чаще в вакансиях а у многих нет возможности даже пощупать эти технологии, не говоря уже об автоматизации, которая значительно отличается от темы REST API или UI. Качественных материалов, которые объясняют не только “как настроить”, но и “как это работает на самом деле”, не так много. Особенно если смотреть на материалы для QA, автоматизаторов и инженеров, которым важно понимать систему целиком. Курс уже обкатан на нескольких потоках и хорошо себя зарекомендовал. Получился именно тот тренинг, который мне самому хотелось бы пройти несколько лет назад, когда приходилось собирать знания по кусочкам делая много проб и ошибок. Так что уже совсем скоро стартуем, 15 июня. Приходи, будет интересно. Это последний поток по текущей стоимости, более того я подготовил скидку 10% по промокоду DIS10 5 поток будет уже дороже. Спасибо всем, кто когда-то проголосовал за эту тему. Фактически именно благодаря вашему интересу этот курс появился. Так же напомню про уже проверенный тренинг REST API Advanced, который позволит вам понимать как грамотно строить архитектуру тестового фреймворка. Это полезно всем, особенно тем кто использует нейросети, чтобы можно было валидировать результат работы ИИ. Так что всех жду и сразу анонсирую, стоимость тренингов будет повышена.

Материалы для тех, кто в теме. Одна из самых больших проблем при развитии в IT - это возможность найти доступный материал не для новичков. Помню, когда я был в автоматизации тестирования, у меня был момент, когда я понимал, что на текущем месте и в текущем коллективе я самый крутой, но от этого было не весело, от этого было грустно. Я начал смотреть другие вакансии, какие там есть технологии, чтобы была возможность развиваться. Я обсуждал это со своими друзьями-коллегами, и тогда мне дали контакт человека, который уже работал в нашей компании, но ушёл в другую. С их слов, он был очень крутой, и честно - не хотели делиться его контактом, потому что боялись, что он меня переманит. Справедливости ради, в дальнейшем он предложил мне перейти к ним - это уже другая история, но я сейчас о другом. Мне дали его контакт в линке и я ему выложил всю свою боль как на духу. Мы быстро нашли общий язык и он меня понял) В тот момент я получил новый виток развития. Я узнал от него о тогда ещё не такой популярной теме, как кодогенерация, про настройку пайплайнов для обновления пакетов. Тогда я уже умел писать код, но не понимал, как с этим работать. Он не сказал, что и как мне делать, но поселил во мне идеи и подходы. Это был один из самых интересных периодов в моей карьере, я был первопроходцев в своем отделе и почти все делал с нуля, просто находил и писал людям которых даже не знал, чтобы они рассказали мне как настроить пайплайн и воткнуть туда кодген. С настальгией вспоминаю, как после работы сидел с 7 вечера до 5 утра чтобы завести пайплайн и какое было ощущение счасться когда все начало работать. Сейчас с клаудкодом или другой ИИ-шкой я бы сделал это быстрее, но какой было ощущение победы, я думаю многим оно знакомо) Этого стимула мне хватило ещё на два года. Если смотрели мою историю, то там как раз есть раздел про кодогенерацию - только изначально я писал её сам, а потом узнал, что есть готовые инструменты, и стал использовать их. Потом я всё равно вернулся в разработку собственных инструментов, и у меня есть проекты, например такие как pbreflect, restcodegen, e2efast. К чему я это всё? Если честно, мне иногда кажется, что я несу некую миссию для таких же заблудших душ, каким был я после трёх лет в автоматизации тестирования, которые уже и не новички, но чувствуют, что есть куда расти, и не понимают, как и что можно улучшить в своём текущем коде или процессах. Так что если вы сейчас читаете это и узнаёте себя - вы не одни. Я здесь как раз для того, чтобы показывать, что за горизонтом есть ещё куча всего интересного. Вопрос только в том, чтобы найти своего проводника. Или стать им для кого-то) TG-сообщество | Обучение |Отзывы

Как улучшить TTM выкатки сервиса и ускорить пайплайн автотестов Базово пайплайн чаще всего состоит из 4 шагов: 1. Сборка образа приложения 2. Запуск приложения 3. Сборка образа тестов 4. Запуск автотестов Теперь вопрос — что тут можно реально ускорить? Если говорим про Python, то первое что можно оптимизировать — сборку образов. Большинство до сих пор используют pip, но есть еще как минимум: — Poetry — uv И вот uv сейчас выглядит очень интересно. За счет того что он написан на Rust — установка зависимостей работает в несколько десятков раз быстрее. На практике только за счет замены pip - uv можно спокойно срезать около минуты на старте сервиса и сборке контейнера. Ту же самую оптимизацию можно провернуть и для образа автотестов. Второй момент, который кажется очевидным, но как выяснилось — не для всех 😄 Python тесты можно запускать параллельно. Золотой стандарт сейчас — pytest-xdist Он позволяет реально запускать тесты в несколько процессов/воркеров. Даже на обычном маке ускорение может быть x4-x8 в зависимости от количества ядер. Пример: pytest -n auto или pytest -n 8 Если используете аллюр: pytest -n auto --alluredir=allure-results Полезные плагины: — pytest-parallel — pytest-concurrent — pytest-asyncio-concurrent Но тут важно понимать — они подходят только если тесты не конфликтуют между собой и могут безопасно работать конкурентно. Следующий уровень оптимизации — запускать не все тесты. Например: у вас 1000+ тестов, но изменения затронули только платежи. Зачем гонять вообще весь регресс? Можно размечать тесты по фичам через markers и запускать только нужные. Пример: @pytest.mark.payments def test_create_invoice(): ... Запуск: pytest -m payments Или через Allure labels/tags: @allure.feature("Payments") @allure.story("Invoices") Еще один огромный bottleneck — подготовка тестовых данных. На сложных интеграционных сценариях подготовка данных может занимать больше времени чем сами тесты. Что можно сделать: — вынести подготовку данных в отдельный сервис — складывать подготовленные данные в БД — отдавать их тестам через API — использовать session fixtures — готовить данные фоном во время тестовой сессии Например: пока идут первые тесты — в фоне уже готовятся данные для следующих. Хранить это можно хоть в SQLite, Redis или отдельной тестовой БД. Еще хороший кейс — авторизация. Очень часто вижу как тест: — логинится — получает токен — делает запрос — заканчивается И так 500 раз подряд 😄 Хотя можно сделать клиент который: — фоново обновляет токен — кеширует его — следит за TTL — отдает уже актуальный access token тестам В итоге минус сотни лишних запросов в auth сервис. Если суммировать, то основные точки ускорения это: - Быстрая сборка образов - Параллельность - Конкурентность - Запуск только нужных тестов - Предподготовка тестовых данных - Фоновые задачи - Кеширование авторизации И за счет этого можно очень сильно срезать время прохождения пайплайна и улучшить TTM выкатки TG-сообщество | Обучение |Отзывы

Как улучшить TTM выкатки сервиса и ускорить пайплайн автотестов Базово пайплайн чаще всего состоит из 4 шагов: 1. Сборка образа приложения 2. Запуск приложения 3. Сборка образа тестов 4. Запуск автотестов Теперь вопрос — что тут можно реально ускорить? Если говорим про Python, то первое что можно оптимизировать — сборку образов. Большинство до сих пор используют pip, но есть еще как минимум: — Poetry — uv И вот uv сейчас выглядит очень интересно. За счет того что он написан на Rust — установка зависимостей работает в несколько десятков раз быстрее. На практике только за счет замены pip - uv можно спокойно срезать около минуты на старте сервиса и сборке контейнера. Ту же самую оптимизацию можно провернуть и для образа автотестов. Второй момент, который кажется очевидным, но как выяснилось — не для всех 😄 Python тесты можно запускать параллельно. Золотой стандарт сейчас — pytest-xdist Он позволяет реально запускать тесты в несколько процессов/воркеров. Даже на обычном маке ускорение может быть x4-x8 в зависимости от количества ядер. Пример: pytest -n auto или pytest -n 8 Если используете аллюр: pytest -n auto --alluredir=allure-results Полезные плагины: — pytest-parallel — pytest-concurrent — pytest-asyncio-concurrent Но тут важно понимать — они подходят только если тесты не конфликтуют между собой и могут безопасно работать конкурентно. Следующий уровень оптимизации — запускать не все тесты. Например: у вас 1000+ тестов, но изменения затронули только платежи. Зачем гонять вообще весь регресс? Можно размечать тесты по фичам через markers и запускать только нужные. Пример: @pytest.mark.payments def test_create_invoice(): ... Запуск: pytest -m payments Или через Allure labels/tags: @allure.feature("Payments") @allure.story("Invoices") Еще один огромный bottleneck — подготовка тестовых данных. На сложных интеграционных сценариях подготовка данных может занимать больше времени чем сами тесты. Что можно сделать: — вынести подготовку данных в отдельный сервис — складывать подготовленные данные в БД — отдавать их тестам через API — использовать session fixtures — готовить данные фоном во время тестовой сессии Например: пока идут первые тесты — в фоне уже готовятся данные для следующих. Хранить это можно хоть в SQLite, Redis или отдельной тестовой БД. Еще хороший кейс — авторизация. Очень часто вижу как тест: — логинится — получает токен — делает запрос — заканчивается И так 500 раз подряд 😄 Хотя можно сделать клиент который: — фоново обновляет токен — кеширует его — следит за TTL — отдает уже актуальный access token тестам В итоге минус сотни лишних запросов в auth сервис. Если суммировать, то основные точки ускорения это: - Быстрая сборка образов - Параллельность - Конкурентность - Запуск только нужных тестов - Предподготовка тестовых данных - Фоновые задачи - Кеширование авторизации И за счет этого можно очень сильно срезать время прохождения пайплайна и улучшить TTM выкатки TG-сообщество | Обучение |Отзывы

Всем привет! Вчера на меня подписалось аж 30 человек, что я не мог не заметить. Скажите плз откуда вы пришли?)) Потому, что я прошелся по всем каналам с кем мы дружим и не нашел ни одного упоминания меня 🤔 Представлюсь. Меня зовут Валерий Меньшиков. Я Руководитель группы разработки Python платформы, до этого я более 6 лет работал как QA Automation Engineer и около двух лет как старший python разработчик, ну а начинал с ручного тестирования, поэтому что-то знаю и понимаю) В этом канале я делюсь информацией по автоматизации тестирования на Python и раскрываю сложные темы автоматизации: такие как kafka, gRPC, REST, GraphQL, работу с различными базами данных, кодогенерацию и многое другое. Если ты хочешь научиться писать код своих автотестов красиво и правильно или научиться автоматизировать что-то из перечисленного выше, добро пожаловать. Актуальные даты тренингов можно найти на сайте aqa-engineer.com ‼️ Кстати ты почти опоздал(а), ближайший старт тренингов уже 11 мая, следующий поток пока не планировал) После моих тренингов ни у кого не остается вопросов. А как мы знаем у этого есть две причины: 1. Что тут спрашивать если и так все понятно? 2. Что тут спрашивать если ничего непонятно? 😃 Я думаю причина все-таки под номером 1) Ну и коротко, мой путь можно посмотреть в видосике, хорошо бы его актуализировать, там нехватает последних 3 лет, но может как-нить сделаю) САМЫЕ ИНТЕРЕСНЫЕ на мой взгляд посты с которых можно начать: - Почему стоит изучать автоматизацию тестирования? - С чего начать автоматизацию Джуну на проекте? 🤔 - Как развернуть автоматизацию тестирования API за неделю? - Python: почему это идеальный язык для автоматизации? - Как устроено наше тестируемое приложение? - Почему стоит учиться у меня? - Ты не хуже у тебя просто не было нужного тренера - Одна из самых больших ошибок, которую можно совершить СПОСОБЫ ПОСТРОЕНИЯ ТЕСТОВОЙ АРХИТЕКТУРЫ: часть1, часть2, часть3 KAFKA: - Серия постов как работать с кафка в автотестах тут gRPC: - Статья про gRPC и работу с ним в автотестах ПРИНЦИПЫ РАЗРАБОТКИ: - DRY (Don't Repeat Yourself) - KISS (Keep It Simple, Stupid) - YAGNI (You Ain’t Gonna Need It) - S. O. L. I. D ТИПИЗАЦИЯ: - “Если оно ходит как утка… 🦆” — питон не требует паспорта. - Гусиная типизация — когда утки 🦆 недостаточно (а интерфейс всё-таки нужен) - Статическая утиная типизация — когда нужно понять, что это утка, ещё до запуска. - Статическая типизация в Python — когда уткам уже не доверяешь 🧊 ДОКЛАДЫ: - Доклад с QA Python Meet Up туть - Доклад с ECODE2025 Список, буду потихоньку дополнять) TG-сообщество | Обучение |Отзывы

Всем привет! Давно не виделись - я к вам с новостью. Какой, спросите вы? Как вы помните, около двух лет назад я перешёл в разработку. Уровень компетенций моей новой команды на Python очень высокий. Первые полгода я чувствовал себя на грани выгорания: много думал, писал код, чтобы наверстать этот разрыв. За это время было сделано много всего. - мой бэкграунд дал неплохой буст в развитии нашего фреймворка для QA-платформы. - огромный опыт я получил при разработке Python-клиента к нашему Kafka-proxy с кодовым названием Databus почитать можно тут. - были задачи и по разработке механизмов обеспечения безопасности, по ротации токенов, и написание клиентов к различным ресурсам. - да и много чего ещё было сделано. Когда я переходил в Python-платформу разработчиком, мой предыдущий руководитель сказал: «Не удивлюсь, если ты в скором времени станешь там руководителем». «Хорошая шутка», - подумал я. Мог ли я тогда подумать, что такое случится? Ну и, собственно, новость: 😎 теперь я руководитель группы разработки Python-платформы. Python занимает большую часть в нашей компании: разработка сервисов, Data Science, ML, автотестирование. Это большая ответственность - держать нашу Python-платформу на том же уровне качества держать весь этот огромный контекст и главное делать её лучше. Если честно, даже мировоззрение немного меняется: чувствуешь, как напрягаются брови при просмотре MR или ответе на какие-то вопросы, потому что ощущаешь груз ответственности. Для меня это новый вызов и новые возможности. Ну а для вас - это новые фичи и приёмы из мира разработки, которые можно применять в автотестировании. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Дорогие девушки 🌸 Поздравляю вас с этим прекрасным днём) Благодаря вам наша жизнь более интересная, насыщенная и комфортная. Все отпуска, рестораны, выставки это ваша заслуга большинству мужчин это нафиг не нужно 😄 Спасибо вам за внимательность, терпение, острый взгляд на детали и способность находить то, что другие никогда бы не заметили. Благодаря вам продукты становятся лучше, а команды — сильнее. Пусть в жизни будет много радости, вдохновения, интересных задач, отпусков и времени для себя. А чтобы вы могли стать еще круче и умнее дарю скидку на все тренинги 20%, а мужчинам чтобы эти 20% были сэкономлены и ушли нашим прекрасным девушкам на подарки 💍)). Промокод 8MARCH , действует до 9 марта. https://aqa-engineer.com/index С праздником! 🌷

Привет! Уже на следующей неделе у меня стартуют. Автоматизация тестирования брокеров сообщений Результат: Научитесь автоматизации тестирования сложных асинхронных систем. Напишите клиенты для kafka и rabbitmq, автоматизируете длинные интеграционные сценарии, проходящие проходящие через 2 API, 2 Брокера сообщений, почтовый сервер. Научитесь работать с многопоточностью. Изучите новые архитектурные приемы и паттерны, овладеете сложной темой востребованной на рынке. Да и просто станете круче как инженеры. 🗓 Неделя 1: Kafka Producer 7 Уроков. Поговорим про брокеры сообщений, как они устроены, научимся публиковать сообщения в топики, узнаем когда нужно работать с кафка в автотестах и зачем. 🗓 Неделя 2: Kafka Consumer 5 Уроков. Научимся использовать паттерны проектирования singleton и observer, будем использовать python потоки и примитивы синхронизации. Будем слушать топики и научимся работать с блокирующими задачами. И рассмотрим проблемы которые возникают при тестировании брокеров сообщений. 🗓 Неделя 3: RabbitMQ 5 Уроков. Научимся работать RabbitMQ, узнаем что такое обменники, очереди, будем публиковать и слушать сообщения из очереди. REST API Advanced Результат: Вы создадите production-ready фреймворк с архитектурой уровня энтерпрайз систем. Сможете с нуля настроить CI/CD pipeline с метриками и уведомлениями. Одного моего друга пригласили на Senior позицию, после того как он показал свой проект и рассказал, что и как он сделал. 🗓 Неделя 1: Введение в автоматизацию тестирования 10 уроков. Повторим основы Python, научимся генерировать простой код, рассмотрим базу API тестирования, напишем первые тесты и настроим автоматический прогон тестов в GitHub. 🗓 Неделя 2: Архитектура и работа с данными 4 урока. Научимся использовать паттерны проектирования для решения наших задач. А также научимся подготавливать тестовые данные и рассмотрим различные виды фикстур. 🗓 Неделя 3: Проверки 7 уроков. Рассмотрим все возможные виды проверок для API, научимся валидировать структуру данных и значения. Мягкие проверки, функции-чекеры, менеджеры контекста. Будем внедрять так, чтобы не засорять код и делать его более читаемым и поддерживаемым. 🗓 Неделя 4: Работа с конфигурациями и репортинг 7 уроков. Завершающая неделя: научимся собирать Docker образы, настраивать пайплайны, дорабатывать сторонние библиотеки, собирать coverage покрытия сервиса автотестами, строить красивые и информативные отчёты. Научимся отправлять отчёты о прохождении тестов в Telegram и перепишем пайплайн для GitLab CI. REST API Professional Результат: Вы научитесь создавать инструменты, которые делают работу за целые команды. Пока другие пишут код руками, вы генерируете готовые решения одной командой. Компании будут переманивать вас не за навыки, а за инструменты, которые вы умеете создавать. 🗓 Модуль 1: Поговорим, что такое платформа и для чего она нужна 🗓 Модуль 2: Научимся управлять зависимостями как профессионалы. Перепишем код, используя асинхронную парадигму, и рассмотрим, для каких задач она применима. 🗓Модуль 3: Научимся поддерживать стандарты и качество кода, разработаем общий пайплайн для контроля качества кода всех проектов, будем использовать линтеры и форматтеры. 🗓 Модуль 4: Рассмотрим различные инструменты для генерации структуры проекта и кода. Научимся собирать свои библиотеки и дорабатывать опенсорс инструменты, выдавая стабильный результат в отличие от использования ИИ. 🗓 Модуль 5: Соберём CLI инструмент, который генерирует всё: проект, клиенты, тесты, фикстуры. Стань еще круче как инженер. Приходи)

Привет, уже есть первые отзывы на курс по брокерам и могу сказать. Что рекомендую его к посещению) Почему? Kafka и RabbitMQ есть почти в каждом высоконагруженном backend-проекте. А вот хороших тренингов по автотестированию для них - почти нет. При просмотре документации драйверов для брокеров кажется, что все просто. ИИ с радостью выдаст первый рабочий код, но проблемы начинаются чуть позже. Тестирование брокеров сообщений - это не REST API. Возникает множество проблем, например, тесты: - начинают зависать при прослушивании топика. - отваливаются по тайм-ауту. - не могут найти нужное сообщение. - работают так долго, что это сильно влияет на ТТМ и их проще отключить. При этом знание Kafka / RabbitMQ и умение тестировать асинхронные системы всё чаще требуется от QA Automation-инженеров - особенно в больших компаниях. Для этого я собрал практический онлайн-курс по автоматизации тестирования Kafka и RabbitMQ на Python, основанный на самых популярных брокерах сообщений. В курсе: - как устроены Kafka и RabbitMQ с точки зрения тестирования - интеграционные и E2E-сценарии с несколькими сервисами - синхронизация асинхронных и конкурентных событий - многопоточность в автотестах - применение паттернов проектирования - практика на Python + код-ревью Формат обучения: 📆 5 недель 🎥 видео-уроки 💬 Telegram-чат ⌨️ упор на практику Кому подойдёт: QA Automation инженерам, которые уже тестируют backend и пишут автотесты на Python. Курс не рассчитан на новичков с нуля. ⚠️ Небольшая группа. 👉 Программа и регистрация: https://aqa-engineer.com/brokers Старт уже в марте, следующий поток только в мае)

С 23 февраля! Поздравляю всех, кто берёт на себя ответственность, держит слово и умеет доводить дела до конца. В наше время это ценится гораздо больше, чем громкие слова. Главное пожелание - мирного неба над головой. Сегодня принято поздравлять мужчин, но без настоящих женщин не было бы настоящих мужчин. И многие девушки, например медики, тоже имеют военный билет, поэтому этот день про силу характера, а не про пол. А чтобы вы могли расти профессионально, проявлять свои сильные качества и направлять энергию в мирное русло в честь праздника дарю скидку 15% на мои тренинги. Промокод: 23FEB Скидка действует до 26 февраля. Пусть будет больше силы, устойчивости и уверенности в жизни и в профессии. Актуальные тренинги тут.

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

Типовая архитектура backend-автотестов на Python У меня сейчас доучивается группа по автотестам и самая сложная неделя это вторая когда мы начинаем активно внедрять всякие архитектнурные штуки. Почему вообще во всех тренингах я акцентирую на этом внимание, да потому что одна из самых частых причин, почему автотесты превращаются в мусор это отсутствие архитектуры. Тесты пишутся, они даже проходят. А потом: - их страшно менять - они часто падают - тяжело понять, где что сломалось Ниже - базовая архитектура backend-автотестов, которую я рекомендую у себя в тренингах. Layers: Transport / API Client / Services (Helpers) / Tests 1. Transport уровень HTTP/GRPC - технический слой На этом уровне лучше всего реализовывать логгирование, закреп attach в аллюр и тп.

class HTTPClient:
  def request(*args, **kwargs) -> Response:
      log.debug(f"Request send with params: {args, kwargs}")

2. API Client - уровень сервиса. На этом уровне происходит валидация контрактов, сериализация / десериализация , структур запросов и ответов.

class PetstoreApi:
  def __init__(self, client: HTTPClient) -> None:
    ...
    
  def post_pet(self, request_model: PetModelRequest) ->  PetModelResponse:
      ...

3. Services (Helpers) - уровень бизнес логики Здесь мы можем реализовывать как методы которые просто оборачивают методы из класса Api Client. Так и реализовывать какую то "композитную логику", которая выполняет целый бизнес флоу для какого то действия.

class PetStoreHelper:
  def __init__(self, petstore_api: PetstoreApi) -> None:
    self._petstore_api = petstore_api
    
  def create_pet(name: str, kind: str) -> PetModelResponse
    request_model = PetModelRequest(name, kind)
    self._petstore_api.post_pet(request_model=request_model)
    ...

4. Tests - уровень тестов Здесь описываются уже конкретный сценарии из методов описанных в классе помощнике.

def test_create_pet(petstore_helper: PetStoreHelper) -> None:
     response = petstore_helper.create_pet('sharik', 'dog')
     assert response

Что нам это дает? 1. Понятные и читабельные сценарии, где ясно что происходит, легко писать тесты из готовых шагов. 2. Легче поддерживать. 1. Меняется формат логов? Достаточно это сделать на уровне транспорта и фреймворк все подтянет автоматически. 2. Меняется контракт? Достаточно внести изменения на уровне Helper 3. Меняется endpoint для Api метода, достаточно внести изменения на уровне Api Client То есть несмотря на кажущуюся сложность в разделении уровней и дополнительных абстракций, нам легко понять где и на каком уровне необходимо вносить изменения , а это вклад в легко поддерживаемый фреймворк и свой душевный покой. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

💙 Валентинка может сказать много о чувствах. Наш чек-лист — ещё больше. Ставьте 💙, если хоть один знак любви имеется. P. S. И кстати, с Днём компьютерщика!

gRPC традиционно вызывает панические атаки. А если говорить про тестирование на Python, слабонервных лучше убрать от экранов. Но если вы хотите узнать, как просто генерировать клиентов и создавать собственные плагины для protoc, усаживайтесь поудобнее. Мы подготовили карточки⬆️ Для тех, кто хочет полного погружения, предлагаем доклад ⬅️ старшего разработчика нашей Python-платформы и автора библиотеки PBReflect ⬅️Валерия Меньшикова. #ozontech_experts #python

Недавно в линке увидел пост, где коллега искал человека или школу которые смогут обучить команду НЕ начинающих автоматизаторов, а людей с опытом. На самом деле его запрос был необычный. Там были и базовые вещи, но из того, что мне показалось интересным в его запросе это "Абстрактные классы", "Интерфейсы", "Алгоритмы", "Эффективное использование многопоточности", на python. Не могу говорить за тенденцию, но немного повангую, а может пофантазирую. В связи с активным использованием ИИ, просто написать рабочий код уже не является преимуществом в профессии или каким то чудом, это делается как раз легко. Так что этап когда сотрудник, не просто пишет рабочий код, а понимает как писать хороший код, понимает хорошие практики и может валидировать ИИ вполне себе вписывается в эту модель развития. Можно ли без этих знаний писать автотесты? В 90% случаев да и довольно неплохие. Могу предлположить, что скоро, да и уже от многих AQA просят писать QА сервисы, разрабатывать свои инструменты автоматизации. И вот как раз сюда требуемые знания ложатся прекрасно. Что касается меня, я конечно предложил свои программы для его команды, там пусть сами думают) Но отдельно тренинг под его команду я разрабатывать не буду, мне лень, да и тем более у меня уже есть рабочий материал. Ведь изначально идея моих тренингов была такая, что я хотел давать такие темы, которые обычно в курсах по автоматизации не рассматриваются и которых капец как не хватато мне, когда я рос как автоматизатор. Многие вещи я набивал только практикой, а многие знания до сих пор можно узнать только из (представьте себе) книг, не потому что их не знает чат гпт, а потому, что человек который работает с ИИ не знает, что спросить, а в книгах все идет структурировано и по порядку, и тренингов по сложным темам и с хорошей подачей днем с огнем не сыскать. Я всегда упарывался над архитектурой тестов, поэтому у меня много посвящается внимания этим темам. Темы асинхронки и многопоточности так же присутствуют в моих тренингах в привязке для решения конкретных задач. Наверное закономерно, но это привело меня в разработку, да еще и в команду python платформы, чем я безумно горжусь) Команда которая так же как и я упарывается над архитектурой и от которой я очень многому научился. К чему я это все, к тому что наверное я очень хочу выдавать желаемое за действительное, и чтобы количество написанного кода перерастало в качество) Чтобы автоматизаторы развивались и чтобы моя светлая идея выращивать топовых инженеров развивалась.

REST API тестируют почти все. А вот делают это на действительно продвинутом уровне - немногие. Часто автотесты API: - сложно поддерживать - тяжело масштабировать - архитектура разваливается со временем - новые сценарии добавляются через боль - код превращается в набор костылей Если ты уже пишешь API-автотесты на Python, то рано или поздно упираешься не в синтаксис и библиотеки, а в архитектуру, подходы и качество решений. Уже на следующей неделе я запускаю практический онлайн-тренинг REST API Advanced. Это курс не про «как отправить запрос», а про то, как строить и поддерживать промышленную автоматизацию API. Что будет в курсе: - архитектура автотестов REST API - масштабируемые и поддерживаемые тестовые фреймворки - работа с контрактами и моделями данных - паттерны проектирования в API-автотестах - улучшение читаемости и качества тестового кода - практика на Python + код-ревью - CI-CD, Coverage, Репортинг и многое другое. Формат обучения: 📆 5 недель 🎥 видео-уроки 💬 Telegram-чат ⌨️ много практики Кому подойдёт: QA Automation инженерам и SDET, которые уже тестируют REST API на Python и хотят перейти с “рабочих тестов” на профессиональный уровень. ❗️ Курс не для новичков с нуля. 👉 Программа и подробности: https://aqa-engineer.com/rest_api_advanced ‼️ОСТАЛОСЬ ВСЕГО 2 МЕСТА‼️ Начинаем в следующий понедельник.

Отзыв на тренинг "REST API Test Automation (Advanced)" от Валерия Меньшикова Начну с того, что на всеразличных онлайн курсах по автоматизации тестирования (вполне себе хороших и не очень) я уже "собаку сЪел", поэтому есть с чем сравнить. Все эти курсы объединяет одно: упор сделан на web-автоматизацию на selenium с применением паттерна PageObject, а REST API уделяется совсем немного внимания (1, максимум 2 урока), хотя, казалось бы, API идеально подходит для автоматизации в первую очередь. Поэтому искал именно курс, на котором покажут и расскажут как можно выстроить структуру проекта по автоматизации именно API, и каким-то чудом наткнулся на этот тренинг от Валерия Меньшикова. На тренинг лучше идти с уверенным знанием синтаксиса языка python, пониманием структур данных языка, циклов, ветвлений и базовым представлением об ООП. Хоть на курсе и есть занятие по основам python (знаю, что Валерий добавил его по просьбам учащихся), но всё же лучше изучить их где-нибудь на других платформах. По сути курс начинается с написания автотеста, который после 1-го занятия представляет длинную простыню трудно читаемого кода (чего???). Но потом начинается самое интересное: мы начинаем изучать всеразличные паттерны пректирования, такие как proxy, facade, decorator, начинаем применять различные инструменты для конфигурирования проекта, валидации запросов и ответов, проверок и много чего еще. В результате эта "длинная простыня трудно читаемого кода" превращается в легко поддерживаемый фреймворк, а сами тесты становятся читаемыми и понятными. Одного взгляда на автотест хватит, чтобы понять что там происходит и что проверяется. Валерий учит не просто писать автотесты, а делать это так, чтобы в случае чего можно было быстро внести какие-то изменения, и всё продолжит работать. При этом всём так же прокачиваются навыки разработки в целом. Ну и вишенкой на торте является прикручивание понятного и читаемого allure-отчета, отчета о покрытии приложения тестами, настройка CI в GitHub Actions и GitLab CI с нотификацией результатов тестирования в канал телеграм через бота. Тренинг действительно можно назвать "уникальным", ибо навряд ли где-то можно найти что-то подобное. От меня 10 из 10 и большое спасибо Валерию за то, что делится такими бесценными знаниями.

Коллеги, привет! 25.01.2026 в 13:00 (MSK) проведу открытый урок (40–60 мин) в рамках курса по тестированию бэкенда: «Работа с OpenSearch и анализ логов». Разберём: 🕵🏻‍♂️ что такое логи и уровни логирования, 🕵🏻‍♀️ как искать в OpenSearch (Dashboards, DQL/Query DSL, фильтры), 🕵️ посмотрим разбор реального лога. Ссылку пришлю на канал @protestinginfo за 30 минут до старта. Запись и презентация будут. Досмотрите до конца - будет бонус на курс.

Всем привет! 🔥 Запускаю практический онлайн-курс по автоматизации тестирования Kafka и RabbitMQ на Python. На текущий момент, почти все высоконагруженные системы используют message-брокеры для асинхронного выполнения задач и увеличения пропускной способности. Понимание их работы и автоматизация тестирования все чаще появляется в требованиях на вакансии в бигтех компании. Материалов на эту тематику очень мало на просторах интернета и он не всегда валиден. Если ты работаешь с backend-системами, то знаешь: тестирование брокеров сообщений отличается от тестирования например REST API. Я сделал курс для QA Automation-инженеров, которые хотят разобраться в тестировании асинхронных систем на практике, а не на абстрактных примерах. Что будет в курсе: — архитектура Kafka и RabbitMQ без лишней теории — реальные интеграционные сценарии с несколькими сервисами — синхронизация конкурентных событий — многопоточность — применение паттернов проектирования в автотестах — практика на Python + код-ревью Формат: 📆 5 недель 🎥 видео-уроки 💬 Telegram-чат группы ⌨️ Много практики Кому подойдёт: QA Automation инженерам с опытом автотестирования backend и Python. ‼️Курс не для новичков с нуля.‼️ ⚠️ Формат — небольшой поток. Всего 12 мест, чтобы я мог работать с каждым. 👉 Подробная программа и регистрация: https://aqa-engineer.com/brokers ПРОМОКОД НА СКИДКУ 10% ДЛЯ ПЕРВОГО ПОТОКА: PROBROKERS