QA_Road_channel

🚀 Вопрос «Куда расти из мануального тестирования и как начать автотесты на 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 очень много контекста "под капотом". Той самой работы, которая скрывается за формальной постановкой задач и последующим уточнением данных. 📌 Почему конкретные данные критичны именно в этом разделе, где границы полноты проверки и как оценивать риски это знает (должен знать 🙃) тестировщик. ИИ такого контекста не знает. Поэтому, думаю, замена будет происходить на того, кто умеет управлять ИИ и проверять его работу, и как результат - экономит часы и охватывает больше задач. А тот, кто проигнорирует этот инструмент, вероятнее всего вылетит из профессии. Сейчас вопрос не про "останется ли с нами ИИ?", а про "Как использовать ИИ в работе?" 🌿 Поставьте 🔥, если хотите освещение этой темы на канале

🌿 Пост для всех, кому непросто Просто несколько мыслей. 📌 Тем, кто ищет работу Поиск работы в тестировании сейчас может занимать месяцы, но это не значит, что с тобой, что-то не так. Рынок сложнее, чем раньше, конкуренция выше. Отказ - не всегда оценка твоих навыков. Обычно это просто "не сошлось" по причинам, которые от тебя не зависят. И таких причин десятки. 📌 Тем, кому тяжело на текущей работе Выгорание, токсичный менеджмент, непонятные задачи, кривые рабочие процессы... С этим сталкиваются и джуны и мидлы и синьоры одинаково. Опыт не делает человека неуязвимым к рабочим проблемам. 📌 Тем, кто только хочет начать Да, порог входа вырос. Но это не значит, что путь закрыт. Это значит, что нужно больше упорства, терпения и системности. Если есть вопросы пишите. Разберём вместе, тут много опытных специалистов. Поставь 🔥, если откликается @qa_road_channel

🔥 Хочешь научиться тестировать ИИ системы? Приходи на Курс «Тестирование и оценка AI» Научишься: 📌 Тестировать ML/DL, LLM, RAG, AI-агентов 📌 Строить процесс оценки ИИ 📌 Работать с DeepEval, Promptfoo, Ragas, LangFuse и др. 📌 Создавать тестовые данные для тестирования 📌 Искать уязвимости в ИИ системах 40+ часов практики на реальных ИИ-системах Автор: Александр Мешков, Head of AI Evaluation, автор фреймворка для оценки ИИ систем eval-ai-library 💰 Старт нового потока: 09 сентября 2026 💡 Если оставить заявку и внести оплату до 19 августа - скидка 10% на все обучение 🔗 Оставить заявку: eval-ai.com 🔗 Узнать больше о тестировании ИИ по этой ссылке 📩 Вопросы: @al_meshkov в Telegram

🔥 Query-параметры и path-параметры в URL. В чём разница Оба способа передают данные через URL, но решают разные задачи. 📌 Path-параметр это часть адреса Указывает на конкретный ресурс, обычно ID. Без него URL не имеет смысла. GET /api/orders/125 125 это path-параметр, обязателен для работы эндпоинта. 📌 Query-параметр это уточнение к запросу Идёт после ?, пары ключ=значение через &. Обычно необязателен - для фильтрации, сортировки, пагинации. GET /api/orders?status=paid&sort=date&page=2 🔴 Ключевое отличие: тип данных Path-параметр может быть типизирован фреймворком. Query-параметр в URL - всегда строка, без исключений. ?age=25&isActive=true Для URL это "25", "true" - просто текст, типов не существует. 📌 Разница коротко 1) Расположение: path - часть пути, query - после ? 2) Обязательность: path обычно обязателен, query - опционален 3) Назначение: path указывает на ресурс, query уточняет запрос 4) Множественные значения: path не поддерживает, query поддерживает через & 📌 Сериализация массива в query URL передаёт только плоский текст, поэтому массив приходится сериализовать - превратить в строку по правилам, которые бэкенд потом разберёт обратно. Стандарта нет: ?tags=a&tags=b ?tags=a,b ?tags[]=a&tags[]=b Если фронт сериализует как tags=a,b, а бэкенд ждёт tags[]=a&tags[]=b - параметр придёт одной строкой вместо списка. Формат сериализации всегда стоит уточнять в документации API. 📌 Кириллица и спецсимволы URL поддерживает только ASCII. Кириллица, пробелы, &, ?, =, # кодируются через percent-encoding: ?city=Москва → ?city=%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0 Пробел кодируется как %20 или + в зависимости от контекста. Без кодирования сервер может обрезать данные или вернуть ошибку парсинга. 📌 Ограничение длины URL Практический лимит - около 2000 символов. Для больших объёмов данных (список из 500 ID) query-параметры не подходят - используй тело запроса или POST на эндпоинт поиска. 🌿 Ловушки для QA 1) Query-параметры видны в URL и логах. Нельзя передавать пароли, токены, персональные данные 2) Проверяй нетипичные значения: ?age=abc, ?limit=-5 3) Порядок query-параметров не важен, path - важен 4) Дублирующийся параметр ?status=paid&status=new - сервера обрабатывают по-разному 5) Некорректный percent-encoding кириллицы ломает парсинг URL 6) Несуществующий path-параметр (ID) должен вернуть 404, а не 500 или 200 Поставь 🔥, если полезно #интеграции

