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

Manual QA меняется. Что учить прямо сейчас? 👇для начинающих 🫶🏼💙
Как обычно от Manual QA ждут не только умения находить баги, но и понимания того, как работает система целиком.
Важно постепенно расширять технический стек.
1️⃣ API и сети
• HTTP и REST: методы, статус-коды, заголовки, параметры.
• Postman: коллекции, переменные, авторизация, тесты.
• DevTools: Network и Console.
• Понимание взаимодействия фронтенда, бэкенда и внешних сервисов.
👉 Практика: возьмите учебный API и соберите коллекцию в Postman с позитивными, негативными и граничными сценариями.
2️⃣ SQL и данные
Минимальный набор:
• SELECT, WHERE, ORDER BY;
• JOIN;
• GROUP BY и агрегатные функции;
• подзапросы и CTE.
👉 Не учите SQL только по теории. Проверяйте данные после реального сценария: регистрация, заказ, платеж или добавление товара в корзину.
3️⃣ Мост к разработке
Полезно освоить:
• основы Python или JavaScript;
• чтение простого кода;
• Git;
• логи;
• основы CI/CD;
• моки и стабы.
Не обязательно писать сложные программы. Важно понимать, что происходит «под капотом», и уметь самостоятельно разобраться с проблемой.
4️⃣ AI-грамотность
AI уже становится рабочим инструментом QA.
Стоит научиться:
• правильно формулировать задачи для AI;
• использовать его для тест-кейсов, тестовых данных и анализа;
• понимать, что такое AI-агенты и MCP;
• проверять результаты AI, а не принимать их на веру.
🎯 Главный навык QA в эпоху AI верификация.
AI может за секунды написать тест-кейс или SQL-запрос. Но может пропустить граничный сценарий, ошибиться в логике или предложить небезопасное решение.
Поэтому важно уметь задавать вопросы:
Что здесь может пойти не так? Что не учтено? Какие данные проверить? Где границы решения?
С чего начать?
Если вы Manual QA, я бы двигалась так:
API → SQL → DevTools → логи → Git → основы кода → AI-инструменты.
Не пытайтесь изучить всё сразу. Выберите один навык и закрепите его на практике.
📌 Сохрани пост как чек-лист развития Manual QA. подписывайся на @protestinginfo

⌛️ Webhook, SSE, WebSocket, polling или worker: что выбрать для долгой операции? ⌛️

Возьмём задачу:
Пользователь через наше приложение запускает генерацию видео во внешнем ИИ-сервисе. Внешний ИИ-сервис может обрабатывать запрос от нескольких десятков секунд до нескольких минут.

При этом пользователь может:

▫️ сразу увидеть, что задача принята,
▫️ наблюдать за прогрессом,
▫️ закрыть страницу и вернуться позднее,
▫️ получить результат позже, даже если соединение прервалось,
▫️ иметь возможность повторить операцию или отменить её.

📌 Тут точно нужен асинхрон.


И далее появляется вопрос:
👉 Что использовать: webhook, polling, SSE, WebSocket или фоновую обработку?

Но эти варианты нельзя просто поставить в один ряд и выбрать один «правильный».

Эти механизмы не заменяют друг друга. Они решают разные части одной задачи.



1️⃣ Как отделить генерацию от запроса пользователя

Если операция занимает несколько минут, Backend не должен всё это время держать HTTP-соединение открытым.

Вместо этого он:
1. Создаёт запись операции со статусом QUEUED (в очереди).
2. Формирует job — задание с данными для запуска генерации.
3. Сохраняет операцию и job.
4. Возвращает 202 Accepted и operationId в ответ на API-запрос.

Дальше job забирает worker.

👉 Job — это описание того, что нужно выполнить.
👉 Worker — компонент, который забирает это задание и выполняет его.

В нашем примере worker не генерирует видео самостоятельно. Он вызывает внешний ИИ-сервис, получает providerJobId и сохраняет его рядом с внутренним operationId.

Очередь при этом не обязательна. В простой системе worker может читать задания из таблицы jobs (async_tasks). При росте нагрузки появляется брокер.

📹 Подкаст про асинхронную задачу и фоновую обработку



2️⃣ Как Backend узнаёт, что видео готово

Здесь выбираем между webhook и polling.

Webhook подходит, если внешний сервис умеет сам сообщать об изменении статуса. Это основной вариант, когда результат нужен быстро и мы не хотим постоянно опрашивать провайдера.

Polling нужен, если webhook не поддерживается. Backend периодически вызывает API для проверки статуса во внешней системе, пока не получит обновление.

❗️ Но даже при наличии webhook, polling может остаться как страховка: например, раз в несколько минут проверять незавершённые операции, по которым событие не пришло.

То есть часто выбор выглядит не как «webhook или polling», а как:

👉 webhook для основного потока + polling для reconciliation.

🎧 Подкаст про webhook и polling


3️⃣ Как показать прогресс пользователю

Это уже отдельное решение.

UI polling — если интерфейсу достаточно обновлять статус раз в несколько секунд.

