Вопросы на собеседовании QA-инженера

Пример сильного ответа

Классы эквивалентности — это разбиение входных данных на группы, внутри которых поведение системы одинаково, поэтому достаточно проверить по одному значению из группы. Граничные значения — проверка на краях диапазона и рядом с ними: именно там чаще всего прячутся ошибки. Для поля «возраст от 18 до 65» выделяются три класса: меньше 18 — невалидный, от 18 до 65 — валидный, больше 65 — невалидный. По границам проверяю 17, 18, 19 и 64, 65, 66, плюс значения не по типу: пустое поле, буквы, дробное число, очень большое число. Такой набор из примерно 10 проверок закрывает и логику, и валидацию ввода, и ни одна ветка не остаётся непроверенной.

• Оба понятия объяснены своими словами, без заученных формулировок
• Пример разобран по классам и по границам диапазона
• Добавлены проверки не по типу — видна практическая глубина

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Верификация отвечает на вопрос «сделали ли мы продукт правильно» — соответствует ли он требованиям и техническому заданию. Валидация — «тот ли продукт мы сделали»: решает ли он задачу пользователя в реальных условиях. То есть верификация — проверки против документации и дизайна, валидация — против реального сценария использования. Форма сохраняет заявку по всем требованиям — это верификация; а удобно ли пользователю её заполнить и не теряет ли он данные при обрыве связи — валидация. Важно закрывать обе стороны, иначе продукт может быть формально корректным, но бесполезным. У меня был случай: все проверки по требованиям проходили, а на реальном пользователе выяснилось, что длинный сценарий из 5 шагов никто не проходит до конца, и логику пришлось менять вместе с продуктом.

• Различие дано через два простых вопроса-формулы
• Есть практический пример из собственного опыта
• Показано, зачем нужны обе стороны проверки

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Хороший тест-кейс самостоятелен: по нему может пройти любой человек из команды и получить тот же результат. Поэтому в нём есть идентификатор и понятное название, привязка к требованию или задаче, предусловия и тестовые данные, пошаговые действия и ожидаемый результат для каждого шага, а также пост-условия и среда, где проверка выполняется. Ещё важны приоритет, тип проверки — функциональная, регресс, интеграционная — и признак автоматизации. У меня в наборах действует правило: один кейс проверяет одну вещь, иначе падение не показывает, что именно сломалось. После ревью набор стал компактнее примерно на 20%, а время прогона регресса сократилось, потому что дубли и неоднозначные формулировки ушли.

• Перечислены ключевые атрибуты тест-кейса без лишнего
• Есть своё правило: один кейс — одна проверка
• Подкреплено цифрой: набор компактнее примерно на 20%

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Классы эквивалентности — база, но ими не ограничиваюсь. Использую анализ граничных значений: проверяю значения на границах и рядом с ними. Таблицы решений — когда логика зависит от комбинации условий, например скидка зависит от суммы и статуса клиента. Ещё в ходу попарное тестирование, диаграммы состояний и переходов для жизненных циклов заказа, причинно-следственный анализ, сценарии использования. На одном проекте таблица решений помогла сократить число кейсов по расчёту доставки примерно на 40% без потери покрытия. Выбор техники зависит от того, что именно проверяем: данные, логику или последовательность событий.

• Показана широта инструментов, а не один приём
• Есть пример с измеримым эффектом
• Объяснён критерий выбора техники

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Попарное тестирование, или pairwise, — это способ сократить число комбинаций параметров: вместо полного перебора проверяются пары значений, чтобы каждая пара встретилась хотя бы один раз. Применяю, когда параметров много, а баги чаще возникают именно на взаимодействии двух факторов, а не трёх-четырёх. Классический пример — матрица конфигураций: браузер, версия системы, язык, тип оплаты. На последнем проекте полный перебор давал около тысячи комбинаций, а попарный набор — порядка шестидесяти, при этом критичных дефектов по взаимодействиям параметров не пропустили. Не применяю там, где важна связка трёх и более условий.

• Дано определение своими словами, без заучивания
• Есть критерий применимости и антипример
• Подтверждено цифрами из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Severity — это влияние дефекта на работу системы, priority — насколько срочно его исправить с точки зрения бизнеса. Они не всегда совпадают. Пример: опечатка в названии банка в печатной форме договора — severity низкая, а priority высокий, потому что документ уходит клиенту. Обратный случай: падение приложения при выборе экзотической валюты в редком регионе — severity высокая, а priority низкий, сценарий почти не используется. В моей практике примерно каждый пятый дефект из двухсот имел такое расхождение, и расстановку приоритетов приходилось защищать перед продукт-менеджером.