HTTP-заголовки в запросах Заголовки - это метаданные запроса и ответа. Они не про "что передаём", а про "как передаём" и "кто ты такой". 🔴 Группы заголовков • Содержимое - Content-Type, Content-Length • Авторизация - Authorization • Состояние клиента - Cookie (запрос), Set-Cookie (ответ) • Кэширование - Cache-Control, ETag • О клиенте - User-Agent, Accept • Кастомные - X-Request-ID, X-Client-Version 📌 Content-Type и Content-Length • Content-Type - говорит серверу, в каком формате тело запроса (application/json, multipart/form-data, x-www-form-urlencoded). Без него бэкенд может не понять, как парсить тело, и вернуть 415 или упасть с ошибкой парсинга • Content-Length - размер тела в байтах. Если он не совпадает с реальным размером, сервер может обрезать тело или зависнуть в ожидании оставшихся данных 📌 Authorization Передаёт токен доступа - чаще всего в формате Bearer <token> для JWT или OAuth В отличие от Cookie, браузер не отправляет Authorization автоматически - его нужно явно добавлять в каждый запрос на клиенте 📌 Cache-Control и ETag • Cache-Control - управляет, можно ли кэшировать ответ и как долго (no-cache, no-store, max-age) • ETag - "отпечаток" версии ресурса, который сервер отдаёт вместе с ответом Работают в паре - клиент присылает If-None-Match с ETag, сервер сравнивает и либо отдаёт 304 Not Modified, либо новый ресурс 📌 User-Agent и Accept • User-Agent - сообщает серверу тип клиента (браузер, версия, ОС) - используется для аналитики и иногда для адаптации ответа • Accept - говорит, какой формат ответа клиент ожидает (application/json, text/html) - сервер должен на это ориентироваться, но не всегда делает 📌 Кастомные заголовки • X-Request-ID - уникальный идентификатор запроса для трассировки через логи разных сервисов - критичен при дебаге распределённых систем • X-Client-Version - версия клиента, по которой бэкенд может включать/выключать фичи или логику обратной совместимости 📌 Cookie vs Set-Cookie: разные направления • Cookie - заголовок запроса, клиент отправляет его на сервер ("вот мои куки") • Set-Cookie - заголовок ответа, сервер отправляет его клиенту ("сохрани у себя эти куки") Атрибуты Cookie: SameSite, HttpOnly, Secure • HttpOnly - запрещает доступ к куке из JS (document.cookie). Защищает от XSS-атак, но не от CSRF • Secure - кука передаётся только по HTTPS. Без этого флага сессионный токен может утечь при случайном обращении по HTTP • SameSite - контролирует, отправляется ли кука при межсайтовых запросах. Значения: Strict (кука не отправляется ни при каких межсайтовых запросах), Lax (отправляется при обычном переходе по ссылке между сайтами, но не при встроенных кросс-доменных запросах через fetch/XHR/iframe), None (отправляется всегда, но требует Secure) 🌿 Ловушки для QA 1) Отсутствие Content-Type - сервер может не понять, как парсить тело 2) Просроченный Authorization - проверяй, что сервер отдаёт 401, а не молча пропускает 3) Дубли заголовков - некоторые прокси и балансировщики дублируют заголовки, проверяй, как бэкенд это обрабатывает 4) Проверяй, что ETag/Cache-Control одинаково настроены на dev и prod", если они настроены по-разному на dev и prod, баги кэширования будет сложно воспроизвести 5) SameSite=None без Secure - кука будет молча отброшена браузером, баг проявится только в проде с HTTPS 6) Если тестируешь авторизацию через сторонний домен (SSO, редиректы, встроенные виджеты) и куки "пропадают" - проверь SameSite первым делом 7) Проверь, что X-Request-ID действительно уникален и передаётся через все сервисы в цепочке - иначе трассировка бесполезна Поставь 🔥, если полезно #интеграции