SSE — между UI и Backend устанавливается постоянное соединение, Backend должен передавать в браузер односторонний поток обновлений по сущности: В ОЧЕРЕДИ → ОБРАБОТКА → ГОТОВО.
🎧 Подкаст про SSE API

WebSocket — если обе стороны часто отправляют сообщения в рамках одной сессии. Например, пользователь не только смотрит прогресс, но и управляет процессом, меняет параметры или отправляет команды на отмену во время генерации.
🎧 Подкаст про WebSocket API



📚 К посту я подготовила большой гайд с разбором всех механизмов и таблицей сравнения.


Сохраняйте и используйте, когда нужно спроектировать долгую операцию, интеграцию с внешним сервисом или отображение прогресса в интерфейсе 💙

#ИнтеграцииGA

CRUD — это база, которую спрашивают на каждом собеседовании по API. Разбираем по RFC 9110
Притом CRUD больше к SQL, но и разберём и для API

➕ CREATE = POST
Создаёт новый ресурс. Данные уходят в теле запроса.
Успех: 201 Created + заголовок Location.
⚠️ Не идемпотентен: отправишь дважды — получишь два одинаковых объекта.

👁️ READ = GET
Читает данные, ничего не меняя.
Успех: 200 OK. Тела запроса нет.
✅ Безопасный и идемпотентный: можно повторять сколько угодно.

✏️ UPDATE = PUT или PATCH
PUT — заменяет ресурс ЦЕЛИКОМ (идемпотентен).
PATCH — обновляет ТОЛЬКО указанные поля (идемпотентность не гарантирована).
Успех: 200 OK или 204 No Content.
Это главное отличие, которое спрашивают почти на каждом собесе!

🗑️ DELETE = DELETE
Удаляет ресурс.
Успех: 204 No Content или 200 OK.
✅ Идемпотентен: состояние после повторов не меняется.
Нюанс: повторный DELETE того же ресурса часто вернёт 404.

• Понимание идемпотентности помогает проектировать корректные автотесты (повторный POST сломает тест, повторный GET — нет)
• Знание кодов ответов (201 vs 200 vs 204) — обязательная проверка в API-тестах
• PUT vs PATCH — классический вопрос-ловушка на собесе

📌 Подпишись на @protestinginfo — разбираю реальные вопросы с собеседований по API, HTTP и тестированию простым языком. Сохраняй карусель, чтобы повторить таблицу перед встречей!

#тестирование #QA #API #собеседованиеQA #тестированиеПО

Как системы могут обмениваться данными? 🔄
В интеграционном тестировании важно понимать не только API, но и как именно системы обмениваются данными.
На слайдах собрала основные способы — сохраняй, пригодится и в работе, и на собеседовании 👇
🔹 Синхронные интеграции
Клиент отправляет запрос и ждёт ответ от сервера. Пока ответа нет, операция может быть заблокирована.
🔹 Асинхронные интеграции
Отправителю не нужно ждать результат. Обработка может произойти позже. Для этого используют, например, Polling или Webhook.
🔹 Брокеры сообщений
Система-производитель отправляет сообщение в брокер, а consumer забирает его, когда готов обработать.
Примеры: RabbitMQ, Kafka.
🔹 Интеграции в реальном времени
Данные передаются практически сразу после события.
WebSocket — двусторонний обмен.
SSE — поток событий от сервера к клиенту.
Также используются GraphQL Subscriptions.
🔹 Общая база данных
Несколько систем работают с одной БД напрямую. Такой подход создаёт сильную связанность и чаще встречается в legacy-системах.
🔹 Обмен файлами
Системы передают файлы через FTP/SFTP или общее хранилище. Например, CSV, XML или JSON.
А есть ещё способы, которые часто встречаются в современных системах:
🔹 SDK — готовый набор инструментов для взаимодействия приложения с сервисом. Особенно часто встречается в мобильной разработке.
🔹 API Gateway — единая точка входа перед backend-сервисами. Может отвечать за маршрутизацию, авторизацию, ограничения запросов.
🔹 CDC — передача изменений из базы данных дальше в другие системы, например через Kafka.
🔹 ETL / ELT — перенос и преобразование данных между источниками и хранилищами.
🔹 Push-уведомления, Deep Links, Object Storage — тоже часть интеграционного ландшафта мобильных и backend-систем.
Для QA главное понимать кто инициирует обмен, куда попадают данные, когда приходит результат и что произойдёт при ошибке.
Сохраняй шпаргалку 📌
И отправляй коллегам, которым тоже приходится тестировать интеграции.

здесь мы готовимся к собеседованиям

FULLSTACK QA: НУЖНО ЛИ УМЕТЬ ВСЁ? 👇
Иногда кажется: если ты QA и не пишешь автотесты, то рынок уже прошёл мимо.
Но это не так.
Вакансии для Manual QA по-прежнему есть от Junior до Senior. При этом требования к сильному ручному тестировщику постепенно становятся шире.
И вот здесь начинается самое интересное 👇
Если ты Manual QA, стоит прокачивать не всё подряд, а то, что усиливает твою экспертизу:
🔹 API, HTTP, REST, JSON, Postman, Swagger/OpenAPI
🔹 SQL: SELECT, JOIN, GROUP BY, подзапросы
🔹 DevTools: Network, Console, Storage, Headers
🔹 Тест-дизайн: классы эквивалентности, граничные значения, таблицы решений
🔹 Клиент-серверное взаимодействие и понимание архитектуры
🔹 Логи и анализ ошибок
🔹 Git и базовое понимание CI/CD