• Разведены два разных понятия
• Два примера показывают оба расхождения
• Есть личный опыт и конкретная цифра

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Качественный баг-репорт — это воспроизводимый сценарий, а не пересказ эмоций. В нём есть заголовок с сутью проблемы, окружение и версия сборки, шаги воспроизведения, ожидаемый и фактический результат, вложения — скриншоты, логи, видео, а также severity, priority и привязка к требованию. Обязательно указываю, воспроизводится ли дефект стабильно: например, из десяти попыток — восемь. Ещё фиксирую тестовые данные и стенд, чтобы разработчик не тратил время на переписку. На моей практике детальные отчёты с логами сократили возвраты с формулировкой «не воспроизводится» примерно на треть.

• Перечислены обязательные элементы отчёта
• Подчёркнута воспроизводимость и данные
• Есть измеримый эффект от практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Цикл обычно такой: обнаружение, создание отчёта, ревью и приоритизация, назначение на разработчика, исправление, проверка на сборке, регресс, закрытие. Бывают развилки: «отклонён» — если это не дефект или дубликат, «отложен» — если решают выпустить позже, «переоткрыт» — если исправление не подтвердилось. Моя роль — не просто завести тикет, а держать статусы актуальными и проверять фикс на той же сборке, где дефект найден. В среднем очередь из 40-50 открытых дефектов удавалось держать в актуальном состоянии, а доля переоткрытых не превышала десяти процентов.

• Показан полный цикл и типовые развилки
• Уточнена реальная роль тестировщика
• Есть метрики, которыми можно управлять

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Чек-лист — это перечень проверок без детальных шагов, а тест-кейс — с конкретными шагами, тестовыми данными и ожидаемым результатом. Чек-лист быстрее поддерживать и легко менять, тест-кейс нужен там, где важна повторяемость, передача задачи новому человеку и аудит. Чек-листа достаточно, когда регресс прогоняет опытный тестировщик, когда нужна быстрая проверка сборки или фича часто меняется. В моей практике чек-лист из 40 пунктов по критичным сценариям закрывал регресс перед релизом примерно за два часа, а детальные тест-кейсы я держу только для самых сложных и рискованных мест.

• Показано чёткое различие по формату и цели
• Названы критерии выбора инструмента
• Есть личный пример с цифрами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Тест-план — это документ, который описывает, что, как, чем и за какое время планируется проверить и кто за это отвечает. Обычно в нём есть цели и объём тестирования — что входит и что осознанно не входит, виды и уровни тестирования, окружения и тестовые данные, критерии начала и завершения, роли и ответственность, расписание, риски и способы их снижения, порядок отчётности и разбора дефектов. В моей практике тест-план по крупной интеграции занимал две страницы текста плюс таблица на 80 проверок — этого хватало, чтобы вся команда из пяти человек понимала границы работ.

• Перечислены ключевые разделы документа
• Отмечена граница объёма работ
• Есть пример объёма из опыта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Если требований нет, я начинаю с восстановления ожидаемого поведения: смотрю, как работает система сейчас, изучаю аналоги, документацию к API, схему данных и логи, общаюсь с аналитиком, разработчиком и поддержкой. Все неясные места выношу в список вопросов и фиксирую допущения, чтобы они не всплыли на приёмке. Дальше строю карту функциональности и чек-лист от критичных сценариев к редким: границы, негативные кейсы, права доступа, целостность данных. На проекте без описания требований такой подход дал чек-лист на 60 проверок и больше десяти вопросов к команде, половина из которых закрылась правками до релиза.

• Видна системная работа с неопределённостью
• Упомянуты коммуникация и фиксация допущений
• Есть измеримый результат по итогам

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Исследовательское тестирование — это управляемое изучение продукта без заранее прописанных шагов: есть чартер с целью и областью, ограниченная по времени сессия, заметки и короткий разбор в конце. Оно эффективнее сценарного там, где требования неполные, где фича новая или сложная, где нужно быстро найти неочевидные дефекты и понять, как система ведёт себя на границах и при нестандартных действиях. Сценарные прогоны лучше для регресса и повторяемости, исследовательские — для поиска неизвестных рисков. Обычно я выделяю сессии по 60–90 минут: за серию таких сессий по новому модулю удавалось найти порядка пятнадцати дефектов, которые не ловились готовыми кейсами.

