Вопросы на собеседовании тестировщика (QA junior)

API тестируют без интерфейса: отправляем запросы (Postman, curl) и проверяем статус, тело ответа, схему данных, побочные эффекты и обработку ошибок.

Идентификация — кто вы (логин), аутентификация — докажите это (пароль, код), авторизация — что вам разрешено делать.

Методы по доступу к коду: чёрный ящик — без знания внутреннего устройства, белый — с доступом к коду, серый — частичное знание (база, логи, API).

Ошибки чаще всего на границах классов, поэтому проверяем саму границу и значения рядом с ней.

Типичный путь: Новый → Открыт → В работе → Исправлен → Проверка (ретест) → Закрыт; при неудачном ретесте — Переоткрыт.

Баг-репорт — описание дефекта, по которому разработчик воспроизведёт его без вопросов: заголовок, шаги, фактический и ожидаемый результат, окружение, вложения.

Браузер находит IP через DNS, устанавливает соединение (TCP, TLS для HTTPS), отправляет HTTP-запрос, сервер возвращает ответ, браузер отрисовывает страницу и догружает ресурсы.

Cookies — небольшие данные, которые браузер отправляет на сервер с каждым запросом (сессия, настройки); localStorage и sessionStorage — хранилища, доступные только скриптам…

Таблица решений описывает все комбинации условий и результат для каждой — так не теряются сочетания в сложной бизнес-логике.

DevTools помогают локализовать баг: Network — запросы и ответы, Console — ошибки JavaScript, Application — cookies и хранилища, Elements — вёрстка.

Делим входные данные на группы, которые система обрабатывает одинаково, и берём по одному значению из каждой.

Исследовательское тестирование — одновременное изучение продукта, придумывание и выполнение проверок, без заранее написанных тест-кейсов.

Функциональное — что система делает (функции по требованиям), нефункциональное — как она это делает (скорость, удобство, надёжность, безопасность).

GET — получить данные, POST — создать или отправить, PUT — заменить целиком, PATCH — изменить частично, DELETE — удалить.

Пять групп: 1xx информационные, 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера.

Pairwise — подбор набора тестов, в котором каждая пара значений любых двух параметров встречается хотя бы один раз.

Позитивное — проверка с корректными данными и ожидаемыми действиями; негативное — с некорректными, чтобы убедиться, что система правильно обрабатывает ошибку.

Это вложенные уровни: QA — обеспечение качества процессов, QC — контроль качества продукта, тестирование — конкретные проверки.

Требования проверяют до разработки: полнота, однозначность, непротиворечивость, проверяемость, выполнимость — каждая найденная дыра дешевле бага в коде.

Тестирование идёт на всех этапах разработки, а не только в конце: от проверки требований до приёмки и мониторинга после релиза.

Серьёзность (severity) — насколько дефект влияет на систему; приоритет (priority) — насколько срочно его исправлять для бизнеса.

Smoke — быстрая проверка, что сборка вообще работает; sanity — узкая проверка конкретного исправления или функции; регресс — что изменения не сломали старое.

SQL нужен, чтобы проверять данные в базе после действий, готовить тестовые данные и искать причину бага.

Если у объекта есть статусы (заказ, заявка, аккаунт), рисуем состояния и переходы между ними и проверяем каждый переход — и недопустимые тоже.

Тест-кейс — подробная проверка: предусловия, шаги, тестовые данные, ожидаемый результат; чек-лист — список того, что проверить, без детальных шагов.

Четыре уровня: модульное (функция, класс) → интеграционное (взаимодействие частей) → системное (продукт целиком) → приёмочное (готов ли для пользователя).

Начните с вопросов о требованиях: для кого предмет и как его используют — затем структурируйте проверки по видам.

Тест-план отвечает на вопросы что, как, кем, когда и до каких пор тестируем на проекте или релизе.

Семь классических принципов: тестирование показывает наличие дефектов, исчерпывающее невозможно, раннее — дешевле, дефекты скапливаются, парадокс пестицида, тестирование зависит…

Тестирование — проверка, что продукт работает как ожидается и решает задачу пользователя; цель — дать информацию о качестве и снизить риски.

Автоматизируют повторяющиеся, стабильные и критичные проверки — регресс, smoke, API; вручную — новое, меняющееся и то, где важен человеческий взгляд.