В основе материала — 13 вопросов, которые автор связывает с собеседованием QA-тестировщика в Сбере. Это не полная запись диалога: в исходном ролике собраны сами вопросы и подготовленные ответы. Мы проверили формулировки по документации и превратили подборку в самостоятельный конспект без личных данных участников.
Верификация, валидация и уровни тестирования
Вопрос: чем верификация отличается от валидации?
Ответ: верификация проверяет соответствие заданным требованиям. Валидация проверяет, подходит ли продукт для предполагаемого использования и решает ли задачу пользователя. Например, форма может точно соответствовать макету и техническому заданию, но оставаться неудобной на телефоне. Формально верификация пройдена, а при валидации обнаружится проблема.
Вопрос: какие бывают уровни тестирования?
В актуальной программе ISTQB Foundation Level выделены компонентное тестирование, компонентная интеграция, системное тестирование, системная интеграция и приёмочное тестирование. Уровень говорит не о том, «насколько тщательно» тестируют, а какой объект и какие взаимодействия находятся в фокусе.
На интервью полезно дать определение, затем привести один сквозной пример: функция расчёта проверяется как компонент, связь сервиса оплаты с заказом — на интеграции, весь пользовательский путь — на системном уровне, а бизнес-сценарий приёмки — вместе с заказчиком.
Статическое и динамическое тестирование, тестовый процесс
Вопрос: чем статическое тестирование отличается от динамического?
При статическом тестировании программу не запускают: команда рецензирует требования и код, применяет статический анализ. Так можно найти неоднозначность требования ещё до разработки. При динамическом тестировании код выполняется, а специалист сравнивает фактическое поведение с ожидаемым.
Вопрос: что такое STLC?
Лучше не произносить выученный список как единственно возможный. Названия этапов зависят от процесса команды. В программе ISTQB тестовая работа описана через планирование, мониторинг и контроль, анализ, проектирование, реализацию, выполнение и завершение. Действия могут идти не строго по очереди и повторяться на каждой итерации.
Хороший ответ показывает связь: требования дают основу для условий тестирования, из них появляются тесты и данные, выполнение даёт фактические результаты, а завершение — вывод о качестве и незакрытых рисках.
Эквивалентные классы и поле со значениями от 1 до 10
Вопрос: как протестировать поле, принимающее целые числа от 1 до 10?
Сначала уточняем контракт: обязательное ли поле, разрешён ли ручной ввод, как обрабатываются пробелы, знак и вставка из буфера. Затем делим данные на классы, внутри которых ожидаем одинаковое поведение. Для допустимых целых это 1…10, для слишком маленьких — всё меньше 1, для слишком больших — всё больше 10. После этого проверяем границы.
| Проверка | Пример | Ожидаемый результат |
|---|---|---|
| Нижняя граница | 0, 1, 2 |
0 отклонён, 1 и 2 приняты |
| Верхняя граница | 9, 10, 11 |
9 и 10 приняты, 11 отклонён |
| Значение внутри | 5 |
Принято |
| Неверный формат | 1.5, текст, пробелы |
Обработка по контракту без падения |
| Нет значения | Пустое поле | Понятная ошибка, если поле обязательно |
| Необычный ввод | +1, очень длинное число, вставка |
Без обхода ограничений и поломки интерфейса |
Такой набор сильнее фразы «проверю от 1 до 10»: он показывает технику тест-дизайна и внимание к интерфейсу.
REST, HTTP и JSON без смешения понятий
Вопрос: что такое REST API?
REST — архитектурный стиль. В диссертации Роя Филдинга описаны ограничения client-server, stateless, cache, uniform interface, layered system и необязательное code-on-demand. Поэтому ответ «REST — это HTTP с JSON» неверен: HTTP часто используют для REST API, а JSON часто выбирают как формат данных, но это разные уровни системы. Первичный источник — работа Филдинга.
Вопрос: из чего состоит HTTP-запрос и как клиент узнаёт формат ответа?
У запроса есть метод, адрес цели, заголовки и, когда нужно, содержимое. У ответа — статус, заголовки и возможное содержимое. Заголовок Content-Type описывает медиатип переданных данных: например, application/json. Это закреплено в HTTP Semantics, RFC 9110.
Важно уточнить: заголовок сам по себе не превращает строку в объект приложения. Клиентская библиотека или код должны прочитать ответ и разобрать JSON, а при ошибке формата — обработать исключение.
COUNT и внешние JOIN в SQL
Вопрос: чем COUNT(1) отличается от COUNT(*)?
В PostgreSQL COUNT(*) считает входные строки, а COUNT(выражение) — строки, где выражение не равно NULL. Константа 1 всегда ненулевая, поэтому COUNT(1) и COUNT(*) возвращают одно число. А COUNT(email) пропустит строки с NULL в email. Это напрямую следует из документации PostgreSQL.
Не стоит обещать одинаковую скорость во всех базах данных. Если интервьюер спрашивает о производительности, корректный следующий шаг — назвать конкретную СУБД и посмотреть план выполнения.
Вопрос: чем LEFT JOIN отличается от RIGHT JOIN?
LEFT JOIN сохраняет все строки левой таблицы и подставляет NULL, если справа пары нет. RIGHT JOIN делает то же относительно правой таблицы. Их часто можно переписать друг через друга, поменяв таблицы местами. На практике важнее не направление в названии, а точное понимание, какие строки обязаны остаться в результате.
Белый экран: как локализовать дефект
Вопрос: на сайте появился белый экран. Что делать?
Мы советуем идти от наблюдаемого симптома к доказательствам:
- Повторить сценарий и записать окружение: адрес, пользователь, браузер, время, входные данные.
- Открыть Console и проверить ошибки JavaScript.
- В Network найти неуспешные, зависшие или неожиданные запросы.
- Сопоставить запрос, статус и тело ответа с контрактом API.
- Проверить DOM и состояние приложения: данные могли прийти, но компонент не отрисовался.
- Сравнить другой браузер, чистую сессию, кеш, флаги и права пользователя.
Статус 500 указывает, что серверная сторона не смогла обработать запрос, но не называет корневую причину: она может быть в самом сервисе, шлюзе или зависимом компоненте. Задача QA — приложить факты, а не назначить виноватого по одному коду.
Ответ 200 и пустое тело: один баг или два
Вопрос: в логах ответ 200, но тело пустое и интерфейс сломан. На кого заводить дефект?
Сначала смотрим контракт. Если API обязан вернуть объект, но отдаёт пустое содержимое со статусом успеха, это нарушение на стороне API. Если фронтенд из-за пустого ответа падает в белый экран вместо понятного пустого или ошибочного состояния, у интерфейса тоже есть проблема устойчивости.
Иногда это один дефект с согласованным владельцем, иногда — два связанных тикета. Решение зависит от устройства команд и критериев учёта. В отчёте важнее зафиксировать ожидаемое и фактическое поведение, запрос, ответ, время, окружение и связь между симптомами.
Получил ли кандидат оффер
В доступном материале нет полных ответов кандидата и решения работодателя. Поэтому честный вывод — данных недостаточно. Мы можем оценить только программу интервью: она проверяет базовую теорию QA, тест-дизайн, API, SQL и умение локализовать сбой.
Кандидат выглядит сильнее, если не угадывает «правильную команду», а спокойно уточняет контракт, приводит пример и отделяет наблюдение от гипотезы. Именно этот навык стоит тренировать вслух. В тренажёре собеседований ЮНИКОД можно пройти вопросы по своему направлению, увидеть пробелы и повторить темы до живого интервью.
Источники
- ISTQB: Certified Tester Foundation Level 4.0 — уровни, виды и процесс тестирования.
- Roy Fielding: Architectural Styles and the Design of Network-based Software Architectures — ограничения REST.
- RFC 9110: HTTP Semantics — устройство HTTP-сообщений и значение Content-Type.
- PostgreSQL: Aggregate Functions — семантика COUNT.
частые вопросы
Короткие ответы
Какие темы повторить перед собеседованием QA-тестировщика?
Повторите базовую теорию тестирования, техники тест-дизайна, устройство HTTP и REST API, чтение логов и простые SQL-запросы. Важно не только знать определения, но и показать ход проверки на конкретном примере.
Чем верификация отличается от валидации?
Верификация отвечает на вопрос, соответствует ли продукт заданным требованиям. Валидация показывает, решает ли готовый продукт реальную задачу пользователя в предполагаемых условиях применения.
COUNT(1) и COUNT(*) дают одинаковый результат?
В PostgreSQL COUNT(*) считает строки, а COUNT(1) — строки, где константа 1 не равна NULL, поэтому результат одинаков. Сравнивать скорость без указания СУБД и плана выполнения некорректно.
Можно ли определить виноватую команду только по коду ответа API?
Нет. Код и тело ответа дают направление, но нужны контракт API, логи, запрос, данные и ожидаемое поведение интерфейса. Иногда один сценарий обнаруживает два разных дефекта.
