Вопросы на собеседовании QA на английском: 24 вопроса, образцы ответов и глоссарий

Как отвечать: определение, пример, компромисс

Интервьюер редко ждёт цитату из учебника. Ему важно понять, знаете ли вы термин, применяли ли его и видите ли границы применимости. Отсюда схема ответа: одно предложение с определением, одно-два с примером из проекта и одно с оговоркой — когда приём не работает или чем за него платят. Образцы ниже написаны так, как говорят вслух, с сокращениями вроде I'd и don't: для устного ответа это норма.

• Определение: «In short, … is …».
• Пример: «On my last project, we…», «For example, when we tested…».
• Оговорка: «The downside is…», «It depends on…».
• Спорный термин: «On my team, we used this term for…».
• Не знаете: «I haven't used it in production, but my understanding is…».

Теория и тест-дизайн: 8 вопросов

Этот блок задают и начинающим, и опытным кандидатам. Определения в образцах опираются на глоссарий ISTQB. Следите за числами: для поля с допустимым диапазоном 18–65 классы эквивалентности — «меньше 18», «от 18 до 65» и «больше 65», а граничные значения — 17, 18, 65 и 66. Если сказать только «проверю границы», скорее всего, последует уточнение: «Which values exactly?»

• ISTQB Glossary: онлайн-глоссарий терминов тестирования

Баги, приоритеты и процесс: 6 вопросов

Severity описывает ущерб от дефекта, priority — очередь на исправление, и совпадать они не обязаны. Глоссарий ISTQB разводит и три слова, которые в разговоре сливаются в «баг»: error — действие человека, которое приводит к дефекту; defect — изъян в рабочем продукте; failure — событие, когда система при выполнении не делает того, что должна.

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

• Mozilla: Bug Writing Guidelines
• QA: баги и процессы — вопросы на собеседовании

API, SQL и автоматизация: 6 вопросов

HTTP спрашивают и у ручных тестировщиков; факты удобно сверять по MDN. Код 401 означает, что запросу не хватает действительных учётных данных; 403 — что учётные данные действительны, но прав на действие нет. Идемпотентен метод, у которого эффект одного запроса и нескольких одинаковых совпадает: таковы все безопасные методы, например GET и HEAD, а также PUT и DELETE; для POST и PATCH это не гарантировано. В SQL, по документации PostgreSQL, WHERE отбирает строки до вычисления групп и агрегатов, HAVING — группы после.

В автоматизации частая тема — нестабильные тесты и ожидания. Playwright относит к flaky тест, который упал при первом запуске и прошёл при повторе, причём повторы по умолчанию выключены. Там же описано автоожидание: перед кликом Playwright ждёт, пока элемент станет видимым, перестанет двигаться, сможет получать события и не будет отключён. В pytest область действия фикстуры по умолчанию — function, код после yield выполняется при завершении, а общие фикстуры выносят в conftest.py.

• MDN: 401 Unauthorized
• MDN Glossary: Idempotent
• MDN: метод PUT
• PostgreSQL: Aggregate Functions (WHERE и HAVING)
• Playwright: Retries
• Playwright: Auto-waiting
• pytest: How to use fixtures

Английский для QA: глоссарий по ISTQB

Определения в таблице пересказаны по английской версии онлайн-глоссария ISTQB (проверено 14 ноября 2026 года). Отдельных статей sanity test и flaky test мы в нём не нашли: это слова индустрии, и их значение зависит от команды. Термин запоминается, когда к нему привязан пример из вашего проекта: для каждой строки придумайте своё предложение в прошедшем времени и проговорите его вслух.

• ISTQB Glossary: онлайн-глоссарий терминов тестирования

Практическое задание: «How would you test a login form?»

Это задание проверяет не количество идей, а порядок. Слабый ответ — поток проверок вперемешку, без единого вопроса и без приоритетов. Сильный начинается с уточнений, затем идёт по группам — позитивные сценарии, негативные, обработка ввода, безопасность, удобство и доступность, особые условия — и заканчивается тем, что вы проверите первым.