А дальше уже можно выбрать специализацию:
💻 Web QA
📱 Mobile QA
🔌 Backend / API QA
🏦 FinTech QA
🔗 Интеграционное тестирование
⚡ Performance QA

А что такое FullStack QA?
Это отдельная карьерная траектория, где QA сочетает экспертизу по бизнес-логике с автоматизацией.

Например:
Тестирование → API → SQL → Automation → CI/CD
Но это не означает, что каждый QA обязан становиться FullStack QA.
Если автоматизация тебе неинтересна можно построить карьеру и в Manual QA. Еще есть время, но я рекомендую уже изучать ИИ, агенты, MCP

Главное не писать в резюме:
❌ «Занимался ручным и автоматизированным тестированием».

Гораздо сильнее показать:
☑ что именно тестировал
✅ какие задачи решал
✅ какими инструментами пользовался
✅ какой получил результат
Не количество технологий делает QA сильным. А глубина понимания продукта и способность решать задачи.

А ты сейчас кто?
Manual QA → развиваешься в глубину или уже смотришь в сторону Automation? 👇
Делись с коллегами, пусть ознакомятся с информацией.
Подписывайся на @protestinginfo

#тестирование #qa #fullstackqa #тестировщик #qaengineer

https://vk.ru/clip-211248677_456239115?c=1

Буду Рада вашей подписке

https://www.instagram.com/p/DcwP08fjNTJ/?igsi=cmNnNGhyNmxuNW9u

Разбираем SQL-задание с sqltest.online👇
нужно найти фильмы, которые реже всего берут напрокат.
📋 ЗАДАНИЕ:
— вывести title и rentals_count
— найти минимальное количество аренд
— вывести все фильмы с этим минимумом
— отсортировать по названию
💡 РЕШЕНИЕ ЧЕРЕЗ CTE на слайдах смотри и сохраняй

А ГДЕ ЗДЕСЬ CTE?
WITH film_rentals AS (...) создаёт временный именованный результат.
Дальше мы обращаемся к нему два раза:
→ FROM film_rentals
→ FROM film_rentals внутри подзапроса MIN()
Именно в такой ситуации CTE особенно удобен: не приходится повторять большой запрос с JOIN.

В карусели все подробно описано💙
💬 НА СОБЕСЕДОВАНИИ МОЖНО СКАЗАТЬ:
«Я вынесла расчёт количества аренд в CTE, потому что этот результат используется дважды. Так запрос проще читать и поддерживать».
А если спросят, почему LEFT JOIN, а не JOIN:
«Чтобы не потерять фильмы, у которых пока нет аренд».

📌 Сохраняй, если готовишься к SQL-вопросам на собеседовании.

Пройти тест на Stepik https://stepik.org/lesson/2241991/step/1?unit=2275473
Если хочешь закрепить знания и потренироваться перед собеседованием, можешь пройти Тесты по тестированию ПО для подготовки к собеседованиям
Там вопросы и практические задания по SQL, тест-дизайну, Postman, API и асинхронному взаимодействию. После каждого задания есть разбор ответа, поэтому можно сразу понять, где ошибся.
По промокоду TESTS до 30 сентября (скидка 1000р)
Посмотреть курс

https://stepik.org/a/276076/pay?promo=4ae1bbb0dcf4696b

Подписаться и поделиться

https://www.instagram.com/reel/Dctr9WXM7fs/?igsi=dHd3b2RmdXVmNjIw

Пригодится
👇 Сохрани этот пост, подпишись на @protestinginfo и делись с коллегой, у кого нет на проекте документации по API! 😉

Как перенести запрос из Chrome DevTools в Postman
Скопировать запрос как cURL в DevTools Copy cURL Bash в DevTools означает создание команды cURL для выполнения сетевого запроса из браузера прямо в терминале Bash, полностью повторяя этот запрос с заголовками и параметрами.

• Открой Chrome DevTools (F12) и перейди на вкладку Network.
• Найди нужный запрос, кликни по нему правой кнопкой мыши.
• Выбери «Copy» → «Copy as cURL (bash)».
• В буфер обмена скопируется готовая команда cURL для терминала Bash с URL, заголовками и параметрами.
Импортировать запрос в Postman
• Открой Postman.
• Нажми «Import».
• Вставь скопированную команду cURL в строку «Paste cURL, Raw text or URL” в открывшемся окне. Нажми «Import into collection» или «Import without saving»
Или вставь скопированную команду cURL в адресную строку нового созданного HTTP запроса
• Postman автоматически создаст запрос с теми же параметрами, заголовками и телом, что и в DevTools.
Этот простой способ помогает быстро тестировать запросы, даже если на проекте нет полной документации по API.
Используй этот трюк каждый день - экономь время и будь на шаг впереди!

#QA #Тестирование #Postman #DevTools

https://vk.ru/story-211248677_456239062