QA_Road_channel

Мы начинаем посиделки старт в 19:00 МСК Ссылка на эфир: https://youtube.com/live/apHpUcuD4i4 https://youtube.com/live/apHpUcuD4i4 https://youtube.com/live/apHpUcuD4i4

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

У тестировщиков редко бывает одинаковая работа. 😺 Один меняет IT на стройку и заново собирает своё представление о QA. Другой тестирует NGFW и совмещает Agile, Waterfall и R&D, потому что цена ошибки слишком высока. Кто-то работает на стыке аналитики и тестирования, пока вокруг AI-хайп. А кто-то превращает страшную метрику забагованности в нормальный инструмент для команды. 🤔 Поэтому 9 сентября, в День тестировщика, я решил собрать четырёх действующих специалистов в одном эфире, где каждый расскажет о том, с чем работает прямо сейчас. Начнём с круглого стола: «Что сегодня делает тестировщика ценным?»

Доменная экспертиза, инженерная база или влияние на процессы?

А затем перейдём к четырём реальным историям. • Света @bettercalllory — «Как панда из IT в стройку ушла»

Что происходит, когда полностью меняешь домен, что приходится чинить первым — процессы или мышление — и к чему это приводит за полгода.

• Вячеслав @Tsevinskiy — «Agile против Waterfall: как мы собрали гибрид для NGFW»

«Agile — да, Waterfall — обязательно». Звучит как оксюморон? Добро пожаловать в реальный мир энтерпрайза и HighLoad.

• Дима Алексеев @qa_road_channel — «Будни аналитика-тестировщика: классическая инженерия после AI-хайпа»

Почему классические инженерные подходы никуда не делись и бизнес уже не так оголтело кричит: «Возьми мои деньги и сделай AI-ассистента».

• Дима Беляков @DmBelyakov — «Забагованность: как ZBP стала союзником качества»

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

И да, будут подарки от докладчиков и моих друзей из ТестОпс 🥳

После каждого выступления спикер выберет лучший вопрос, а его автор сразу получит подарок 👍

Приносите свои кейсы и спрашивайте то, что действительно хотелось обсудить с практиками. 9 сентября, 19:00 МСК Ссылка на эфир: https://youtube.com/live/apHpUcuD4i4 https://youtube.com/live/apHpUcuD4i4 https://youtube.com/live/apHpUcuD4i4 Участие бесплатное. Отправьте этот пост знакомым тестировщикам — 9 сентября собираемся своей QA-тусовкой. 🎉 Ставьте 🔥, если будете!

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

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

Безопасность 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), а не оставлен на дефолт Поставь 🔥, если полезно

Ссылка на созвон https://meet.jit.si/DesirablePoolsDevelopTwice https://meet.jit.si/DesirablePoolsDevelopTwice https://meet.jit.si/DesirablePoolsDevelopTwice

Работаем в консоли на удаленном сервере Запуск автотестов в докере на удаленном сервере Давайте устроим сегодня созвон в 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 для системных аналитиков. Эта тема, мне особенно близка, учитывая мою специализацию на бэке и интеграциях. А какие курсы вы недавно прошли или проходите сейчас?

Продублирую Ссылка на созвон https://meet.jit.si/IntensePrisonsCruiseIndeed https://meet.jit.si/IntensePrisonsCruiseIndeed https://meet.jit.si/IntensePrisonsCruiseIndeed

Работаем в консоли на удаленном сервере БД в Docker Давайте устроим сегодня созвон в 21 по мск Ссылка на созвон появится тут за 5 минут до старта надо оживать)

