Материал Эйч · Опубликовано 6 августа 2026
Middle QA в продуктовой команде средств защиты информации ViPNet: ручное тестирование, тестовая документация, Linux-стенды и API
Фишка: ИнфоТеКС — один из лидеров российского рынка ИБ (35+ лет, ТОП-10), разработчик экосистемы ViPNet. Тестировщик работает с комплексными сетевыми продуктами: VPN, NGFW, защита каналов связи. Важны навыки администрирования Linux-стендов, виртуализации (VMware vSphere, Proxmox) и контейнеризации Docker — тестовая инфраструктура близка к продакшену.
| Этап | Длительность | Что проверяют |
|---|---|---|
| HR-скрининг | 30 мин | Мотивация, опыт 3+ лет, готовность к офису в Томске, зарплатные ожидания, сроки выхода |
| Техническое интервью | 60–90 мин | Тест-дизайн, сети, Linux, Docker, API, интеграционное тестирование, разбор реальных кейсов из опыта |
| Практическое задание | 45–60 мин | Написание тест-кейсов, тестирование API в Postman или оформление баг-репорта по описанию дефекта |
| Встреча с руководителем | 30–45 мин | Софт-скиллы, работа с тестовыми стендами, взаимодействие с разработчиками, понимание специфики ИБ-продуктов |
Обязательный минимум
Плюсом будет
Какие знаешь техники тестирования дизайна?
Эквивалентное разбиение, граничные значения, попарное (pairwise), таблицы решений, диаграммы состояний, предугадывание ошибок. Приведи пример применения к сетевому продукту.
Расскажи про свой опыт работы с техниками тест-дизайна
Опиши конкретный модуль: входные данные → техника → сколько кейсов → что покрыл. Упомяни приоритизацию по рискам.
Как составлял тест-кейс?
Структура: ID, название, предусловия, шаги, ожидаемый результат, постусловия, приоритет. Покажи связь с требованиями.
Что такое жизненный цикл бага?
New → Assigned → Open → Fixed → Retest → Verified → Closed / Reopened / Deferred / Rejected. Знай роли: тестировщик, разработчик, менеджер.
Что такое приёмочное тестирование?
Проверка соответствия продукта бизнес-требованиям и критериям приёмки заказчиком (UAT). Отличается от системного и регрессионного.
Есть ли опыт тестирования требований?
Анализ ТЗ на полноту, непротиворечивость, тестируемость. Задавай уточняющие вопросы до начала тестирования.
Фишка: В ИнфоТеКС тестировщик ведёт и поддерживает тестовую документацию в актуальном состоянии — на собесе могут попросить написать кейсы «на месте» для сетевого сценария.
Совет: При ответе про тест-дизайн всегда связывай технику с экономией времени: «граничные значения для порта 1–65535 вместо перебора всех».
Ловушка: Не путай чек-лист (краткий список проверок) и тест-кейс (детальные шаги с ожидаемым результатом).
Что такое клиент-серверная архитектура?
Клиент инициирует запрос, сервер обрабатывает и отвечает. Уровни: представление, бизнес-логика, данные. Примеры: веб-приложение, VPN-клиент ↔ VPN-сервер.
Что такое GET-запрос?
HTTP-метод для получения ресурса. Идемпотентный, данные в URL (query string). Не для передачи чувствительных данных.
Как передаются данные в GET?
Через query-параметры в URL после «?», разделённые «&». Ограничение длины URL, видимость в логах.
Из чего состоит запрос на сервер?
Строка запроса (метод, URI, версия HTTP), заголовки (Headers), тело (Body, опционально). Ответ: статус-код, заголовки, тело.
Что такое WebSocket?
Протокол полнодуплексной связи поверх TCP после HTTP-handshake (Upgrade). Для real-time: чаты, мониторинг, push-уведомления.
Есть ли опыт работы с SOAP?
XML-based протокол для веб-сервисов. WSDL описывает контракт. Отличие от REST: строгая схема, envelope/header/body.
В чём разница между JSON и XML?
JSON — легковесный, нативен для JS/REST. XML — строгая схема, namespaces, валидация XSD. Оба используются в enterprise и ИБ.
Фишка: Продукты ViPNet работают с сетевыми протоколами, VPN-туннелями, защищёнными каналами — базовое понимание TCP/IP и маршрутизации обязательно.
Ловушка: GET не предназначен для изменения данных — это частый вопрос-ловушка. Для создания/изменения — POST, PUT, PATCH, DELETE.
Какие знаешь команды в терминале?
Навигация: ls, cd, pwd. Файлы: cat, grep, tail -f, find. Процессы: ps, top, kill. Сеть: ip a, netstat/ss, curl, ping, traceroute. Права: chmod, chown.
Какой опыт работы с Docker?
Образ, контейнер, Dockerfile, docker run/exec/logs, docker-compose для мультиконтейнерных стендов. Volumes для персистентности.
Какие использовал протоколы передачи IP?
TCP (надёжный, с установкой соединения), UDP (без установки, быстрее), ICMP (диагностика). Уровни OSI/TCP-IP.
Фишка: Вакансия явно требует VMware vSphere и Proxmox — будь готов рассказать, как поднимал ВМ для тестового стенда, снапшоты, сетевые настройки.
Совет: Опиши типичный рабочий день на стенде: развернуть ВМ → установить продукт → проверить сетевую связность → собрать логи при дефекте.
Ловушка: Docker ≠ виртуализация. Контейнеры разделяют ядро хоста, ВМ — полная изоляция. Для ИБ-продуктов часто нужны оба подхода.
Какими пользуешься инструментами для тестирования API?
Postman, Insomnia, curl, DevTools (Network tab). Для нагрузки — JMeter. Укажи коллекции, окружения, автоматизацию.
Есть ли опыт работы в Postman с переменными?
Environment/collection/global variables, {{var}} синтаксис, pre-request scripts, тесты в Tests-tab (pm.test, pm.response).
Какая вкладка DevTools меняет скорость работы сети?
Network → Throttling (Slow 3G, Offline). Также можно блокировать запросы, смотреть Headers/Payload/Response.
Можно ли редактировать Cookie?
Да, через DevTools → Application → Cookies, или в Postman. Важно для тестирования сессий и авторизации.
Совет: На практике могут дать endpoint и попросить проверить статус-коды, заголовки авторизации, негативные сценарии (401, 403, 400).
Ловушка: Не забывай про негативные тесты API: невалидный токен, пустое тело, неверный Content-Type.
Как оцениваешь свой уровень знания SQL?
Честно оцени: SELECT, JOIN, WHERE, GROUP BY, HAVING, подзапросы. Приведи пример запроса из практики.
Расскажи про свой опыт работы с SQL
Для чего использовал: проверка данных после API-запроса, валидация миграций, поиск тестовых записей.
Какие знаешь виды баз данных?
Реляционные (PostgreSQL, MySQL) — ACID, таблицы, связи. NoSQL: документные (MongoDB), key-value (Redis), колоночные, графовые.
Что такое первичный ключ (Primary Key)?
Уникальный идентификатор строки. Не NULL, один на таблицу. Суррогатный (auto-increment) vs натуральный.
Совет: Для QA достаточно уметь SELECT с JOIN для проверки бэкенда. INSERT/UPDATE — для подготовки тестовых данных.
Какие знаешь методы интеграционного тестирования?
Big Bang, Top-down, Bottom-up, Sandwich. Проверка взаимодействия модулей/сервисов через API, очереди, БД.
Что такое интеграция?
Объединение компонентов в единую систему с проверкой интерфейсов взаимодействия. В микросервисах — через API и message brokers.
Какой опыт автоматизации тестирования?
Даже при фокусе на ручном тестировании — знай основы: зачем автоматизируют, что оставляют ручным (exploratory, UX).
Как был устроен рабочий процесс на прошлом проекте?
Agile/Scrum: спринты, daily, ретро. Роль QA: ревью требований, тест-план, тестирование, регресс, релиз. Jira/YouTrack.
Как была устроена документация на прошлом проекте?
Confluence/Wiki: ТЗ, тест-планы, кейсы в TMS (TestRail, Qase), баг-трекер. Версионирование документации.
Фишка: Плюсом будет опыт интеграционных проектов со старой и новой экосистемой — типичный сценарий при развитии линейки ViPNet.
Совет: Упомяни Kafka/RabbitMQ/NATS, если есть опыт: публикация/потребление сообщений, проверка доставки, dead letter queue.
Написание тест-кейсов для авторизации VPN-клиента
Дано: VPN-клиент ViPNet. Пользователь вводит логин и пароль, выбирает сервер из списка, нажимает «Подключиться». При успехе — статус «Подключено», при ошибке — сообщение с кодом. Напиши набор тест-кейсов, применив техники тест-дизайна.
1) Позитивный: валидные логин/пароль + доступный сервер → «Подключено». 2) Граничные: пустой логин, пустой пароль, макс. длина полей. 3) Негативные: неверный пароль → код ошибки, недоступный сервер → таймаут, отозванный сертификат. 4) Эквивалентные классы: валидный/невалидный логин, валидный/невалидный пароль. 5) Состояния: подключение → отключение → повторное подключение. Минимум 8–12 кейсов с предусловиями и ожидаемыми результатами.
Сложность: O(n) по количеству комбинаций входных данных
Тестирование REST API через Postman
Дан endpoint: POST /api/v1/users с телом {"name": "string", "email": "string", "role": "admin|user"}. Авторизация: Bearer token. Проверь API: создай коллекцию с позитивным, негативным и граничными запросами.
Позитивный: POST с валидными данными → 201, тело содержит id. Негативные: без токена → 401, невалидный email → 400, role="superadmin" → 400, пустое name → 400. Граничные: name из 1 символа, name из 255 символов, name из 256 → 400. В Tests: pm.test('Status 201'), pm.expect(json.id).to.exist. Переменные: {{baseUrl}}, {{token}}.Сложность: O(1) на запрос
Оформление баг-репорта по дефекту сетевого продукта
При тестировании NGFW обнаружено: после обновления правил firewall трафик на порт 443 блокируется для подсети 10.0.1.0/24, хотя правило ALLOW существует. Окружение: Proxmox, 2 ВМ (клиент + сервер), Ubuntu 22.04. Оформи баг-репорт.
Заголовок: [NGFW] Трафик 443 блокируется для 10.0.1.0/24 после обновления правил. Шаги: 1) Создать правило ALLOW tcp/443 для 10.0.1.0/24. 2) Применить конфигурацию. 3) С клиента 10.0.1.5 выполнить curl https://10.0.2.10. Ожидаемый: соединение установлено. Фактический: Connection timed out. Окружение: ViPNet NGFW vX.Y, Proxmox 8, Ubuntu 22.04. Приоритет: High. Вложения: скриншот правил, tcpdump, логи firewall.
Сложность: N/A
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| Тест-дизайн | можешь назвать 5+ техник и применить эквивалентное разбиение к полю ввода |
| Сети | объясняешь клиент-сервер, HTTP-методы, структуру запроса и коды 2xx/4xx/5xx |
| Linux и инфраструктура | называешь 10+ CLI-команд и описываешь, как поднимал тестовый стенд на ВМ/Docker |
| API | создаёшь коллекцию Postman с переменными и негативными тестами за 15 минут |
| SQL | пишешь SELECT с JOIN и объясняешь, зачем QA работает с БД |
| Документация | оформляешь баг-репорт с шагами, окружением и ожидаемым/фактическим результатом |
| ИнфоТеКС | знаешь, что компания делает (ViPNet, ИБ), и можешь объяснить мотивацию |
В день собеседования