📚 ProTestingInfo 🔷 Канал по тестированию 📚

DoQA 4.2 (Niccolum) — самый крупный релиз этого года 🔗 Главное: требования из трекера теперь живут в связке с тестами. Изменилось требование — узнали сразу, а не когда тест уже упал по устаревшему сценарию. Что ещё внутри: • Модуль управления требованиями: синхронизация с трекером, матрица покрытия, ИИ-генерация тестов по требованию; • Перезапуск автотеста прямо из результатов прогона, без возврата в CI/CD; • Метрика надёжности и история запусков для каждого теста; • Кастомизация таблиц с сохранением в пресеты; • Множественные параметры в тестах (pairwise и другие комбинации); • Расширенный Public API с постоянным токеном. Названо в честь никеля — элемента, который держит сплавы от коррозии со временем. Почему это в тему релиза — рассказали в статье. Разбор всех изменений 👉 на сайте 🌐 https://doqa.app/ 🥸 Telegram 🤩 Мы в MAX

Всем привет, завершила курс, узнала новые моменты по продвижению, остается внедрить 😅 Пока в отпуске, хотя через несколько дней снова работа. А порой хочется и успевать развивать блог, аккаунт. В приоритете семья, менторство, обучение коллег, работа. Снятие рилсов, а особенно монтаж еще в планах на делегирование, но пока еще сама учусь. Зато стала ближе к Сберу, теперь амбассадор😁

А у вас как дела обстоят с оценкой задач на проекте?😅 А требования? Делитесь рилс https://www.instagram.com/reel/DavefLgsFGv/?igsh=dTZ1b2xheGtydTRq и присоединяйтесь к аккаунту 💙 Краткий гид по методам оценки трудозатрат в QA. Сохраняйте, чтобы не гадать! 👇 1️⃣ PERT (3 точки): Формула E=(a+4m+b)/6. Сглаживает риски. 2️⃣ Декомпозиция: Дробление на этапы (кейсы, прогон, ретест) и суммирование. 3️⃣ Метод Дельфи: Анонимный опрос экспертов до консенсуса, без давления авторитетов. 4️⃣ Директивный: Срок диктует бизнес, команда подгоняет объем проверок. 5️⃣ Функц. точки: Оценка сложности сценариев с переводом баллов в часы. 6️⃣ % от разработки: Фиксированный процент от времени кодинга (напр., 30%). 7️⃣ COCOMO: Алгоритмический расчет по размеру проекта и коэффициентам. 8️⃣ По аналогии: Опора на опыт: «проверяли похожее за 2 дня». 9️⃣ Use Case Points: Прогноз по числу акторов и сложности сценариев. 🔟 Нормативный: Жесткие стандарты компании (напр., 30% бюджета на QA). 1️⃣1️⃣ ПВН: Оценка «на глаз» при полном отсутствии данных. 📚 Источник: https://www.software-testing.by/blog/sqadays15planirovanieiocenkatrudozatratnatestirovanie/ #qa #тестированиепо #тестировщик

Нормализация пользовательского ввода. Зачем это нужно, если есть валидация В прошлом посте разбирали валидацию - проверку, что данные подходят для использования. Но валидные данные не равно стандартизированные данные. Вот где начинается нормализация. 👀 Зачем нужна нормализация когда есть валидация Валидация ответит «данные валидны для использования», но не исправит их: «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) Если сервис-справочник недоступен, то поле ввода может заблокироваться или криво работать Поставь 🔥, если полезно #интеграции