• Дано корректное определение через сессии
• Сравнение со сценарным подходом по ситуации
• Подтверждено результатом из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В Postman я смотрю не только статус-код, а весь контракт целиком. Проверяю тело ответа: структуру, типы полей, обязательные и необязательные поля, значения и их соответствие ожиданиям, заголовки и тип контента, кэширование. Отдельно — бизнес-логику: изменился ли статус объекта, пересчитались ли связанные значения, нет ли побочных эффектов при повторном запросе, идемпотентность. Обязательно авторизация: запрос без токена, с чужим токеном и с просроченным. Плюс негативные кейсы: пустые и неверных типов поля, границы, слишком длинные строки. И время ответа. В коллекции на 120 запросов я держу тесты уровня ответа и проверку состояния через отдельные GET.

• Перечислены проверки за пределами статус-кода
• Отдельно выделены авторизация и бизнес-логика
• Есть конкретика по объёму коллекции

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей практике тестирование API — это ежедневная работа. Я проверяю основные методы: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Для каждого важна семантика: GET — безопасный и идемпотентный, POST — создание, PUT — полная замена, PATCH — частичное изменение, DELETE — удаление. Коды ответов делю на группы: 2xx — успех (200, 201, 204), 3xx — редиректы (301, 304), 4xx — ошибки клиента (400, 401, 403, 404, 409, 422, 429), 5xx — ошибки сервера (500, 502, 503). На моём проекте чек-лист покрывает 7 методов и 40 кодов ответов, что помогает находить несоответствия до релиза.

• Показывает знание методов и кодов
• Приводит конкретные цифры из практики
• Демонстрирует системный подход к проверкам

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Запрос строю от группировки: SELECT u.id, u.name FROM users u JOIN orders o ON o.user_id = u.id GROUP BY u.id, u.name HAVING COUNT(o.id) > 3. Ключевой момент — фильтр по агрегату идёт в HAVING, а не в WHERE, иначе количество ещё не посчитано и запрос просто не выполнится. Если нужны и пользователи без заказов, беру LEFT JOIN и считаю COUNT(o.id), потому что COUNT(*) посчитает и пустую строку. В работе такой запрос помогал сверять данные интерфейса с базой: в одном релизе расхождение обнаружилось у 12 пользователей из выборки, и причиной оказался дефект кэша.

• Видно понимание HAVING против WHERE — частая ошибка
• Запрос рабочий и легко проверяется на месте
• Есть связь с реальной сверкой интерфейса и базы

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

INNER JOIN возвращает только те строки, где есть совпадение в обеих таблицах, а LEFT JOIN берёт все строки из левой таблицы и подставляет совпадения из правой, а где их нет — NULL. На практике это критично для проверок. Например, при тестировании заказов и оплат: мне нужно убедиться, что каждый заказ имеет платёж. Если строить выборку через INNER JOIN, заказы без оплаты просто исчезают из результата, и баг легко пропустить. Я использую LEFT JOIN и фильтр по NULL: так на выборке в 50 тысяч заказов видны 120 заказов без платежа — по ним и завели дефект. Такая проверка стала регулярной и закрыла слепую зону в регрессии.

• Простыми словами объясняет разницу двух типов join.
• Пример из тестирования показывает практику, а не теорию.
• Есть цифры: 50 тысяч заказов и 120 дефектных записей.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Через интерфейс видно только то, что решил показать интерфейс, а база — источник правды. Моя задача была убедиться, что операция не просто отрисовалась, а действительно сохранилась корректно: в нужной таблице, с нужными типами, без дублей и мусорных записей. Классический пример: заказ создаётся, всплывающее уведомление об успехе появляется, а в связанной таблице статуса нет или сумма округлена не так. Ещё проверяю транзакционность и откат при ошибке. В одном релизе сверка через базу выявила 15 осиротевших записей без родительской сущности, которые через интерфейс были не видны.