🔥 Идентификация, аутентификация, авторизация. В чём разница Эти три термина часто путают, хотя они решают разные задачи и идут строго друг за другом. 👀 Простая аналогия - вход в офис Идентификация - ты называешь своё имя на входе: «Я Котов Мурмур» Аутентификация - охранник проверяет пропуск и сверяет фото: «Действительно ли ты Котов Мурмур?» Авторизация - пропуск открывает дверь только на 3 этаж: «Тебе разрешено только на 3 этаж» 📌 Идентификация - «кто ты?» Заявление пользователя о том, кто он: логин, email, номер телефона, device ID, cookie, номер карты, ИНН, номер заказа - любое заявление «кто/что» перед проверкой. 🔴 Идентификация сама по себе ничего не доказывает. Любой может ввести любой email. 📌 Аутентификация - «докажи, что ты это ты» Проверка, что заявленная личность соответствует действительности: пароль, OTP-код, биометрия, токен-устройство, сертификат. Успешная аутентификация подтверждает факт владения средством проверки - из этого система делает вывод о личности пользователя. Результат - выданный токен (JWT, session ID), чтобы не спрашивать пароль на каждый запрос. Многофакторная аутентификация (MFA/2FA) Аутентификация может требовать не один фактор, а несколько из разных категорий: - Фактор знания - пароль - Фактор владения - телефон с кодом, физический ключ - Фактор принадлежности - биометрия 2FA - это два фактора из разных категорий. Пароль + секретный вопрос - это не настоящая 2FA, это два фактора знания, что слабее. 📌 Авторизация - «что тебе разрешено» Происходит после аутентификации, определяет права: - юзер видит свои заказы - админ - все • модератор редактирует комментарии, но не цены. Авторизация часто работает на нескольких уровнях: • Эндпоинт - доступ к /admin или нет • Запись - свои заказы, но не чужие • Поле - заказ виден, но себестоимость товара скрыта Авторизация отвечает не «кто ты», а «что тебе можно делать». 🧩 Наглядная последовательность Ввод email → Идентификация | Проверка пароля → Аутентификация | Выдан токен доступа | Запрос "удалить товар" → Авторизация: есть ли право? | Да → выполнено Нет → 403 Forbidden 🔴 Частая путаница в статус-кодах - 401 Unauthorized - на самом деле это ошибка аутентификации: пользователь не вошёл в систему или токен невалиден - 403 Forbidden - это ошибка авторизации: пользователь аутентифицирован, но у него нет прав на это действие Название 401 Unauthorized вводит в заблуждение - по смыслу оно про authentication, а не authorization. Вот такая вот исторически сложившаяся неточность в спецификации HTTP. 🔴 Логаут - это не просто "забыть токен" logout должен инвалидировать токен на бэкенде (blacklist / удаление сессии), а не просто удалить его из localStorage на фронте. Иначе украденный токен продолжит работать даже после «выхода» пользователя. 🌿 Ловушки для QA 1) Проверять нужно оба статуса раздельно: 401 для неаутентифицированного пользователя, 403 для аутентифицированного, но без прав 2) Токен может быть валиден по формату, но просрочен - это тоже 401 3) После смены роли пользователя (например, из юзера в админа) старый токен должен либо обновить права, либо система должна заставить перелогиниться - иначе получится рассинхрон между токеном и реальными правами 4) Один и тот же эндпоинт может по-разному отдавать данные разным ролям - нужно тестировать не только «доступно/недоступно», но и объём возвращаемых данных 5) IDOR-уязвимость: пользователь аутентифицирован, но может подставить чужой ID в запрос и получить доступ к данным другого пользователя - это провал авторизации, критичный баг безопасности 6) После logout проверь что старый токен действительно не работает, а не просто удалён на фронте Поставь 🔥, если полезно #интеграции

