Собеседование тестировщика (QA):
вопросы и ответы.

Покажите систему, а не поток случайных идей: валидные значения, границы (0, 1, 17, 18, 117, 118 — по требованиям), классы невалидных (буквы, отрицательные, дробные, пустое, пробелы), поведение UI и сообщение об ошибке, проверка на уровне API в обход формы.

Severity — техническая тяжесть, priority — очерёдность исправления для бизнеса. Классические примеры: опечатка в названии компании на главной (низкая severity, высокий priority) и падение экзотического сценария, которым никто не пользуется (наоборот).

Заголовок с сутью, шаги воспроизведения, ожидаемый и фактический результат, окружение, вложения (скриншот, лог, HAR). Критерий качества: разработчик воспроизводит баг без вопросов к вам. Упомяните проверку на дубликаты перед заведением.

Позитивный сценарий и схема ответа, валидация полей, коды ошибок (400, 401, 404, 409), идемпотентность повторного запроса, граничные размеры данных, проверка результата в БД. Плюс: что будет при недоступности зависимого сервиса.

Риск-ориентированный подход: сначала критичные пользовательские сценарии и зоны, затронутые изменениями, потом остальное. Упомяните смоук как минимальный барьер и честную коммуникацию: явно сказать, что не успели проверить, а не молча сократить объём.

LEFT JOIN с проверкой IS NULL либо NOT EXISTS. Проговорите, чем LEFT JOIN отличается от INNER — это базовый маркер. Для QA важно уметь проверять данные за интерфейсом, а не только через UI.

Тест, который падает недетерминированно. Причины: жёсткие sleep вместо умных ожиданий, зависимость от порядка тестов, общие данные, гонки. Лечение: явные ожидания условий, изоляция данных, ретраи только как временная мера с расследованием.

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

Не решать в одиночку: быстро оценить воспроизводимость и влияние, сообщить команде с фактами, дать варианты — откатить фичу, перенести релиз, выпустить с известной проблемой и хотфиксом. Решение о релизе принимает команда, ваша роль — точная информация.

Спор переводите к источнику истины: требования, макеты, аналитика, поведение конкурентов. Если требования молчат — это вопрос к продакту, а не спор двух мнений. Покажите, что умеете отстаивать качество без конфликта.