Как работают access и refresh токены 🔔 После логина сервер должен узнавать пользователя при каждом запросе, не спрашивая пароль заново. Токен - временное удостоверение вместо пароля. Проблема в том, что его можно украсть, и чем дольше он живёт, тем опаснее кража. Разберём по шагам весь путь токенов, и почему их два, а не один 📌 Шаг 1: логин Сервер проверяет логин и пароль и выдаёт сразу два токена - короткоживущий access token (15-60 минут) и долгоживущий refresh token (от нескольких дней до недель). Где хранятся токены Access token хранят в памяти приложения или localStorage, прикладывают к каждому запросу в заголовке Authorization. Refresh token хранят осторожнее - лучший вариант HttpOnly cookie, недоступная из JavaScript, что защищает от XSS. На сервере access token не хранится вообще - подпись проверяется на лету, в этом и смысл JWT. Refresh token сервер хранит в базе или Redis, поэтому его можно отозвать вручную в любой момент. 📌 Шаг 2: access token истёк Когда access token истекает и клиент получает 401, приложение обращается к эндпоинту вроде /refresh, прикладывая refresh token. Сервер проверяет его в базе и в ответ присылает не один токен, а пару - новый access token и новый refresh token. Такой подход называется Refresh token rotation. Старый refresh token в этот момент сразу помечается как использованный и становится недействительным. Если refresh token невалиден пользователю придётся залогиниться заново 📌 Шаг 3: зачем менять ещё и refresh token, если он всё равно долгоживущий Если бы сервер в шаге 2 присылал только новый access token, а refresh token оставался прежним всё две недели, то кража этого единственного refresh token дала бы атакующему доступ на весь оставшийся срок незаметно, потому что и легитимный пользователь, и атакующий обращались бы к /refresh с одним и тем же валидным токеном, и сервер не смог бы отличить их друг от друга. Ротация превращает refresh token в одноразовый - его можно использовать для обмена ровно один раз. После этого он сгорает, а клиент обязан использовать токен, который пришёл в паре с последним ответом. Если старый (уже сожжённый) refresh token попытались применить снова это означает, что кто-то помимо легитимного клиента получил доступ к предыдущей версии токена. Сервер трактует это как компрометацию и отзывает всю цепочку, требуя от обоих полного повторного логина. 📌 Шаг 4: logout Сервер удаляет refresh token из хранилища. Даже если у кого-то остался старый access token, обновить его после истечения уже не выйдет. 🌿 Ловушки для QA 1) Проверь, что просроченный access token отдаёт ошибку доступа, а не проходит проверку 2) Проверь, что refresh token нельзя использовать вместо access token и наоборот в защищённых эндпоинтах 3) При ротации попробуй использовать один и тот же refresh token дважды подряд - второй запрос должен провалиться 4) Проверь хранение refresh token на клиенте - localStorage уязвим к XSS, HttpOnly cookie безопаснее 5) Проверь logout - должен инвалидировать refresh token на сервере, а не только на клиенте 6) Проверь абсолютный лимит жизни сессии, даже при ротации должен быть жёсткий потолок 7) При обнаружении повторного использования уже сгоревшего refresh token проверь, что отзывается вся цепочка токенов Поставь 🔥, если полезно

🚀 Вопрос «Куда расти из мануального тестирования и как начать автотесты на Java?» всё ещё актуален. Поэтому хочу лично от себя порекомендовать новый курс Java QA Automation 2026 от Олега Пендрака автора канала @thread_qa_blog, который проводил у нас мастер-классы и предоставил свою песочницу для нашего бесплатного курса по авто на питоне для UI автотестов. 📌 Курс работает с полным набором технологий, которые реально спрашивают на собеседованиях: REST, SOAP, GraphQL, gRPC, Kafka, PostgreSQL, WireMock, Docker, CI/CD. разбирается серьезный набор технологий. В нем вы будете автоматизировать то, с чем реально работают сильные инженерные команды: тестовым проектом служит не игрушечный Petstore, а полноценный backend ShawarmaShop с четырьмя API-протоколами, вебхуками и Kafka. 📌 Личный код-ревью: автор лично разбирает каждый ваш PR на GitHub, указывает на архитектурные ошибки и учит писать чистый Clean Code. 📌 Блок по работе с AI в QA: отдельно разбирается работа с AI-агентами, MCP-серверами и ChatGPT Codex, как генерировать автотесты из требований и ускорять разработку в 2-3 раза без потери качества. 🎯 Если вы давно планировали перейти из Manual в Automation или подтянуть архитектуру своих фреймворков до серьезного уровня это отличный вариант. 📌 Подробная программа курса по ссылке 🔥 Промокод QA-ROAD дает скидку 5% Вопросы по курсу можете задать Олегу в ЛС @penolegrus

