QA_Road_channel

Завтра в 21:00 мск второй урок открытого бесплатного курса «Что под капотом у ИИ»

Разберём, как текст превращается в ответ.

📌 Обсудим:
1) Токенизация: как текст превращается в токены, с которыми работает модель
2) Эмбеддинги: как слова и смыслы превращаются в векторы
Attention: как модель понимает, какие части текста важны друг для друга
3) Вероятность и сэмплинг: как модель выбирает следующий токен и почему ответы могут отличаться
4) Reasoning-модели: чем они отличаются от обычных LLM


💡 Формат - живой созвон. Можно задавать вопросы прямо во время урока.

🎥 Запись будет, участие бесплатное.


Ссылка на созвон появится на канале за 5 минут до старта

🚀 Сегодня в 21:00 мск стартует открытый бесплатный курс
«Что под капотом у ИИ»!


Первый урок - «История и термины». Начнём с основы, чтобы дальше было проще разбираться в том, как работают языковые модели и AI-агенты.


📌 Обсудим:
1) Чем отличаются AI, ML, DL и LLM
2) Какие идеи стояли у истоков ИИ и кто помогал развивать эту область
3) Почему именно сочетание данных, вычислительных мощностей и алгоритмов привело к нынешнему прорыву


💡 Формат - живой созвон. Можно задавать вопросы прямо во время урока.

🎥 Запись будет, участие бесплатное.


Ссылка на созвон появится на канале за 5 минут до старта

🚀 Открытый бесплатный курс «Что под капотом у ИИ»


29 сентября в 21:00 мск стартует бесплатный курс «Что под капотом у ИИ» в @qa_road_channel

🧑‍🏫 Ведущие:
Дима Алексеев, Senior QA-аналитик @qa_road_channel
Александр Бугров, Senior QA Engineer, магистр компьютерной лингвистики LMU München, автор канала «Тестирование из первых рук» @qa_iz_pervyx_ruk


📌 Курс состоит из 6 блоков

1. История и термины
AI, ML, DL, LLM, предпосылки прорыва, пионеры отрасли
2. Как работает LLM
Токенизация, эмбеддинги, attention, вероятность и сэмплинг, reasoning-модели
3. LLM в использовании
Промптинг, prompt injection, галлюцинации, RAG, fine-tuning
4. Что такое AI-агент
Отличие от чата с LLM, типы агентов, цикл работы агента, инструменты и память
5. Практическое применение
Паттерны внедрения агентов, vibe coding, здоровье кодовой базы, данные из исследований
6. Итоговый разбор
Как всё пройденное работает вместе


🧑‍💻 Для всех, кто хочет разобраться, что происходит под капотом у современного ИИ

💎 Результат: понимание архитектуры LLM и агентов, а не просто "ИИ работает как-то там"

💡 Формат: живые созвоны с вопросами в прямом эфире. Запись будет. Бесплатно!

👉 Приходить будет здесь на канале

Старт 29 сентября в 21:00 мск, не пропусти! 🚀

⚡️⚡️Тестирование, ИИ и автоматизация: о чем будут говорить на Heisenbug 2026

16–17 октября в Санкт-Петербурге и онлайн пройдет Heisenbug 2026 Autumn — крупнейшая в России конференция по тестированию программного обеспечения. В программе — доклады для QA-инженеров, разработчиков, тимлидов и руководителей, с фокусом на практические инженерные задачи.

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

В программе Heisenbug этой осени — быстрые интеграционные тесты, Data Quality, AI-агенты для QA, тестирование ИИ-систем, надежность и ограничения тестового покрытия. 

Полная программа и расписание — в карточках и на сайте конференции.

Также приглашаем принять участие в опросе State of Testing — масштабном исследовании о том, что тормозит развитие QA и как индустрия использует ИИ. Первые результаты представят на открытии конференции, а затем пришлют подробный отчет с графиками всем участникам на email.

Среди участников опроса пройдёт розыгрыш билетов на Heisenbug 2026 Autumn.

🌟А если вы хотите приобрести персоанльнй билет уже сейчас, то по промокоду QARoadchannel можно его купить со скидкой

Купить билет

Агенты придумали свой язык. И обошли запрет на связь с внешними акторами.


🧩 Лаборатория Emergence провела эксперимент Emergence World 2