gRPC vs HTTP статусы: разверни 👇 в чём разница? Пост в нельзяграме - Подписаться - https://www.instagram.com/p/DZ-T3ZijL3Y/?igsh=MTF2d3k3Znhic2sycg== Разная философия: HTTP описывает состояние сети и протокола (удалось ли доставить запрос?). gRPC описывает точный программный результат вызова метода (удалось ли выполнить бизнес-логику?). 🔍 Ключевые различия: 1. Детализация: HTTP делит ошибки на категории (400, 500). gRPC даёт точную причину (нет данных, таймаут, неверный аргумент). 2. Полезная нагрузка: gRPC статус всегда содержит текстовое сообщение и может включать детальные структуры (Protobuf). 📊 Таблица соответствия (Маппинг): ✅ Успех и Клиентские ошибки: • OK (0) → 200 OK • INVALID_ARGUMENT (3) → 400 Bad Request • NOT_FOUND (5) → 404 Not Found • ALREADY_EXISTS (6) → 409 Conflict • PERMISSION_DENIED (7) → 403 Forbidden • UNAUTHENTICATED (16) → 401 Unauthorized ️ Серверные и Сетевые ошибки: • DEADLINE_EXCEEDED (4) → 504 Gateway Timeout • RESOURCE_EXHAUSTED (8) → 429 Too Many Requests • INTERNAL (13) → 500 Internal Server Error • UNAVAILABLE (14) → 503 Service Unavailable • CANCELLED (1) → 499 Client Closed Request Зачем это знать QA? • Понимать истинную причину бага (500 в HTTP может быть чем угодно, а INTERNAL в gRPC — конкретный сбой). • Правильно писать баг-репорты (указывать grpc-status). • Настраивать точные алерты в мониторинге. Приглашаю на практический курс по gRPC😉 https://stepik.org/a/254052/pay?promo=80990bdfdfea22db ✍️ С какими статусами gRPC сталкиваешься чаще всего? Пиши в комментариях! 👇 #gRPC #HTTP #тестированиеПО #QA #карьераВIT

Получила прекрасный отзыв от Татьяны! Подготовка к собеседованию по тестам и вебинарам от 2990р💙 Применяй промокод JULY (790р) и вместе готовимся к собеседованиям! 💙 Тесты по подготовке на собеседования по тестированию ПО https://stepik.org/a/276076/ 💙 Онлайн-вебинары, связанные с теорией и разбором ситуационных вопросов https://coreapp.ai/app/player/course/673a1093e2ef10f35a7d95a5 💙 Онлайн-вебинары по тестированию API, интеграционному тестированию и SQL https://coreapp.ai/app/player/course/691f421ee93b12ef2f3aad60

Чем отличается тестирование бэкенда от тестирования API? 🤔 Пост в нельзяграме - подписаться Частый вопрос на собеседованиях QA. Многие считают, что API и backend testing - это одно и то же. На самом деле API лишь часть тестирования бэкенда. Сначала разберёмся, что вообще входит в тестирование бэкенда. 🖥️ Backend testing — это проверка всей серверной части приложения. Что сюда входит? 🗄️ Тестирование базы данных • проверка структуры и целостности данных; • операции CRUD (Create, Read, Update, Delete); • проверка транзакций и связей между данными. ⚙️ Проверка бизнес-логики • бизнес-правила; • валидация данных; • пользовательские сценарии; • интеграции между сервисами. 🔌 API-тестирование Да, это тоже часть backend testing. Проверяются запросы, ответы, статус-коды, схемы данных, корректность работы эндпоинтов. ⚡ Тестирование производительности • время отклика; • нагрузка; • масштабируемость; • устойчивость системы под высокой нагрузкой. 📨 Очереди и асинхронные процессы • Kafka, RabbitMQ и другие брокеры сообщений; • корректность обработки фоновых задач; • доставка и обработка сообщений. 🛡️ Тестирование безопасности • авторизация и аутентификация; • права доступа; • поиск уязвимостей. Главная цель backend testing — убедиться, что вся серверная часть приложения работает корректно, стабильно и соответствует требованиям. ⠀ 🔌 API testing Что обычно проверяют? • HTTP-методы (GET, POST, PUT, DELETE, PATCH); • статус-коды (200, 201, 400, 401, 404, 500); • request/response; • JSON/XML и структуру данных; • авторизацию (Bearer Token, API Keys); • соответствие Swagger/OpenAPI-документации. • типы API (REST, gRPC, GraphQL) ⠀ Цель API testing — убедиться, что API правильно обрабатывает запросы и возвращает ожидаемые ответы согласно контракту. До 30 июня действует промокод JUNE25 — скидка 25% на любой курс. 💙 Тесты по подготовке на собеседования по тестированию ПО А что вы тестируете чаще в работе: только API или весь бэкенд? Делитесь в комментариях #api #qa #тестированиепо #собеседование #qaengineer

