📚 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