QA_Road_channel

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

Кэш, куки и Storage браузера. Зачем они нужны и чем отличаются Браузер умеет хранить данные на стороне клиента. Но каждая технология создавалась для своей задачи и путаница между ними приводит к багам, которые сложно локализовать. 📌 Браузерный кэш Браузерный кэш создан для одной цели - ускорить загрузку и снизить нагрузку на сервер: • Браузер сохраняет ответ сервера и при повторном запросе отдаёт копию без обращения к серверу • Управляется заголовками HTTP-ответа: Cache-Control, ETag, Expires • Данные хранятся на диске клиента или в памяти вкладки (memory cache). Memory Cache быстрее дискового - данные не требуют обращения к файловой системе. Данные хранятся прямо в оперативной памяти процесса браузера, без обращения к диску. • Не доступен напрямую из JS-кода приложения Что хранится: картинки, JS-файлы, CSS, шрифты, HTML-страницы, API-ответы 📌 Куки Куки появились как единственный способ хранить состояние между запросами: • Создавались для идентификации пользователя на сервере (сессии, авторизация) • Главное отличие от всех остальных хранилищ - автоматически отправляются на сервер с каждым HTTP-запросом • Имеют атрибуты безопасности: HttpOnly (недоступны из JS), Secure (только HTTPS), SameSite (защита от CSRF) • Максимальный объём - 4 КБ • Имеют срок жизни - Expires или Max-Age Что хранится: session ID, токен авторизации, ID пользователя, языковые настройки, A/B тест-группа 📌 Local Storage Local Storage появился как замена кукам для хранения клиентских данных, которые не нужны серверу: • Создавался для хранения состояния приложения на стороне клиента • Данные не отправляются на сервер - только для нужд фронтенда • Управляется JS-кодом вручную • Данные не удаляются при закрытии браузера - живут до явного удаления • Объём до 5-10 МБ Что хранится: настройки интерфейса (тема, язык), состояние фильтров, черновики форм, флаги онбординга («не показывать снова»), закэшированные справочники ⚡️ Чем отличаются браузерный кэш, куки и Local Storage Браузерный кэш: 1) Цель: ускорение загрузки 2) Управляет: браузер автоматически 3) На сервер: не отправляется 4) Объём: сотни МБ 5) Время жизни: по TTL заголовков Куки: 1) Цель: идентификация на сервере 2) Управляет: сервер или JS 3) На сервер: да, с каждым запросом 4) Объём: 4 КБ 5) Время жизни: по Expires / Max-Age Local Storage: 1) Цель: хранение данных приложения , которые не нужны серверу 2) Управляет: JS вручную 3) На сервер: не отправляется 4) Объём: 5-10 МБ 5) Время жизни: до явного удаления 🧩 Где искать в DevTools Вкладка Application: 1) Storage -> Cookies - все куки текущего домена 2) Storage -> Local Storage - данные Local Storage 3) Storage -> Session Storage - данные Session Storage (живёт до закрытия вкладки) 4) Storage -> Cache Storage - кэш Service Worker (не путать с браузерным HTTP Cache) Вкладка Network: 1) Столбец Size - значение (disk cache) или (memory cache) означает, что реального запроса не было 2) Headers -> Response Headers - заголовки браузерного кэша (Cache-Control, Age, ETag) 🌿 Почему это важно для QA 1) Disable cache в DevTools сбрасывает только браузерный кэш - серверный и CDN кэш остаются 2) Данные в Local Storage живут между сессиями - баг может воспроизводиться только у конкретного пользователя с конкретными данными в хранилище 3) В режиме инкогнито куки и Local Storage чистые - исключает влияние накопленного состояния 4) Hard Reload (Ctrl+Shift+R) сбрасывает и disk cache и memory cache для текущей страницы 5) Баг с (memory cache) не воспроизведётся после закрытия и повторного открытия вкладки, это усложняет локализацию Поставь 🔥, если полезно #интеграции

Друзья, моему курсу «Тестируем с ИИ» уже год и я продолжаю его развивать 🚀 Сначала я его сделал, чтобы у меня тоже был свой курс) А он оказался очень актуальным и востребованным, и уже: 🎯 500+ тестировщиков прошли обучение 🎯 Сотни часов сэкономлено на рутине 🎯 Курс обновляется и пополняется новыми уроками ⚡️ Реальный пример: Анализ ТЗ на 30 страниц: 12 часов → 4 часа с AI Что получаете: ✅ Промпты для чек-листов, тест-кейсов и баг-репортов ✅ Анализ требований и тест-план с ИИ ✅ API и UI тестирование с ИИ ✅ Как писать автотесты с Cursor ✅ Как работать с БД через MCP ✅ Создание и улучшение резюме ✅ Как тестировать GraphQL с ИИ 5 часов обучения сэкономят недели жизни ⚡️ 💰 4990₽ → 2990₽ до 26 июля 👀 Содержание и покупка на Stepik: stepik.org/a/251931 🔗 Купить в Telegram: @qa_road_bot 📩 Вопросы и оплата от компании: @Smok_Belyu