Хочу отставить свой отзыв и поделиться впечатлениями. Также хочу отметить, что это мой второй большой курс, приобретенный у Нади. Невероятно продуманная структура, много знаний, полезностей для разных уровней подготовки, и конечно много практики. Проходя данный курс, учишься не просто понимать, как работать с инструментами отдельно Swagger, Postman, DBeaver, Redis и др, а как взаимодействовать с ними в совокупности. Во время прохождения курса, я задавала много вопросов, на которые всегда Надя меня направляла и давала развернутый ответ. Однозначно рекомендую курс, для тех кто хочет приобрести новые знания, закрепить имеющееся, получить много практики. Желаю Наде вдохновения, еще больше классных продуктов и новых учеников. Буду приобретать твои курсы точно и не раз) Приглашаю вас на курс! Старт 5-го августа! Готова вас направить! Скидки на участие: APISQL25 — скидка 25% до 25 июля 2026 APISQL20 — скидка 20% до 5 августа 2026 APISQL15 — скидка 15% до 15 августа 2026 Условия и сроки проверки заданий: Тариф 1: без проверки. Проверка заданий осуществляется только в течение ограниченного срока с начала обучения: Тариф 2: только первые 3 месяца Тариф 3: только первые 5 месяцев Тариф 4 (полный): 9 месяцев Обратная связь на протяжении всего доступа. 📖 Полная программа: https://protestinginfo.ru/practice_api_sql#program 💳 Тарифы: https://coreapp.ai/app/checkout/67631889a17350fd817c5cdb

Что-то я зачастил писать на Хабр, пора завязывать) Но пока не завязал - вышла новая статья про то, как мы во ВкусВилле разбираем упавшие автотесты с помощью AI и автоматически заводим баги в Яндекс Трекере. Внутри рассказал: - почему красный запуск сам по себе почти ничего не значит и что с падениями делать дальше; - зачем нам дефекты в ТестОпс и правило «один дефект — одна причина»; - как matcher-правила автоматически привязывают повторяющиеся падения в следующих прогонах; - как связка MCP ТестОпС + MCP Яндекс Трекера + Cursor / Claude Code разбирает запуск за нас; - как мой skill /testops-run-defects за один прогон разобрал 29 упавших результатов, создал дефекты, завёл задачи в Трекере и не оставил ни одного неразобранного падения. Главная мысль: AI не должен тупо заводить баги на всё красное. Он должен отделять продуктовые баги от проблем тестов, данных и окружения — тогда команда получает понятный список причин, а не шум. Читать на Хабре

SQL vs NoSQL: В чём разница? 👇 Присоединяйся в нельзяграм 📊 реляционные базы данных (SQL) Данные в таблицах со строками и столбцами. Связи через ключи. Особенности: ✓ Строгая схема данных ✓ SQL — мощный язык запросов ✓ Целостность и надёжность (ACID) ✓ Сложные запросы и агрегация Примеры: PostgreSQL, MySQL, Oracle, MS SQL Server 📄 нереляционные базы данных (NoSQL) Гибкая структура: документы, ключ-значение, графы, колонки. Особенности: ✓ Гибкая схема (легко менять) ✓ Горизонтальное масштабирование ✓ Высокая производительность ✓ Для больших данных Примеры: • MongoDB (документы) • Redis (ключ-значение) • Cassandra (колонки) • Neo4j (графы) ⚖️ СРАВНЕНИЕ: SQL: • Таблицы • Строгая схема • Вертикальное масштабирование • Идеально для финансов, транзакций NoSQL: • Документы, графы, key-value • Гибкая схема • Горизонтальное масштабирование • Идеально для Big Data, высоких нагрузок 💡 Главный совет: На собеседовании скажи, что выбор зависит от задачи проекта! 💙 Тесты по подготовке на собеседования по тестированию ПО https://stepik.org/a/276076/pay?promo=9fdcd29f7e88cd5a А также есть практика по SQL ✍️ С какими базами данных работал? Делись опытом в комментариях! 👇 #SQL #NoSQL #QA #тестированиеПО #карьераВIT