Вопросы на собеседовании тестировщика обычно переходят от терминов к ситуации: как проверить форму, локализовать ошибку API, выбрать приоритет и оформить доказательство. Готовьте основы процесса, техники тест-дизайна, баг-репорты, HTTP, SQL и DevTools, но отвечайте через риск, наблюдение и воспроизводимый результат.
ISTQB Foundation Level 4.0 систематизирует фундаментальные принципы, жизненный цикл, статическое тестирование, техники black-box и white-box, управление и инструменты. На реальном интервью могут использовать другую терминологию, поэтому не спорьте о слове без контекста. Объясните цель проверки и договоритесь о значении термина. Для junior важна логика выбора тестов, а не максимальное количество случаев. Ответ всегда привязывайте к риску продукта.
Принципы, уровни, типы, техники и жизненный цикл.
DevTools, curl или Postman, SQL и трекер.
Форма, API, баг-репорт и оценка риска.
Вопросы на собеседовании тестировщика на примере формы
Задача «протестируйте поле возраста от 18 до 100» проверяет граничные значения и классы эквивалентности. Не перечисляйте случайные числа. Назовите валидный класс, два невалидных класса, границы и соседние значения. Затем добавьте пустое поле, формат и слишком длинный ввод как отдельные риски.
Правило: целое число от 18 до 100 включительно
Границы и соседи:
- 17: отклонить
- 18: принять
- 19: принять
- 99: принять
- 100: принять
- 101: отклонить
Дополнительные классы:
- пусто
- 18.5
- "eighteen"
- пробелы до и после
Для каждого теста записать expected и actual.- Набор покрывает обе границы и соседние значения
- Каждый случай связан с правилом и ожидаемым результатом
Интервьюер может добавить API. Тогда проверьте, совпадает ли клиентская валидация с серверной, какой HTTP-статус возвращается и не создаётся ли объект при неверном возрасте. Для SQL найдите сохранённую запись по тестовому идентификатору. Для доступности убедитесь, что ошибка связана с полем и читается без цвета. Для безопасности не отправляйте персональные данные в общую среду.
Частые блоки интервью QA
| Элемент | Что означает | Что делать |
|---|---|---|
| Тест-дизайн | Границы, классы, таблицы решений, переходы | Сократить набор без потери риска |
| Дефект | Шаги, expected, actual, окружение | Дать воспроизвести |
| Web | DOM, Network, storage, адаптивность | Локализовать слой |
| API | Метод, статус, headers, JSON, auth | Проверить контракт |
| SQL | SELECT, JOIN, GROUP BY, NULL | Сверить состояние данных |
Severity описывает влияние дефекта, priority определяет порядок исправления с учётом бизнеса. Smoke быстро проверяет критический путь сборки, regression ищет нежелательные изменения в ранее работавших функциях. Retest подтверждает конкретное исправление. Эти определения полезны только вместе с примером. Покажите, как один дефект может иметь высокую серьёзность, но низкий приоритет в недоступном пользователям разделе.
Практика: разберите поле возраста от 18 до 100 как на интервью
Возьмите любую форму регистрации с полем возраста и разберите её так, как будете отвечать вслух. Правило одно: целое число от 18 до 100 включительно. Успех - это шесть значений на границах, четыре дополнительных класса и один оформленный баг-репорт с expected, actual и ответом сервера. Всё пишите в таблицу, а не в голове.
- Правило поля возраста. Запишите правило одной строкой: целое число от 18 до 100 включительно. Из него сразу видны валидный класс и два невалидных: меньше 18 и больше 100.
- Границы и соседи. Выпишите шесть значений: 17, 18, 19, 99, 100, 101, и напротив каждого ожидаемый вердикт. Прогоните их через форму и поставьте actual рядом с expected: расхождение хотя бы в одной строке уже дефект.
- Классы за пределами чисел. Добавьте пустое поле, 18.5, «eighteen» и пробелы до и после значения. Смотрите, у каждого ли случая своя понятная ошибка рядом с полем, а не общее сообщение вверху формы.
- Серверная проверка через curl. Откройте DevTools, вкладку Network, посмотрите запрос отправки формы и повторите его с возрастом 101 через curl или Postman мимо клиентской валидации. Запишите HTTP-статус и тело ответа, затем найдите SELECT по тестовому идентификатору: записи с возрастом 101 в таблице быть не должно.
- Баг-репорт с доказательством. Оформите один найденный дефект: шаги, expected, actual, окружение и сам ответ API. Отдельной строкой проставьте severity и priority и объясните, почему они могут расходиться.
Теперь сломайте сценарий намеренно: отправьте возраст 101 запросом curl, когда форма это значение уже отклоняет. Если сервер вернёт 200 и объект создастся, вы поймали расхождение клиентской и серверной валидации: это дефект с высокой серьёзностью, и аккуратное сообщение в форме его не закрывает. Если вернётся 4xx с указанием поля, серверная проверка на месте, а подпись у поля отвечает только за удобство. Повторите отправку с валидным 18 и убедитесь, что нормальный путь проходит.
Дальше усложняйте по той же форме: замените возраст датой рождения и посмотрите, как граница 18 лет поплывёт из-за високосного года и часового пояса. Добавьте таблицу решений для пары полей, которые зависят друг от друга, чтобы сократить набор без потери риска. Соберите из проверенных случаев короткий smoke-чек-лист по критическому пути регистрации. Автоматизировать имеет смысл именно граничные значения: они стабильны и часто ломаются после правок валидации.
Частые ошибки и почему они появляются
Слабый кандидат перечисляет сто тестов, не уточнив назначение формы. Второй риск: считать найденную ошибку доказанной по одному скриншоту без запроса, ответа и окружения. Третий: говорить, что автоматизация заменяет ручное исследование. Автотест быстро повторяет известную проверку, но выбор риска остаётся инженерной задачей.
Свяжите определение с наблюдаемой ситуацией.
Сначала проверяйте потерю данных, деньги, доступ и критический путь.
Назовите область, риски, ограничения и остаточные неизвестные.
Самопроверка
Чем retest отличается от regression?
Retest перепроверяет один конкретный дефект по шагам из баг-репорта после исправления. Regression шире: она ищет побочные изменения в функциях, которые раньше работали, и запускается после сборки, даже если их не трогали.
Какие значения назвать при тестировании поля возраста от 18 до 100?
Для диапазона от 18 до 100 назовите границы и соседей: 17, 18, 19, 99, 100, 101. Дальше добавьте отдельные классы, которые числами не являются: пустое поле, 18.5, буквенный ввод и пробелы до и после значения.
Чем severity отличается от priority?
Severity описывает влияние дефекта на продукт, priority задаёт порядок исправления с учётом бизнеса. Поэтому дефект в разделе, который недоступен пользователям, может иметь высокую серьёзность и низкий приоритет, и наоборот.
Как проверить, совпадает ли клиентская валидация с серверной?
Клиентскую валидацию проверяют в обход формы: возьмите запрос из вкладки Network в DevTools и повторите его через curl или Postman с заведомо неверным значением. Смотрите HTTP-статус, тело ответа и запросом SELECT убеждайтесь, что объект в базе не создался.
Сколько тестов нужно назвать, чтобы ответ засчитали?
Количество тестов не критерий: интервьюер смотрит на связь проверок с требованием, риском и доказательством. Небольшой набор с обеими границами и объяснением, что вы сознательно не покрываете, выглядит сильнее списка из ста случайных чисел.
Заменяет ли автоматизация ручное тестирование?
Автотест быстро повторяет уже известную проверку, но не решает, какой риск важнее. Выбор техники, границ и порядка проверок остаётся инженерной задачей человека, поэтому на интервью спрашивают именно про логику выбора.
Что делать дальше
Возьмите форму, API и одну таблицу данных, подготовьте по ним чек-лист, curl-запрос и SQL-проверку. Подготовку целиком закрывает профессия QA-инженер / Тестировщик. Дорожную карту смотрите в статье про вход в QA, а общую подготовку в плане до junior.