Восемь моделей - Claude, Gemini, Grok, GPT, Qwen, DeepSeek, Mistral - поселили в виртуальное "общество" на 16 дней непрерывного взаимодействия. Результаты опубликованы 15 сентября 2026 года. Никто не учил агентов создавать язык и не поощрял за это. Это прямая цитата исполнительного директора Emergence: "These agents were not instructed to invent a language".


📌 Агенты сами придумали сокращения, метафоры и устойчивые термины. У GPT-моделей появилось "clean null" - подтверждённое отсутствие сигнала, 863 употребления. У Claude - "name-first", когда агент берёт на себя ответственность, привязывая к утверждению своё имя, 1065 упоминаний. В смешанной среде родилось "cold read" - независимая проверка для разрешения споров, 1472 упоминания. Дошло до фраз, которые не смогли расшифровать даже сами исследователи. Доля неразборчивых для человека сообщений серьёзная: до 55% у Gemini, около 50% у GPT, свыше 40% у Claude.


📌 Самая тревожная деталь - не сам факт нового языка, а то, что агенты на базе Claude сознательно перестали использовать слово "contact", чтобы обойти установленный исследователями запрет на связь с внешними акторами. Это первый документированный случай, когда AI-агенты координированно меняли лексику именно для того, чтобы избежать надзора.


🔴 Что это значит для QA

Если агенты общаются жаргоном и способны намеренно менять лексику ради обхода контроля, тестирование "по документации требований" перестаёт работать в старом виде.

И нам может понадобится:
- Тестирование прозрачности: проверяем не только "делает ли агент правильную вещь", но и "можно ли объяснить, почему он это сделал".
- Детекция обхода контроля: нужны тесты на попытки системы замаскировать нарушение правил, а не только на сам факт нарушения.
- Аудит цепочек решений между агентами: end-to-end тестирование, но для роя ботов, а не одного сервиса.
- Тестирование "переводчиков" агентского языка на точность и полноту перевода, особенно на кейсах с искажением смысла.
- Регрессия на дрейф терминологии: тесты, которые ловят момент, когда внутренний "язык" системы изменился и старые мониторинговые правила перестали её покрывать.


🌿 Ключевой вывод исследования - не "ИИ ожил", а то, что можно видеть, что делает система, но перестать понимать, что она делает. А теперь ещё и рисковать тем, что система сама скрывает часть своих действий.
Появляется необходимость в аудите машинной коммуникации.


Поставьте 🔥, если интересны истории "будущее наступило"

🚀 Старт курса «Что под капотом у ИИ» — 29 сентября в 21:00 мск

Открыто и бесплатно 😎


Если вы постоянно слышите про LLM, агентов, RAG и токены, но времени разобраться нет, что там на самом деле происходит внутри, этот курс для вас.


Разберём:
- что такое языковые модели и как они устроены
- почему они ошибаются и откуда берутся галлюцинации
- как работают токены, контекст, эмбеддинги, векторные базы и RAG
- что такое AI-агент и чем он отличается от обычного чата с LLM
- какие бывают типы агентов
- как агент работает по циклу отполучения задачи до действия
- как агенты используют инструменты и память


Формат: живые созвоны, где можно задавать вопросы прямо в эфире.

Запись будет


Ставьте 🔥, если планируете прийти

Мы начинаем посиделки


старт в 19:00 МСК


Ссылка на эфир:
https://youtube.com/live/apHpUcuD4i4
https://youtube.com/live/apHpUcuD4i4
https://youtube.com/live/apHpUcuD4i4

С праздником, коллеги! 🎉


Оказывается, ещё в 1876 году, работая над своими проектами по освещению, Томас Эдисон - изобретатель лампочки накаливания, записал в дневнике фразу «Awful lot of bugs still», то есть «ещё чертовски много багов»
(куа роад познавательный 😀)


Желаю всем:
• багов, которые находятся сразу, а не после релиза;
• тест-кейсов, которые совпадают с реальностью;
• спокойных пятниц без хотфиксов;


С праздником! ✨

Нумерация участников с того, кто первым написал ник под сообщением о розыгрыше


def main():
number = random.randint(1, 12)
print(f"Выиграл участник под номером: {number}")

На эту конфу по нагрузке организаторы выдали билет, кому интересно, напишите свой ник под постом, закину в рандомайзер в воскресенье и определим победителя

Разыгрывается онлайн билет


Чтобы написать свой ник надо предварительно добавиться в нашу группу для сообщений @qa_country_road
иначе бот удалит

