Вопросы на собеседовании тестировщика с ответами
Открытая подборка для QA-интервью: от тест-дизайна и баг-репортов до API, SQL, автоматизации и приёмки изменений. Объясняйте решения через риск и наблюдаемое поведение, а не только через определения.
Python 3.12 для исполняемых примеров; HTTP и SQL проверяются на изолированных тестовых данных. Шкалы дефектов уточняются в конкретной команде.
Вопросы и ответы
Junior: основы
ОсновыЗачем нужно тестирование?
Тестирование даёт информацию о качестве и рисках продукта относительно конкретных требований и ожиданий пользователей. Оно помогает обнаруживать дефекты, проверять изменения и принимать решения о выпуске. Конечный набор проверок не доказывает отсутствие любых ошибок. Поэтому важно объяснять, что именно проверено, в каком окружении и какие риски остались. Качество результата зависит не от числа тест-кейсов, а от того, насколько проверки различают важные варианты поведения.
- Пример
- Перед выпуском оплаты проверяют успешный платёж, отказ, повтор callback и неопределённый результат.
- Частая ошибка
- Сообщать «всё работает», не называя проверенную область и ограничения.
- Уточнение интервьюера
- Как выбрать проверки, если до релиза осталось мало времени?
ОсновыЧем верификация отличается от валидации?
Верификация проверяет соответствие заданным требованиям или спецификации. Валидация оценивает, подходит ли продукт для предполагаемого использования. Эти вопросы связаны, но не совпадают: формально правильная реализация может решать не ту пользовательскую задачу. На практике полезно сочетать проверки контрактов с наблюдением реального сценария. Если требование неоднозначно, его сначала уточняют, а не превращают собственное предположение в единственный ожидаемый результат.
- Пример
- Форма может соблюдать макет, но быть непроходимой с клавиатуры для целевого пользователя.
- Частая ошибка
- Считать согласованный документ доказательством полезности любого реализованного поведения.
- Уточнение интервьюера
- Как зафиксировать обнаруженное противоречие требований?
Виды проверокЧем уровень тестирования отличается от вида?
Уровень описывает масштаб и границу проверяемой системы: компонент, взаимодействие компонентов, система или приёмочный сценарий. Вид описывает аспект качества, например функциональность, производительность или безопасность. Поэтому проверка API может относиться к разным уровням в зависимости от того, что реально подключено. Названия инструмента недостаточно: важно указать зависимости, окружение и наблюдаемый контракт.
- Пример
- HTTP-тест с подменённым сервисом не подтверждает реальную запись в production-подобную базу.
- Частая ошибка
- Называть любой тест через браузер полноценной проверкой всей системы.
- Уточнение интервьюера
- Чем контрактный тест дополняет интеграционный?
Тест-дизайнКак применять анализ граничных значений?
Сначала определите упорядоченную область и точные правила включения границ. Затем выберите значения на границе и непосредственно по обе стороны там, где они существуют. Для целых чисел это одни примеры, для времени и денежных сумм — другие. Проверка нужна и для представления данных: пустая строка, пробелы или дробь могут относиться к отдельным классам. Нельзя механически выбирать min−1 без понимания допустимого типа.
- Пример
- При возрасте от 18 до 65 включительно проверяют 17, 18, 19, 64, 65 и 66.
- Частая ошибка
- Проверять только 18 и 65, не подтверждая отклонение соседних недопустимых значений.
- Уточнение интервьюера
- Как изменится набор для даты окончания подписки?
Тест-дизайнЧто даёт разбиение на классы эквивалентности?
Метод объединяет входы, которые по выбранному правилу должны обрабатываться одинаково. Из каждого класса берут представителя, чтобы сократить повторяющиеся проверки. При этом классы являются моделью: ошибка в их построении может скрыть важный случай. Отдельно учитывают валидные и невалидные данные, а затем комбинируют подход с границами и взаимодействиями параметров. Все невалидные значения редко образуют один полезный класс.
- Пример
- Для количества товара классы могут включать допустимое целое, ноль, отрицательное, дробь и строку.
- Частая ошибка
- Выбрать одну неверную строку вместо анализа разных причин отказа.
- Уточнение интервьюера
- Когда два допустимых значения стоит проверить отдельно?
ДефектыЧто должно быть в воспроизводимом баг-репорте?
Укажите краткий симптом, окружение и версию, необходимые предусловия, последовательность действий, фактический и ожидаемый результат. Приложите минимальные данные, по которым ошибка воспроизводится, и безопасные логи или запись. Ожидаемое поведение связывайте с требованием либо ясно обозначенной договорённостью. Если ошибка нестабильная, полезны частота, время и признаки успешного и неуспешного запуска. Лишние секреты и персональные данные в отчёт не включают.
- Пример
- После повторного нажатия «Оплатить» создаются два заказа вместо одного — с указанием ID тестовых операций.
- Частая ошибка
- Писать «не работает» без версии, входных данных и результата.
- Уточнение интервьюера
- Как описать дефект, если воспроизведение пока не найдено?
ДефектыЧем severity отличается от priority?
Severity описывает влияние дефекта на систему или пользователя. Priority отражает очередность исправления с учётом бизнеса, сроков и распространённости. Они не обязаны совпадать: редкий серьёзный дефект может иметь иной порядок работы, чем заметная проблема текущей кампании. Шкалы зависят от команды, поэтому лучше объяснить последствия и условия возникновения, чем спорить только о слове critical. Итоговую приоритизацию согласуют с владельцами продукта.
- Пример
- Неверное имя бренда на главной может иметь высокий приоритет без аварийного воздействия на данные.
- Частая ошибка
- Использовать severity как способ заставить команду быстрее взять задачу.
- Уточнение интервьюера
- Какие данные помогут пересмотреть приоритет после релиза?
HTTPКак различать 400, 401, 403 и 404?
400 обычно означает некорректный запрос, 401 — необходимость подходящей аутентификации, 403 — отказ в доступе при обработке запроса, 404 — отсутствие доступного ресурса по адресу. Конкретный API может намеренно скрывать существование защищённого объекта через 404. Поэтому проверяют договорённый контракт, а не только популярную трактовку кода. Также важны тело, заголовки и отсутствие нежелательного побочного эффекта.
- Пример
- Запрос чужого документа не должен возвращать его содержимое даже если код ответа выглядит как ошибка.
- Частая ошибка
- Проверить только status и не заметить утечку данных в теле.
- Уточнение интервьюера
- Как тестировать доступ для анонима, владельца и другого пользователя?
Middle: применение
APIЧто проверять помимо HTTP-кода?
Проверяйте схему и типы полей, обязательность, значения, заголовки, состояние системы и ограничения доступа. Для мутации важно убедиться, что результат сохранён, а повтор не создал неожиданный дубль. Негативный ответ должен оставлять данные в согласованном состоянии. Для списков нужны порядок, пагинация и фильтры. Не следует фиксировать в тесте каждое необязательное поле, если контракт разрешает расширение ответа.
- Пример
- После создания заказа проверьте его чтение, владельца и отсутствие лишних списаний.
- Частая ошибка
- Считать любой 200 достаточным доказательством успешной бизнес-операции.
- Уточнение интервьюера
- Как тестировать совместимость API при добавлении новых полей?
SQLПочему COUNT(*) и COUNT(column) могут отличаться?
COUNT(*) считает строки результата, а COUNT(column) пропускает NULL в выбранном выражении. Это особенно заметно после LEFT JOIN: пользователь без заказов всё равно даёт одну строку соединения, но поле заказа в ней NULL. Чтобы посчитать реальные заказы, считают их ненулевой идентификатор. Также важно учитывать дубликаты, возникающие при соединении нескольких связей один-ко-многим. Ошибка агрегации может выглядеть как ошибка интерфейса, хотя источник находится в запросе.
- Пример
- У пользователя без заказов COUNT(order.id) равен нулю, а COUNT(*) после LEFT JOIN может быть равен одному.
- Частая ошибка
- Добавлять DISTINCT наугад вместо выяснения кардинальности соединений.
- Уточнение интервьюера
- Как проверить агрегацию для нуля, одного и нескольких заказов?
АрхитектураКак отделить ошибку клиента от ошибки сервера?
Проследите путь конкретной операции: пользовательский ввод, фактический сетевой запрос, ответ и его отображение. Сопоставьте время и идентификатор запроса с серверными логами, если доступно. Правильный ответ при неправильном отображении указывает на клиентский участок; неверный payload мог появиться до сервера. Прямой запрос к API помогает сузить область, но не заменяет сценарий браузера с cookies, redirect и политиками безопасности.
- Пример
- В интерфейсе ошибка загрузки может возникнуть потому, что вместо JSON BFF получил HTML авторизации.
- Частая ошибка
- Сразу назначать проблему backend по одному сообщению в браузере.
- Уточнение интервьюера
- Какие данные нужны для проверки ошибки только у части пользователей?
Тест-дизайнКогда нужна таблица решений?
Таблица полезна, когда результат зависит от сочетания условий. Сначала перечисляют условия и действия, затем определяют допустимые комбинации и ожидаемый результат каждой. Это помогает обнаружить пропущенные правила и противоречия. Для большого числа факторов не обязательно проверять все математические сочетания: можно исключить невозможные и применить риск-ориентированное сокращение. Однако такое сокращение нужно объяснить, а не считать автоматическим доказательством полного покрытия.
- Пример
- Доступ зависит от авторизации, срока подписки и остатка лимита; каждая комбинация должна иметь понятное решение.
- Частая ошибка
- Проверять каждый флаг отдельно и пропускать конфликт их сочетания.
- Уточнение интервьюера
- Когда pairwise недостаточно для критичного бизнес-правила?
Тест-дизайнКак тестировать состояния заказа?
Опишите разрешённые состояния, переходы, инициаторов и ограничения. Проверяйте не только успешную цепочку, но и запрещённые переходы, повторы события и изменение порядка доставки. У одного заказа может быть несколько технических представлений состояния, которые нужно согласовать. Для асинхронной обработки важно различать промежуточное состояние и окончательный отказ. Тест должен ждать осмысленного результата с ограниченным временем, а не случайную задержку.
- Пример
- Повтор уведомления paid не должен повторно начислять доступ, а старое pending не должно отменять уже подтверждённую оплату.
- Частая ошибка
- Проверять только путь created → paid без повторов и гонок.
- Уточнение интервьюера
- Как протестировать callback, пришедший раньше ответа checkout?
АвтоматизацияЧто автоматизировать в первую очередь?
Выбирайте повторяемые проверки важных контрактов, которые дают быстрый и понятный сигнал. Учитывайте стоимость подготовки данных, устойчивость окружения и цену сопровождения. Часто основной объём выгодно проверять ниже браузера, оставляя E2E для критичных связных сценариев. Автоматизация нестабильного требования может закрепить случайное поведение. Ручное исследование полезно для новых рисков, которые ещё не сформулированы как проверки.
- Пример
- Сначала проверить расчёт стоимости и повтор платежного события, затем визуальные детали редкой страницы.
- Частая ошибка
- Выбирать тесты только по тому, что легче записать рекордером.
- Уточнение интервьюера
- Как измерить пользу автоматизации кроме количества тестов?
Тестовые данныеКак сделать тесты независимыми?
Каждый тест должен получать понятные исходные данные и не зависеть от порядка запуска. Изоляцию обеспечивают отдельные записи, транзакции, временные каталоги или контролируемые сервисы — в зависимости от уровня теста. Уборка не должна удалять чужие данные. Случайные значения полезны только при возможности воспроизвести сбой. Глобальный общий аккаунт с меняющимся состоянием часто создаёт скрытые связи между тестами.
- Пример
- Параллельные тесты создают разные заказы и проверяют их по собственным ID.
- Частая ошибка
- Надеяться, что тест A всегда выполнится перед B и подготовит ему состояние.
- Уточнение интервьюера
- Когда транзакционный rollback не изолирует внешние эффекты?
Надёжность тестовКак разбирать нестабильный тест?
Сохраните доказательства падения и классифицируйте причину: гонка, нестабильная сеть, общие данные, время, порядок или ошибка продукта. Повторный запуск показывает частоту, но не исправляет источник. Ожидание должно быть связано с наблюдаемым состоянием и ограниченным таймаутом. Если тест обнаруживает реальную гонку приложения, её нельзя скрывать увеличением sleep. Полезно сравнить успешную и неуспешную трассу одного сценария.
- Пример
- После отправки формы ждут появления записи или статуса, а не просто две секунды.
- Частая ошибка
- Бесконечно добавлять retries, не анализируя первый отказ.
- Уточнение интервьюера
- Как отличить проблему теста от периодического дефекта продукта?
Senior: компромиссы и надёжность
СтратегияКак построить проверку рискованного изменения?
Определите, какие пользовательские операции и данные затронуты, какова цена отказа и насколько легко его обнаружить. Затем выберите проверки на изменённой границе, соседних интеграциях и критичных сценариях. Сохраните критерии отката и наблюдения после выпуска. Полный прогон старого набора может не покрыть новый риск, если в нём нет нужного состояния. Отчёт должен разделять выполненные проверки, известные ограничения и остаточный риск.
- Пример
- Изменение оплаты требует проверки повторов, конкурентных запросов и сохранения ранее выданного доступа.
- Частая ошибка
- Подменять анализ влияния фразой «все старые тесты зелёные».
- Уточнение интервьюера
- Какие проверки стоит выполнить после production deploy?
ПроизводительностьЧем нагрузочный тест отличается от проверки одного запроса?
Нагрузочная проверка задаёт профиль пользователей, интенсивность, длительность и данные. Она показывает распределение задержек, ошибки и использование ресурсов при совместной работе. Один быстрый запрос не доказывает устойчивость под нагрузкой. Важно учитывать разогрев, ограничение клиента нагрузки, фоновые задачи и насыщение внешних зависимостей. Порог успеха определяют заранее для конкретного сценария, а результаты сравнивают при сопоставимых условиях.
- Пример
- Среднее 200 мс может скрывать медленные ответы части пользователей; нужны перцентили и доля ошибок.
- Частая ошибка
- Повышать RPS, пока клиент сам стал узким местом, и приписывать результат серверу.
- Уточнение интервьюера
- Как отличить предел базы данных от предела приложения?
БезопасностьКак проверять разграничение доступа?
Составьте матрицу субъектов, ресурсов и действий: аноним, владелец, другой пользователь, роли поддержки и администратора. Для каждого действия проверьте серверный отказ, а не только отсутствие кнопки. Меняйте идентификаторы объектов и проверяйте списки, экспорт, вложения и побочные эффекты. Используйте разрешённое тестовое окружение и собственные данные. Разные маршруты к одному ресурсу должны соблюдать одинаковую политику.
- Пример
- Другой пользователь не должен прочитать документ по известному ID через прямой API-запрос.
- Частая ошибка
- Считать скрытую кнопку реализацией авторизации.
- Уточнение интервьюера
- Как убедиться, что отказ не раскрывает содержимое через дополнительные поля?
ПриёмкаКогда можно считать задачу проверенной?
Критерии готовности должны связывать требование, проверку и результат на конкретной версии. Отдельно фиксируйте локальный прогон, проверку интеграции и наблюдение после выпуска. Если часть сценария зависит от внешнего кабинета или оборудования, её нельзя помечать выполненной по косвенным признакам. Полезный итог позволяет следующему человеку повторить проверку и понять оставшиеся ограничения. Количество выполненных кейсов без контекста не заменяет доказательство.
- Пример
- Успешная загрузка конверсии в API ещё не подтверждает её привязку к визиту в отчёте аналитики.
- Частая ошибка
- Закрывать всю задачу после зелёного build, если приёмка включает внешнюю интеграцию.
- Уточнение интервьюера
- Как оформить блокер так, чтобы он не скрывал уже проверенную часть?
Практические задания
1. Спроектировать проверки формы
Форма принимает имя длиной 1–50 символов после trim и целый возраст 18–65 включительно. Составить классы, границы и негативные случаи.
Ожидаемый результат. Покрыты пустое имя, пробелы, длины 1/50/51, допустимые и соседние возраста, дробь и строка.
Решение и объяснение
Сначала фиксируем правила нормализации и типы. Затем проверяем каждую независимую причину отказа; отдельно — несколько ошибок одновременно и сохранение корректных полей.
def valid_profile(name, age):
return (
isinstance(name, str)
and 1 <= len(name.strip()) <= 50
and type(age) is int
and 18 <= age <= 65
)
assert valid_profile('Анна', 18)
assert valid_profile('x' * 50, 65)
assert not valid_profile(' ', 30)
assert not valid_profile('x' * 51, 30)
assert not valid_profile('Анна', 17)
assert not valid_profile('Анна', 66)
assert not valid_profile('Анна', 18.5)
assert not valid_profile('Анна', True)2. Проверить контракт API создания
API создаёт задачу с title длиной 1–100 и возвращает 201 с id и title. Невалидный title даёт 422 и не создаёт запись. Составить автоматические проверки на тестовом сервисе.
Ожидаемый результат. Проверены статус, Content-Type, форма ответа, чтение созданного объекта, отказ и отсутствие побочного эффекта.
Решение и объяснение
Используйте отдельный объект для каждого теста. В негативном сценарии сравните состояние до и после. Повтор операции тестируется отдельно, только если контракт задаёт идемпотентность. Пример — каркас проверок для клиента вашего тестового сервиса.
def check_created(response, read_by_id):
assert response.status_code == 201
assert response.headers['content-type'].startswith('application/json')
data = response.json()
assert isinstance(data['id'], str) and data['id']
assert data['title'] == 'Проверить контракт'
assert read_by_id(data['id'])['title'] == data['title']3. Найти пользователей без заказов
Есть users(id, name) и orders(id, user_id). Получить всех пользователей с количеством заказов, включая ноль.
Ожидаемый результат. Для трёх пользователей с 0, 1 и 2 заказами результат содержит ровно три строки с соответствующими числами.
Решение и объяснение
LEFT JOIN сохраняет пользователя без заказов. COUNT(o.id) не считает NULL правой стороны. Группируем по идентификатору и имени, чтобы запрос был явным и переносимым.
SELECT u.id, u.name, COUNT(o.id) AS order_count
FROM users AS u
LEFT JOIN orders AS o ON o.user_id = u.id
GROUP BY u.id, u.name
ORDER BY u.id;План подготовки на семь дней
- Выпишите требования вакансии и отметьте знакомые и незнакомые темы.
- Ответьте на вопросы Junior вслух, затем проверьте себя по объяснениям.
- Разберите вопросы Middle. Для каждой ошибки запишите свой небольшой пример.
- Решите практические задания без подсказок и проверьте граничные случаи.
- Разберите вопросы Senior и объясните компромиссы применительно к своему проекту.
- Проведите пробное интервью: уточняйте условия, рассуждайте и проверяйте выводы.
- Повторите ошибки, подготовьте реальные истории опыта и проверьте технику.