@ProTestingInfo - Канал Надежды Дудник, автора на Хабре, ментор QA и эксперта в тестировании ПО. Здесь одинаково комфортно и тем, кто только гуглит «STLC», и крепким QA-спецам. Что внутри для твоей карьеры: • 📂 База шаблонов: забирай в файлах готовые чек-листы, тест-кейсы, тест-планы и отчеты. • 🧠 Интерактив: квизы на знание теории, которые заменяют скучное чтение большого потока информации. • 🛠 Hard Skills: разборы инструментов (Kibana, Insomnia, Postman, mTLS, Redis, Kafka) и ссылки на экспертные статьи автора. • 📹 Обучение: записи вебинаров с разбором технических вопросов с собеседований. Автор канала топит за практику. Те, кто не просто читает, а применяет эти знания, быстрее получают офферы и продвигаются по грейдам. 💯 Подпишись на @ProTestingInfo, чтобы держать знания в тонусе и забрать вебинар по техническим вопросам в закрепе!

Linux для тестировщика с нуля | Урок 6 🌿 Как не страдать в терминале Linux Запись с созвона https://youtu.be/_Yc2ur3FCfQ?si=xlDArm440ftiKJfN Список полезных команд от Максима Трофимова в комментариях

Linux для тестировщика с нуля | Урок 6 🌿 Как не страдать в терминале Linux Завтра, во вторник в 21 по мск В уроке будет: 1) как найти где лежит файл 2) как настроить автоочистку логов по времени, по размеру 3) как протестировать сетевое подключение (несколько стандартных утилит ping, traceroute, nslookup, mtr, nmap) 4) полезные скрипты на баш Ссылка за созвон появится за 5 минут до старта Запись будет

JSON и как данные передаются в JSON Фронтенд собирает данные и отправляет на бэкенд. JSON - самый популярный формат, но не единственный, еще используются: • form-data • x-www-form-urlencoded • XML • GraphQL • query-параметры в URL • protobuf/gRPC для внутренних сервисов. 👀 Сериализация и десериализация JSON физически - это строка символов, а не "живой" объект в памяти программы. Когда фронтенд отправляет запрос, он превращает JavaScript-объект в текст. Этот процесс называется сериализация. JS-объект → сериализация → JSON-текст → десериализация → Object/контракт API Десериализация: превращение текста обратно в структуру Сервер получает просто текст в теле HTTP-запроса. Чтобы с этим текстом можно было работать как с обычными переменными, бэкенд превращает строку обратно в структуру своего языка - этот процесс называется десериализация. Это обратная операция по отношению к сериализации. Если тип поля не совпадает или обязательное поле отсутствует - десериализация падает ещё до бизнес-логики. 📌 Типы данных в JSON Всего шесть типов: • Строка - текст в двойных кавычках: "Иван", "ivan@mail.ru" • Число - без кавычек: 25, 199.99, -10 • Логическое значение - только true или false, без кавычек • null - отсутствие значения • Объект - набор пар ключ: значение в фигурных скобках • Массив - список значений в квадратных скобках, включая другие массивы (массив массивов) { "name": "Иван", "age": 25, "isActive": true, "middleName": null, "roles": ["user", "editor"], "matrix": [ [1, 2, 3], [4, 5, 6] ], "address": { "city": "Москва", "street": "Ленина" } } Дата отдельного типа не имеет - передаётся строкой, обычно в формате ISO 8601: "2026-07-20T10:17:00Z". (есть и другие стандарты) 🔴 Проблема для QA: раз это просто строка, ничто не мешает бэкенду или фронтенду передать дату в другом формате - 20.07.2026, 07/20/2026, unix-timestamp 1784716620. Разные команды могут договориться о разных форматах, и это частый источник багов при интеграции. 📌 Частые ловушки - Кавычки меняют тип: "age": 25 (число) и "age": "25" (строка) - разные вещи для API - null, "" и отсутствие поля - три разных состояния, особенно критично в PATCH запросах - Невалидный синтаксис: одинарные кавычки, ключи без кавычек, запятая в последней строке, комментарии - всё это ломает JSON 🧩 Как проверить синтаксис JSON • Онлайн-валидаторы - jsonlint.com, jsonformatter.org: показывают точную строку и символ ошибки • JSON.parse() в консоли браузера • Postman - невалидный синтаксис подсвечивается красным до отправки запроса • Линтеры в IDE - VS Code, PyCharm, IDEA и другие редакторы 🌿 Что проверять QA 1) Content-Type соответствует реальному формату тела запроса 2) Тело запроса является валидным JSON: двойные кавычки, нет лишних запятых и комментариев 3) Типы значений совпадают с контрактом API 4) Формат даты соответствует документации API, а не произвольный формат 5) Обязательные поля отправляются, иначе десериализация падает до бизнес-логики 6) Поля с null, пустыми строками и отсутствующие поля обрабатываются по-разному 7) Массивы и массивы массивов сохраняют порядок и вложенность 8) Ошибки десериализации подсказывают что проблема в типах, а не в бизнес-логике 9) Фронтенд показывает понятную ошибку, если сервер отклонил данные Поставь 🔥, если полезно #интеграции

