Иногда кажется: если ты 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? 👇

Как системы могут обмениваться данными? 🔄
В интеграционном тестировании важно понимать не только 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 главное понимать кто инициирует обмен, куда попадают данные, когда приходит результат и что произойдёт при ошибке.
Сохраняй шпаргалку 📌
И отправляй коллегам, которым тоже приходится тестировать интеграции.
подписывайся на @protestinginfo , здесь мы готовимся к собеседованиям

Разбираем 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-вопросам на собеседовании.

А хочешь закрепить SQL?

Лови короткий тест по SQL 🔥
https://stepik.org/lesson/2241991/step/1?unit=2275473

Промокод, если хочешь продолжить готовиться к собеседованию

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


А также подписывайся на @protestinginfo , здесь я направляю по подготовке к собеседованиям по тестированию ПО, QA

#SQL #CTE #QA #тестирование #собеседованиеQA