• Подчёркивает базу как источник правды
• Есть проверка транзакций и целостности данных
• Пример дефекта, который интерфейс скрывает

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Даже если автоматизацию пишут коллеги, мне важно понимать её устройство. Как минимум — пирамиду тестов: много быстрых проверок на уровне модулей, меньше на уровне API и совсем немного UI, потому что UI-тесты самые хрупкие и медленные. Мне полезно читать код тестов и отчёты, ставить метки, разбираться, почему прогон красный: это настоящий дефект или упавший локатор. Ещё важно формулировать проверки так, чтобы они были стабильными и независимыми друг от друга. В моей практике после чистки нестабильных тестов время прогона сократилось примерно с двух часов до сорока минут.

• Демонстрирует понимание пирамиды тестов
• Показывает пользу от чтения отчётов и логов
• Подтверждает пользу конкретной цифрой из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

На такую форму у меня обычно уходит около 45 проверок, и я раскладываю их по группам. Позитив: валидный email и пароль, регистрация проходит, приходит письмо подтверждения, пользователь может войти. Формат email: без собаки, без домена, лишние пробелы, заглавные буквы, юникод, очень длинная строка, вставка из буфера. Пароль: минимальная и максимальная длина, границы, только пробелы, цифры, спецсимволы, разные регистры. Негатив: пустые поля, дубликат email, уже занятый логин, обрыв сети при отправке, двойной клик по кнопке. Отдельно — безопасность: SQL-инъекции, XSS, перебор, и юзабилити: сообщения об ошибках, фокус, автозаполнение, мобильная клавиатура.

• Показана структура: позитив, негатив, границы, безопасность
• Есть конкретный объём — около 45 проверок
• Упомянуты юзабилити и мобильные сценарии

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом собираю факты, а не гипотезы: id заказов, время, устройство, версия приложения и канал, где заказ пропадает. Прошу поддержку вытащить логи и метрики за сутки по этим заказам. Дальше строю гипотезы: обрыв сети в момент подтверждения, повторная отправка, таймаут платёжного шлюза, гонка при параллельных запросах. Проверяю их эмуляцией плохой сети, отключением связи на разных шагах и нагрузочным прогоном. Если воспроизведение не даётся, добавляю логирование в подозрительный участок и оставляю баг с подробным описанием. В похожем случае причину удалось найти за три дня, разобрав 12 обращений.

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

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Самый серьёзный дефект в моей практике — потеря платежей при повторной отправке формы. Ситуация: перед релизом новой оплаты в логах тестовой среды я замечаю, что при двойном нажатии кнопки создаётся два заказа, а списание проходит один раз. Задача — понять масштаб и причину. Прогоняю сценарий через нагрузку и вижу, что проблема стабильно воспроизводится на медленной сети. Результат: релиз ставлю на паузу, разработка добавляет защиту от повторных запросов, а в регресс уходит отдельная проверка. По нашим метрикам, на проде это затронуло бы около 4 процентов заказов в сутки.

• Ясная структура STAR и понятная бизнес-ценность
• Конкретные цифры: двойная отправка, 4 процента
• Показано влияние находки на решение о релизе

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Ситуация: на финальной неделе перед релизом я нахожу дефект в расчёте скидки — при комбинации промокода и акции итоговая сумма уходила в минус. Задача — оценить риск и дать бизнесу основание для решения. Собираю данные: сколько сценариев затронуто, есть ли обходной путь, как быстро ставится фикс. Показываю на трёх примерах, как пользователь получает бесплатный заказ, и прикидываю потери на объёме в 2 000 заказов в день. Релиз переносим на четыре дня, проверку добавляем в регресс. Обоснование строю на деньгах и рисках, а не на эмоциях.

• Обоснование через деньги и риск, а не эмоции
• Есть оценка срока фикса и обходного пути
• Показано, как решение принималось вместе с бизнесом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Приоритеты расставляю по риску: смотрю, что чаще всего используется, что связано с деньгами, данными и безопасностью, и где цена ошибки выше. Дальше взвешиваю вероятность и влияние дефекта. Сначала обязательное: критичные бизнес-сценарии, оплата, регистрация, авторизация, миграции данных. Потом регресс вокруг изменений и автотесты. Косметику и редкие кейсы выношу в отдельный список и честно показываю его менеджеру: что не успеваю проверить и какие риски это несёт. Помогают таймбоксы: на смоук — час, на регресс — день, остальное — по остаточному времени.

• Прозрачный критерий приоритета — риск и влияние
• Есть диалог с менеджером о непокрытых рисках
• Таймбоксы и порядок проверок звучат практично

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.