Troubleshooting Linux: как диагностировать и чинить проблемы на сервере | Урок 5 Показывает админ/девопс Максим Трофимов Запись с созвона https://youtu.be/ItD3JxpASP8

Troubleshooting Linux систем | Урок 5 Сегодня в 21 по мск К нам придёт devops/админ Максим Трофимов и покажет, как быстро находить причину проблемы на сервере. С чего начинать диагностику, какие утилиты смотреть в первую очередь. Ссылка за созвон появится за 5 минут до старта Запись будет

Linux для тестировщика с нуля | Практика с докером Запись https://youtu.be/jtvHSBNwgXs

Linux для тестировщика с нуля | Урок 4 Запись https://youtu.be/T3isRw7z0nY

Нормализация пользовательского ввода. Зачем это нужно, если есть валидация В прошлом посте разбирали валидацию - проверку, что данные подходят для использования. Но валидные данные не равно стандартизированные данные. Вот где начинается нормализация. 👀 Зачем нужна нормализация когда есть валидация Валидация ответит «данные валидны для использования», но не исправит их: «89161234567» и «+7(916)123-45-67» оба телефона верные, и в базе создадут два разных аккаунта, но поиск по одному не найдёт второй «Москва, ул. Ленина» и «г. Москва, улица Ленина» - один адрес, два разных написания Нормализация решает эту проблему - приводит данные к единому виду до сохранения. 📌 Валидация обрамляет нормализацию с двух сторон Данные которые передаём на нормализацию тоже должны соответствовать минимальным требованиям - быть валидны для обработки. Поэтому валидация происходит дважды: Ввод пользователя | Базовая валидация: проверка, что данные пригодны для нормализации? (не пусто, минимальная длина, тип данных) | Нормализация: привести к стандарту | Финальная валидация: данные пригодны для сохранения? (формат, бизнес-правила, уникальность) | Сохранение в базу 🎯 До нормализации проверяем, что данные вообще пригодны для обработки 🎯 После нормализации проверяем, что результат соответствует требованиям системы Можно ли сразу писать правила валидации под нормализованный формат? Да, но только для простых полей. Например для email: вместо «просто проверь что есть @ и точка» пишешь правило «только lowercase, без пробелов». Тогда нормализация делает своё дело до валидации, и валидация проверяет уже «чистые» данные. Но не всегда это возможно: Телефон - пользователь может ввести «89161234567» или «+79161234567» или «8(916)123-45-67». Запретить все форматы кроме одного - плохой UX. Правильно: принять любой -> нормализовать -> валидировать итог Адрес - невозможно написать правило которое покрывает все адреса страны. Поэтому и существуют внешние справочники вроде Дадата - они нормализуют данные. ФИО - «Иван Иванов Иванович» и «Иванов Иван Иванович» оба правильные и нормализация нужна 🔴 Главный принцип: не наказывай пользователя за формат, если его можно исправить автоматически. 📌 Где происходит нормализация На фронте (до отправки на сервер): • Дает быструю обратную связь пользователю • Снижает нагрузку на бэкенд • Форматирование отображения в реальном времени На бэкенде: • Финальная нормализация перед записью в базу, так как бэкенд не доверяет данным с фронта 📌 Примеры нормализации на фронте Простая без внешних сервисов: • Обрезка пробелов: « Иван » -> «Иван» • Регистр email: «IVAN@MAIL.RU» -> «ivan@mail.ru» • Форматирование телефона: «89161234567» -> «+7 (916) 123-45-67» • Удаление лишних символов из номера карты Сложная (через внешние сервисы-справочники): • Адреса - через Дадата / ФИАС • ФИО - разбивка на имя, фамилию, отчество • ИНН, ОГРН, реквизиты банков 🧩 Внешние сервисы - это справочники Дадата, ФИАС, ГАР - это по сути справочники с API: • Содержат эталонные данные (все адреса РФ, все ИНН, все банки) • Фронт отправляет введённый текст -> справочник возвращает нормализованный объект • Выбор из подсказок сам по себе является валидацией - пользователь не может ввести несуществующий адрес 🌿 Ловушки для QA 1) Бэкенд принимает только структурированный объект с ФИАС-кодом, если пользователь ввёл адрес вручную без выбора подсказки и нажал Submit, бэкенд вернёт ошибку 2) Нормализация на фронте и на бэкенде может различаться 3) Данные могут быть валидны, но не нормализованы - такие баги проявляются не сразу, а при поиске, сравнении и дедупликации 4) ФИАС-коды домов периодически меняются - ранее сохранённый адрес может стать невалидным 5) Debounce 300-400ms на запросы к Дадата - проверь поведение при быстром вводе и медленной сети 6) Если сервис-справочник недоступен, то поле ввода может заблокироваться или криво работать Поставь 🔥, если полезно #интеграции