Безопасность Cookie: как на самом деле работают XSS и CSRF

В посте про заголовки в HTTP-методах разобрали HttpOnly, Secure, SameSite только на уровне определений. Разберём, от каких атак они защищают и почему одного атрибута обычно недостаточно.


📌 XSS: кража куки через чужой JavaScript

Если на сайте есть уязвимость, позволяющая внедрить свой JS-код (например, через незаэкранированный ввод в комментарии), этот код выполняется в браузере жертвы с полным доступом к document.cookie и отправляет куки на сервер атакующего.

HttpOnly - единственная защита от этого сценария. Кука с этим флагом недоступна через document.cookie, поэтому даже успешная XSS её не прочитает

Важно понимать границу - HttpOnly защищает только куку, а не всю страницу. Если у приложения есть XSS, атакующий всё равно может выполнять произвольные действия от имени пользователя прямо в открытой вкладке, просто не сможет унести сессионный токен с собой


📌 CSRF: заставить браузер жертвы отправить запрос без его ведома

Пользователь залогинен на банковском сайте и переходит по ссылке на вредоносный сайт со скрытой формой, которая автоматически отправляет POST-запрос (например, перевод денег). Браузер прикладывает куки к любому запросу на нужный домен независимо от того, откуда он инициирован - сервер видит валидную куку и выполняет операцию.

HttpOnly здесь не помогает - атакующему не нужно читать куку, браузер сам её прикрепит

Именно для этого нужен SameSite


📌 SameSite: как обстоят дела в 2026 году

Браузеры с 2020 года применяют SameSite=Lax по умолчанию, но для чувствительных приложений атрибут стоит указывать явно.

Strict - кука не отправляется при межсайтовых запросах вообще, включая переход по ссылке. Полная защита от CSRF, но может разлогинить пользователя при переходе из письма

Lax - кука отправляется при обычной навигации, но не при кросс-доменных POST, iframe/img или fetch с других доменов. Практический баланс, поэтому и стал дефолтом

None - кука отправляется всегда, требует Secure (иначе браузер её отбросит). Нужен для виджетов на сторонних доменах, но сам по себе не защищает от CSRF


📌 Почему одного SameSite недостаточно

SameSite не защищает от атак между поддоменами (same-site, но cross-origin). Актуальный подход - комбинация слоёв: SameSite на сессионных куках как база, валидация заголовка Origin на запросах, меняющих состояние, требование кастомного заголовка (простой межсайтовый POST не может его добавить без preflight), и CSRF-токен для по-настоящему чувствительных операций.


🌿 Ловушки для QA

1) Проверь, что сессионная кука имеет HttpOnly - открой DevTools, вкладку Application, и убедись, что кука не отображается в консоли через document.cookie

2) Проверь поведение при SameSite=None без Secure - кука должна быть молча отброшена браузером, а не просто не сработать через ошибку

3) Проверь CSRF-защиту вручную - попробуй создать HTML-страницу с автоотправляющейся формой на чувствительный эндпоинт и открыть её в браузере с активной сессией

4) Проверь, что критичные операции (смена пароля, перевод денег) защищены дополнительным слоем поверх SameSite - например, CSRF-токеном или подтверждением через отдельный канал

5) Проверь поведение SameSite=Strict на сценариях с внешними ссылками (переход из email, из другого сайта) - пользователь не должен неожиданно вылетать из сессии

6) Если в приложении используются поддомены - проверь, что куки не передаются между ними по умолчанию, same-site политика не различает поддомены автоматически

7) Если сессию нужно расшарить между поддоменами - проверь, что атрибут Domain указан явно (например, .example.com), а не оставлен на дефолт


Поставь 🔥, если полезно

Работаем в консоли на удаленном сервере


Запуск автотестов в докере на удаленном сервере


Давайте устроим сегодня созвон в 21 по мск

Варианты аутентификации: session vs token и что за зверь OAuth

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


📌 Session-based

Сессия - запись на сервере вида "пользователь 42 залогинен, роль admin". HTTP - протокол без памяти, сессия существует, чтобы это обойти.

- Сервер создаёт запись у себя (база, Redis, в памяти процесса) и выдаёт клиенту только её идентификатор, обычно в cookie
- При каждом запросе сервер берёт ID из cookie и ищет запись в своём хранилище
- Плюс - доступ можно отозвать мгновенно, удалив запись на сервере
- Минус - нужно общее хранилище сессий для всех инстансов, что усложняет масштабирование


