GraphQL для QA: с чего начать и что спросят на собеседовании
Если в вакансии уже мелькает GraphQL, но в голове пока только REST - этот пост для тебя. GraphQL все чаще встречается в продакшне, и на собеседовании от QA ждут, что ты хотя бы базово понимаешь, как с ним работать.
Что такое GraphQL простыми словами
GraphQL - это язык запросов к API, где клиент сам решает, какие именно поля ему нужны. Не нужно тянуть «лишние» данные, как это часто бывает в REST. В одном запросе ты можешь получить сразу всё, что нужно экрану или модулю.

Для тестировщика это значит: важно уметь читать схему, понимать, какие типы данных доступны, и проверять, что сервер действительно возвращает только то, что запрошено.
Основные компоненты GraphQL для собеседования
Вот три слова, которые очень любят рекрутеры и тимлиды:
• Query – чтение данных.
Пример: получить профиль пользователя, список товаров, детали заказа.
• Mutation – изменение данных.
Пример: создать тег, обновить email, удалить комментарий.
• Subnoscription – подписка на изменения.
Пример: получать обновления в реальном времени по чату или статусу заказа.
На собеседовании тебя могут попросить:
• объяснить разницу между Query и Mutation;
• рассказать, почему Query можно кешировать, а Mutation – нет;
• показать, как бы ты протестировал простую Mutation на обновление данных.

Что можно добавить в свою подготовку
• Посмотреть несколько реальных схем GraphQL и потренироваться писать простые Query и Mutation.
• Попробовать прогнать их через GraphiQL/Insomnia/Postman.
• Составить список проверок: валидация аргументов, ошибки, права доступа, проверка структуры ответа.

Хочешь разложить GraphQL и другие темы для собеседования по шагам, а не хаотично гуглить перед интервью?
👉 Переходи по ссылке к курсу с практикой по тестированию GraphQL API с промокодом на 1500р - GRAPHQL1500 до 31 января 2026г


https://stepik.org/a/252924/pay?promo=4449ccf0546d4b2d

gRPC для QA: разверни

Unary, Streaming и собеседование
В вакансии gRPC, а ты пока уверенно только в REST? Тогда держи короткий разбор.
gRPC - RPC-протокол от Google, который работает на HTTP/2 и использует Protobuf (бинарный формат вместо JSON), поэтому часто быстрее и экономнее по трафику, чем REST.
Что важно тестировщику: уметь читать .proto как контракт, понимать 4 типа RPC, проверять статус-коды и поведение стриминга.
4 типа RPC, которые любят спрашивать
1. Unary (1 запрос → 1 ответ). Пример: получить пользователя по id. Тесты: валидация полей, корректные данные в ответе, негативные кейсы.
2. Server streaming (1 запрос → поток ответов). Пример: стрим логов/событий. Тесты: порядок сообщений, нет дублей, поток корректно закрывается.
3. Client streaming (поток запросов → 1 ответ). Пример: загрузка метрик пачками. Тесты: сервер обработал все сообщения, ответ приходит после завершения потока.
4. Bidirectional streaming (поток ↔️ поток). Пример: чат. Тесты: задержки, порядок, ошибки в середине потока, reconnect.
Статус-коды gRPC (must know)
• 0 OK — успех
• 3 INVALID_ARGUMENT — клиент отправил некорректные данные
• 5 NOT_FOUND — сущность не найдена
• 14 UNAVAILABLE — сервис недоступен (retry логика)
• 16 UNAUTHENTICATED — проблемы с авторизацией
Практика перед интервью

Хочешь пройти практику на реальных gRPC практических примерах переходи по ссылке с промокодом на 1500р - GRPC1500 до 31 января 2026г


https://stepik.org/a/254052/pay?promo=30eb59ad283bfd76