JWT: что внутри токена 🧐 (Очень важная тема) JWT обычный текст в кодировке Base64URL, это не шифрование. Любой может декодировать токен и прочитать, что внутри - защищена только подпись, а не содержимое. Токен состоит из трёх частей через точку: header.payload.signature. 👀 Где используется и почему HTTP - протокол без памяти: каждый запрос сервер видит "с нуля". JWT решает это без хранения состояния сессии на сервере, вся нужная информация уже внутри токена, подписана и самодостаточна. - REST API и мобильные приложения - сервер проверяет подпись локально, без похода в базу - Микросервисы - любой сервис в цепочке проверяет токен независимо, без обращения к центральному хранилищу сессий - SSO - токен, выданный одним сервисом, принимают другие сервисы и домены без повторного логина - SPA - если хранить JWT в localStorage, а не в cookie, токен не привязан к домену (удобно при разделении фронтенда и бэкенда на разных доменах) Обратная сторона stateless-подхода - мгновенный logout невозможен без дополнительного состояния (deny-list, подробнее в ловушках ниже). Поэтому в сценариях с высокими требованиями к мгновенному отзыву доступа (банкинг, критичные админ-панели) часто выбирают классические серверные сессии. 📌 Header Тип токена и алгоритм подписи (`alg`, например HS256 или RS256), плюс kid - идентификатор ключа, если сервер использует несколько ключей одновременно. 📌 Payload Claims - данные о токене и пользователе. Основные: sub (кто владелец), exp (когда истекает), iat (когда выдан), nbf (с какого момента действителен). Плюс любые кастомные поля (`role`, `email`). Payload не зашифрован - никогда не клади туда пароли или чувствительные данные. 📌 Signature Подпись header и payload, которая ломается при любом изменении содержимого. 1. HS256 - один секретный ключ (симметричный), проверить токен может только тот, у кого есть этот секрет - удобнее для одного сервиса 2. RS256 - пара приватный/публичный ключ (асимметричный), проверить токен может любой, у кого есть публичный ключ - удобнее для нескольких сервисов 🔴 Ловушка: alg none Спецификация разрешает токен без подписи (`alg: none`). Если сервер слепо доверяет алгоритму из заголовка самого токена - атакующий меняет payload (например, `role: admin`), убирает подпись, и токен проходит проверку. Защита - сервер должен сам решать, какой алгоритм ожидать, а не брать его из токена. 🌿 Ловушки для QA 1) Проверь, что сервер отклоняет alg: none 2) Отправь токен с изменённым payload без пересчёта подписи - должен упасть на верификации 3) Проверь просроченный токен (`exp` в прошлом) - по спецификации должен быть 401, но многие фреймворки (например, некоторые JWT-middleware для Django/aiohttp) по умолчанию отдают 403. Зафиксируй, какое поведение реализовано у тебя, и проверь, что оно консистентно на всех эндпоинтах 4) Проверь logout - JWT сам по себе не инвалидируется, нужен deny-list или короткий срок жизни 5) Длинный JWT в Authorization может привести к 431 Request Header Fields Too Large access token + refresh token для обновления - отдельная тема, разберём в следующем посте. Поставь 🔥, если полезно

🎯 ИИ заменит тех, кто не умеет с ним работать Под прошлым постом было много опасений про ИИ и наше QA будущее. Думаю страх обоснован наполовину. 🧐 Сейчас я работаю как системный аналитик по внедрению ИИ в бизнес-процессы и тестировщик. Из моего опыта могу сказать, что в QA очень много контекста "под капотом". Той самой работы, которая скрывается за формальной постановкой задач и последующим уточнением данных. 📌 Почему конкретные данные критичны именно в этом разделе, где границы полноты проверки и как оценивать риски это знает (должен знать 🙃) тестировщик. ИИ такого контекста не знает. Поэтому, думаю, замена будет происходить на того, кто умеет управлять ИИ и проверять его работу, и как результат - экономит часы и охватывает больше задач. А тот, кто проигнорирует этот инструмент, вероятнее всего вылетит из профессии. Сейчас вопрос не про "останется ли с нами ИИ?", а про "Как использовать ИИ в работе?" 🌿 Поставьте 🔥, если хотите освещение этой темы на канале