Объявление!!! Созвон переносится! Сегодня созвона по Linux для тестировщика с нуля | Урок 4 не будет, не успеваю добраться до дома, буду в дороге Давайте перенесем на этот четверг на 2 июля так же на 21 по мск

Валидация пользовательского ввода на фронте. Валидация на фронте - это первый рубеж проверки данных, которые вводит пользователь. Но важно понимать: фронтовая валидация создана для UX, а не для безопасности. Любую клиентскую проверку можно обойти через DevTools или отправив запрос напрямую через Postman. Зачем нужна валидация на фронте - Не гонять невалидные данные на сервер - экономия трафика и времени - Моментальная обратная связь пользователю без ожидания ответа сервера - Снижение нагрузки на бэкенд - очевидные ошибки отсекаются до отправки запроса на сервер 👀 Подходы к валидации и особенности 📌 Встроенная HTML валидация: - Атрибуты required, type, pattern, minlength, maxlength, min, max - Браузер сам показывает ошибку без JS - Атрибуты легко убираются через DevTools - и валидация обходится за секунды - Подходит только для простых проверок: обязательность поля, формат, длина, диапазон 📌 Для сложных проверок используется JS-валидация: - Кросс-полевая: дата выезда должна быть позже даты заезда - Условная: поле обязательно только при определённом выборе - Зависимая: выбранный город должен соответствовать стране - Асинхронная: проверка уникальности email через запрос на сервер (AJAX - асинхронный запрос к серверу без перезагрузки страницы) - Бизнес-правила: сумма перевода не превышает баланс счёта 💡 Когда валидация срабатывает - onBlur - при уходе с поля (оптимально для большинства случаев) - onChange - при каждом изменении поля (агрессивно, раздражает пользователя) - onSubmit - при отправке формы (мягко, но поздно показывает ошибки) - Комбинированный: onBlur для первой проверки, onChange после первой ошибки 🧩 Ловушки для QA Валидация не срабатывает при: 1) Автозаполнении браузером - поле заполнено, но событие onBlur не вызвано 2) Автозаполнении менеджером паролей (1Password, LastPass) 3) Вставке через правую кнопку мыши - oninput может не сработать 4) Drag & Drop текста в поле 5) При автоматизации при заполнении через Selenium или Cypress 6) Заполнении мобильным автокорректором Другие ловушки: 7) Фронт и бэк валидируют по-разному - фронт разрешает пробелы в имени, бэк нет 8) При onBlur-валидации ошибка не показывается, если поле не было в фокусе - пользователь сразу нажал Submit 9) Асинхронная валидация создаёт лишние запросы - нужно проверить поведение при быстром вводе 🌿 Главный принцип Валидация на фронте это для UX. Валидация на бэке обязательна всегда. Даже если фронт всё проверил, на бэке надо повторить проверку, потому что запрос может прийти в обход интерфейса. Поставь 🔥, если полезно #интеграции

Тестировщики, общий сбор! Что успеете сделать за 100 минут работы? Делимся идеей: можно запустить параллельные тесты приложения на разных устройствах, проверить производительность, нажатия и UI. И все это — бесплатно в Мобильной ферме от Selectel, потому что при регистрации вы получаете 100 бонусных минут в сервисе. Что дает Мобильная ферма Selectel: ● Парк из 50+ моделей от популярных до редких смартфонов на Android и iOS. ● Удобство — настройки сохраняются, пока устройство закреплено за вами вне зависимости от количества тестов и длины сессии. ● Безопасность — информация о ваших сессиях автоматически удаляется после завершения аренды. Регистрируйтесь и получите промокод на 100 минут при первом заказе: https://slc.tl/2xfqa Реклама. АО "Селектел". erid:2W5zFHoXy7w