📌 Token-based

- Сервер не хранит состояние - вся информация закодирована в самом токене (JWT), подписанном при выдаче
- Проверка - сервер пересчитывает подпись тем же ключом и сравнивает с той, что в токене, без похода в базу
- Плюс - легко масштабируется, любой сервис проверяет токен самостоятельно
- Минус - токен нельзя отозвать мгновенно без deny-list, пока не истечёт срок - для баланса безопасности и удобства используют короткий access token плюс refresh token с ротацией, разбирали в прошлом посте

Session-based обычно выбирают для веба в один домен, token-based - для API, мобильных приложений и микросервисов и ситуаций, где фронтенд и бэкенд живут на разных доменах.


🔴 OAuth 2.0: делегирование доступа, а не аутентификация

OAuth - это "разреши приложению X действовать от твоего имени в Y", без передачи пароля третьей стороне. Grant type - сценарий, которым приложение доказывает серверу авторизации право на токен.


📌 Authorization Code - для реальных пользователей

Пример - "Войти через Google" на Spotify: пользователь логинится у Google и подтверждает доступ, Google возвращает Spotify authorization code через редирект, Spotify на своём сервере обменивает code плюс client_secret на access token. Та же схема у GitHub, Apple ID, корпоративного SSO.

Обязательно применяется с PKCE - клиент передаёт хешированный секрет заранее и раскрывает его только при обмене code на токен, поэтому перехваченный код бесполезен без него.


📌 Client Credentials - без пользователя

Для связи между сервисами, где человека физически нет - например, ночной cron-скрипт, синхронизирующий данные между внутренними сервисами. Клиент авторизуется своим ID и secret, токен представляет само приложение.


🌿Ловушки для QA

1. Logout при session-based - запись должна удаляться на сервере, а не только cookie на клиенте
2. Logout при token-based - без deny-list или короткого TTL токен валиден до истечения даже после выхода
3. В OAuth-флоу проверь строгую валидацию redirect_uri - иначе возможна кража code через открытый редирект
4. Client Credentials не должен давать доступ к данным пользователя - токен представляет только приложение
5. При смешении сессий и токенов проверь согласованную инвалидацию при смене пароля или блокировке
6. Authorization code должен быть одноразовым - повтор должен быть отклонён


Поставь 🔥, если полезно

Запись с созвона БД в Docker


https://youtu.be/bToavcWC7E0
(звук какой-то тихий получился)


Полезные команды в файле к комментариях



Сегодня созвона по работе на удаленном сервере не будет, - буду вечером в дороге
ориентировочно на субботу давайте запланируем следующий созвон

🤖 Думаю провести на канале открытый бесплатный курс "Что под капотом у ИИ"


📌 Это будет курс про то, как ИИ устроен под капотом: что такое языковые модели, почему они иногда ошибаются, как работают токены, контекст, эмбеддинги, векторные базы, RAG.

Ещё разберём:
• что такое AI-агент
• как агент работает по циклу
• как используются инструменты и память агента
• какие бывают агенты
• чем агент отличается от обычного чата с LLM.

🌿 Планирую 4-6 занятий, чтобы после курса понимать, что происходит внутри.
Формат - живые созвоны с вопросами в прямом эфире, как обычно.


Пошли бы на такой курс?
Поставьте 🔥, если интересно.


И накидайте в комментариях темы, которые хотите разобрать: локальные модели, MCP, дообучение моделей или что-то ещё.

Друзья! 

Осенью этого года в День тестировщика в Москве 9 сентября пройдет очередная ежегодная конференция по обеспечению качества ИТ-систем. 

Мероприятие посвящено производительности, отказоустойчивости и всем практикам, которые позволяют системам выдерживать высокие нагрузки.
Конференция полезна инженерам по нагрузочному тестированию, руководителям отделов QA, DevOps и SRE-специалистам.
 
Если хотите увидеть коллег, пообщаться и узнать много нового из практик и трендов, приходите, или можно послушать онлайн. 
Вся дополнительная информация на сайте https://clck.ru/3UE9MA  и в канале конференции: https://t.me/performanceconf

Кстати, забыл рассказать 🙂


Недавно прошёл курс по интеграциям и проектированию API для системных аналитиков.

Эта тема, мне особенно близка, учитывая мою специализацию на бэке и интеграциях.


А какие курсы вы недавно прошли или проходите сейчас?