Для блока безопасности есть на что опереться. Шпаргалка OWASP по аутентификации рекомендует отвечать на любую неудачную попытку одним общим сообщением, чтобы по тексту ошибки нельзя было узнать, существует ли учётная запись, ограничивать число попыток входа, разрешать вставку в поля логина и пароля и открывать страницу входа только по TLS. Каждая рекомендация превращается в проверку. Ниже — каркас ответа примерно на две минуты.

First, I'd ask a few questions:
- Which login methods do we support: password, SSO, 2FA?
- What are the password rules and the lockout policy?
- Which browsers and devices matter most?

Then I'd test in this order:
1. Happy path: valid email and password, "Remember me",
   logout, redirect back to the page I came from.
2. Negative cases: wrong password, unknown email,
   empty fields, a locked account.
3. Input handling: leading or trailing spaces, an email
   typed in a different case, the shortest and longest
   allowed password, special characters.
4. Security: the same error message for a wrong email
   and a wrong password; a limit on failed attempts;
   the password is masked and never appears in the URL;
   HTTPS only; SQL injection and XSS strings.
5. Usability and accessibility: Tab order, Enter submits
   the form, paste works in both fields, clear error
   messages, labels for screen readers.
6. Edge conditions: a slow network, a double click
   on the button, several sessions at once.

If time is short, I'd start with the happy path, the lockout
and the generic error message: they carry the most risk.

• OWASP Cheat Sheet Series: Authentication Cheat Sheet

Поведенческие вопросы для QA: 4 вопроса и пример ответа

Поведенческая часть строится на прошлых ситуациях: «Tell me about a time when…». Отвечайте по схеме «ситуация — задача — действие — результат», говорите I, а не we, когда описываете свои действия, и заканчивайте числом или изменением в процессе.

Подготовьте по одной истории на каждую тему и проговорите с таймером: полторы-две минуты на ответ. В примере ниже нет оправданий, зато есть причина, исправление и перемена в работе команды. Сюжет и цифры условные: подставьте свои.

• «Tell me about a bug that escaped to production» — ответственность и выводы.
• «Tell me about a time you disagreed with a developer» — спорите ли вы фактами.
• «Describe a time you had to test under a tight deadline» — приоритизация по риску.
• «What process improvement are you most proud of?» — инициатива и измеримый результат.

Question: Tell me about a bug that escaped to production.

Situation: Last year a discount bug reached production:
a promo code was applied twice when a user double-clicked
the Apply button.
Task: I owned the checkout test suite, so I had to find out
why we missed it and make sure it couldn't happen again.
Action: I reproduced the issue, wrote a clear report and
worked with the developer on the fix the same day. Then
I added API tests for repeated requests and a UI check
for double clicks, and I proposed a rule: every payment
endpoint gets a duplicate-request test.
Result: The fix shipped within a day. Over the next two
quarters we had no duplicate-request defects in checkout,
and the rule became part of our definition of done.

Как тренироваться: вслух, с таймером, с повторением

Прочитать образцы недостаточно: на собеседовании вы будете говорить, а не узнавать знакомый текст. Берите пять вопросов в день, отвечайте вслух на английском, записывайте себя и сверяйте с образцом: прозвучали ли определение, пример и оговорка, уложились ли вы в минуту. Вопросы, на которых запнулись, возвращайте через день и через неделю, а за два-три дня до интервью устройте репетицию целиком с коллегой, который перебивает уточнениями. Для терминов и коротких определений удобны карточки с интервальным повторением: в RecallDeck есть треки по ручному тестированию и автоматизации.

• Junior Manual QA: репетиция собеседования
• Вопросы по теории тестирования
• Вопросы по тест-дизайну
• Нестабильные тесты Playwright: автоожидание и проверки
• Интервальное повторение: схема и карточки
• Трек Manual QA
• Трек QA Automation

Коротко

Частые вопросы