¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
Валерий | AQA Engineer | Автотестирование на Python | REST, gRPC, GraphQL
Ir al canal en Telegram
Сделаю из тебя крутого AQA инженера на Python. • Преподаю лучшие тренинги по автоматизации тестирования API • Senior Python developer | AQA lead, 7 лет в IT
Mostrar más1 505
Suscriptores
+224 horas
Sin datos7 días
-430 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
junio '26
junio '26
+12
en 1 canales
mayo '26
+47
en 0 canales
Get PRO
abril '26
+15
en 0 canales
Get PRO
marzo '26
+31
en 0 canales
Get PRO
febrero '26
+31
en 1 canales
Get PRO
enero '26
+65
en 1 canales
Get PRO
diciembre '25
+45
en 1 canales
Get PRO
noviembre '25
+40
en 1 canales
Get PRO
octubre '25
+41
en 2 canales
Get PRO
septiembre '25
+31
en 0 canales
Get PRO
agosto '25
+100
en 1 canales
Get PRO
julio '25
+99
en 3 canales
Get PRO
junio '25
+85
en 1 canales
Get PRO
mayo '25
+29
en 0 canales
Get PRO
abril '25
+133
en 2 canales
Get PRO
marzo '25
+85
en 2 canales
Get PRO
febrero '25
+157
en 2 canales
Get PRO
enero '25
+97
en 2 canales
Get PRO
diciembre '24
+25
en 0 canales
Get PRO
noviembre '24
+63
en 1 canales
Get PRO
octubre '24
+64
en 1 canales
Get PRO
septiembre '24
+246
en 1 canales
Get PRO
agosto '240
en 1 canales
Get PRO
julio '240
en 0 canales
Get PRO
junio '240
en 0 canales
Get PRO
mayo '240
en 0 canales
Get PRO
abril '240
en 0 canales
Get PRO
marzo '240
en 0 canales
Get PRO
febrero '240
en 0 canales
Get PRO
enero '240
en 0 canales
Get PRO
diciembre '230
en 0 canales
Get PRO
noviembre '230
en 0 canales
Get PRO
octubre '230
en 0 canales
Get PRO
septiembre '23
+419
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 11 junio | +4 | |||
| 10 junio | +2 | |||
| 09 junio | +2 | |||
| 08 junio | +3 | |||
| 07 junio | 0 | |||
| 06 junio | 0 | |||
| 05 junio | 0 | |||
| 04 junio | +1 | |||
| 03 junio | 0 | |||
| 02 junio | 0 | |||
| 01 junio | 0 |
Publicaciones del Canal
Привет!
Уже на следующей неделе у меня стартуют.
Автоматизация тестирования брокеров сообщений
Результат: Научитесь автоматизации тестирования сложных асинхронных систем. Напишите клиенты для 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 инструмент, который генерирует всё: проект, клиенты, тесты, фикстуры.
Стань еще круче как инженер. Приходи)
| 2 | Несколько месяцев назад я спросил, какой технический тренинг вам был бы действительно интересен.
Из всех вариантов больше всего реакций и комментариев собрала тема брокеров сообщений.
Это не удивительно.
Знания Kafka, RabbitMQ встречаются всё чаще в вакансиях а у многих нет возможности даже пощупать эти технологии, не говоря уже об автоматизации, которая значительно отличается от темы REST API или UI.
Качественных материалов, которые объясняют не только “как настроить”, но и “как это работает на самом деле”, не так много. Особенно если смотреть на материалы для QA, автоматизаторов и инженеров, которым важно понимать систему целиком.
Курс уже обкатан на нескольких потоках и хорошо себя зарекомендовал.
Получился именно тот тренинг, который мне самому хотелось бы пройти несколько лет назад, когда приходилось собирать знания по кусочкам делая много проб и ошибок.
Так что уже совсем скоро стартуем, 15 июня. Приходи, будет интересно.
Это последний поток по текущей стоимости, более того я подготовил скидку 10% по промокоду DIS10
5 поток будет уже дороже.
Спасибо всем, кто когда-то проголосовал за эту тему.
Фактически именно благодаря вашему интересу этот курс появился.
Так же напомню про уже проверенный тренинг REST API Advanced, который позволит вам понимать как грамотно строить архитектуру тестового фреймворка. Это полезно всем, особенно тем кто использует нейросети, чтобы можно было валидировать результат работы ИИ.
Так что всех жду и сразу анонсирую, стоимость тренингов будет повышена. | 1 229 |
| 3 |  Материалы для тех, кто в теме.
Одна из самых больших проблем при развитии в IT - это возможность найти доступный материал не для новичков.
Помню, когда я был в автоматизации тестирования, у меня был момент, когда я понимал, что на текущем месте и в текущем коллективе я самый крутой, но от этого было не весело, от этого было грустно.
Я начал смотреть другие вакансии, какие там есть технологии, чтобы была возможность развиваться.
Я обсуждал это со своими друзьями-коллегами, и тогда мне дали контакт человека, который уже работал в нашей компании, но ушёл в другую. С их слов, он был очень крутой, и честно - не хотели делиться его контактом, потому что боялись, что он меня переманит.
Справедливости ради, в дальнейшем он предложил мне перейти к ним - это уже другая история, но я сейчас о другом.
Мне дали его контакт в линке и я ему выложил всю свою боль как на духу.
Мы быстро нашли общий язык и он меня понял)
В тот момент я получил новый виток развития. Я узнал от него о тогда ещё не такой популярной теме, как кодогенерация, про настройку пайплайнов для обновления пакетов. Тогда я уже умел писать код, но не понимал, как с этим работать. Он не сказал, что и как мне делать, но поселил во мне идеи и подходы.
Это был один из самых интересных периодов в моей карьере, я был первопроходцев в своем отделе и почти все делал с нуля, просто находил и писал людям которых даже не знал, чтобы они рассказали мне как настроить пайплайн и воткнуть туда кодген. С настальгией вспоминаю, как после работы сидел с 7 вечера до 5 утра чтобы завести пайплайн и какое было ощущение счасться когда все начало работать. Сейчас с клаудкодом или другой ИИ-шкой я бы сделал это быстрее, но какой было ощущение победы, я думаю многим оно знакомо)
Этого стимула мне хватило ещё на два года. Если смотрели мою историю, то там как раз есть раздел про кодогенерацию - только изначально я писал её сам, а потом узнал, что есть готовые инструменты, и стал использовать их.
Потом я всё равно вернулся в разработку собственных инструментов, и у меня есть проекты, например такие как pbreflect, restcodegen, e2efast.
К чему я это всё? Если честно, мне иногда кажется, что я несу некую миссию для таких же заблудших душ, каким был я после трёх лет в автоматизации тестирования, которые уже и не новички, но чувствуют, что есть куда расти, и не понимают, как и что можно улучшить в своём текущем коде или процессах.
Так что если вы сейчас читаете это и узнаёте себя - вы не одни. Я здесь как раз для того, чтобы показывать, что за горизонтом есть ещё куча всего интересного. Вопрос только в том, чтобы найти своего проводника. Или стать им для кого-то)
TG-сообщество | Обучение |Отзывы | 426 |
| 4 |  Как улучшить 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-сообщество | Обучение |Отзывы | 602 |
| 5 | Как улучшить 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-сообщество | Обучение |Отзывы | 0 |
| 6 |  Всем привет!
Вчера на меня подписалось аж 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-сообщество | Обучение |Отзывы | 590 |
| 7 | Всем привет!
Давно не виделись - я к вам с новостью.
Какой, спросите вы?
Как вы помните, около двух лет назад я перешёл в разработку.
Уровень компетенций моей новой команды на Python очень высокий.
Первые полгода я чувствовал себя на грани выгорания: много думал, писал код, чтобы наверстать этот разрыв.
За это время было сделано много всего.
- мой бэкграунд дал неплохой буст в развитии нашего фреймворка для QA-платформы.
- огромный опыт я получил при разработке Python-клиента к нашему Kafka-proxy с кодовым названием Databus почитать можно тут.
- были задачи и по разработке механизмов обеспечения безопасности, по ротации токенов, и написание клиентов к различным ресурсам.
- да и много чего ещё было сделано.
Когда я переходил в Python-платформу разработчиком, мой предыдущий руководитель сказал: «Не удивлюсь, если ты в скором времени станешь там руководителем».
«Хорошая шутка», - подумал я.
Мог ли я тогда подумать, что такое случится?
Ну и, собственно, новость:
😎 теперь я руководитель группы разработки Python-платформы.
Python занимает большую часть в нашей компании:
разработка сервисов, Data Science, ML, автотестирование.
Это большая ответственность - держать нашу Python-платформу на том же уровне качества держать весь этот огромный контекст и главное делать её лучше.
Если честно, даже мировоззрение немного меняется:
чувствуешь, как напрягаются брови при просмотре MR или ответе на какие-то вопросы, потому что ощущаешь груз ответственности.
Для меня это новый вызов и новые возможности.
Ну а для вас - это новые фичи и приёмы из мира разработки, которые можно применять в автотестировании.
——————————-
📱 TG-сообщество
📱 Обучение
📱 Отзывы | 0 |
