Вопросы на собеседовании QA с ответами

Вопросы на собеседовании junior QA повторяются от компании к компании. Ниже сорок штук с ответами — и, что важнее, с пояснением, что именно проверяют этим вопросом. Готовый ответ без понимания слышно сразу.

Теория тестирования

1. Что такое тестирование?
Проверка соответствия продукта требованиям и ожиданиям, чтобы дать команде информацию о качестве. Не «поиск багов» — поиск дефектов лишь одна из задач.

2. Чем отличаются ошибка, дефект и отказ?
Ошибка — действие человека (программист перепутал знак). Дефект — её след в коде или документации. Отказ — наблюдаемое неверное поведение, когда до дефекта дошло выполнение. Дефект может годами не давать отказа.

3. Почему нельзя протестировать всё?
Комбинаций входных данных, состояний и окружений бесконечно много. Отсюда приоритеты, риски и техники сокращения количества проверок.

4. Что такое верификация и валидация?
Верификация — делаем ли мы продукт правильно (соответствие спецификации). Валидация — делаем ли мы правильный продукт (решает ли он задачу пользователя).

5. Назовите принципы тестирования.
Тестирование показывает наличие дефектов, а не их отсутствие; исчерпывающее тестирование невозможно; раннее тестирование дешевле; дефекты скапливаются (правило Парето); парадокс пестицида — одни и те же тесты перестают находить новое; тестирование зависит от контекста; отсутствие ошибок — заблуждение, продукт может работать и быть при этом никому не нужен.

6. Уровни тестирования.
Модульное → интеграционное → системное → приёмочное.

7. Что такое пирамида тестирования?
Много быстрых модульных тестов внизу, меньше интеграционных, совсем немного медленных сквозных наверху. Перевёрнутая пирамида — долгий и хрупкий прогон.

8. Чем smoke отличается от регресса?
Smoke — быстрая проверка, что сборку вообще имеет смысл тестировать (10–15 проверок ключевых сценариев). Регресс — проверка, что новое не сломало старое, объёмный и обычно частично автоматизирован.

9. Что такое ретест?
Повторная проверка конкретного исправленного дефекта. Регресс — про соседний функционал, ретест — про сам дефект.

10. Позитивное и негативное тестирование.
Позитивное — система работает на корректных данных. Негативное — корректно отказывает на некорректных: понятная ошибка, ничего не сломалось, данные не потеряны.

11. Что такое статическое тестирование?
Проверка без запуска: ревью требований, макетов, кода. Самый дешёвый способ найти дефект — до того, как его написали.

12. Чем чёрный ящик отличается от белого?
Чёрный — тестируем по внешнему поведению, не зная устройства. Белый — зная код и структуру. Серый — частично: например, знаем схему базы и структуру API.

Техники и документация

13. Классы эквивалентности — зачем?
Значения, которые система обрабатывает одинаково, объединяем в класс и проверяем одно значение из класса. Вместо ста проверок — четыре, покрытие то же.

14. Граничные значения.
Ошибки живут на границах. Для диапазона 18–65 проверяем 17, 18, 65, 66 — именно там путают < и <=.

15. Попарное тестирование.
Большинство дефектов вызывает сочетание двух параметров, а не пяти. Вместо всех комбинаций берём набор, где каждая пара значений встречается хотя бы раз: было 96 комбинаций — стало 12.

16. Что такое таблица решений?
Способ разложить сложную логику «если — то» на условия и результаты. Хорошо показывает пропущенные и противоречивые правила в требованиях.

17. Чем чек-лист отличается от тест-кейса?
Чек-лист — список того, что проверить («корзина сохраняется после перезагрузки»). Тест-кейс — точные шаги, данные и ожидаемый результат, чтобы повторил любой. Чек-лист быстрее пишется, кейс — воспроизводимее.

18. Что обязательно в тест-кейсе?
Идентификатор, название, предусловия, шаги, данные, ожидаемый результат. Ожидаемый результат — со ссылкой на источник требования.

19. Что такое тест-план?
Документ о том, что тестируем и что не тестируем, как, кто, когда, на каких окружениях, какие критерии старта и завершения, какие риски.

20. Что такое критерии входа и выхода?
Условия начать тестирование (стенд поднят, сборка установлена, smoke пройден) и условия его закончить (все кейсы пройдены, критических дефектов нет).

Дефекты

21. Что входит в баг-репорт?
Заголовок, окружение, предусловия, шаги, ожидаемый и фактический результат, серьёзность, воспроизводимость, вложения. Готовая структура — в шаблоне баг-репорта.

22. Severity и Priority — в чём разница?
Severity — насколько сломано (ставит тестировщик), Priority — насколько срочно чинить (ставит продакт). Опечатка в названии компании на главной: severity Trivial, priority Highest. Падение раз в год на редком сценарии: severity Critical, priority Low.

23. Жизненный цикл дефекта.
New → Assigned → In Progress → Fixed → Retest → Closed. Ветки: Reopened, если не починили; Rejected, если это не дефект; Deferred, если отложили; Duplicate, если уже есть.

24. Дефект не воспроизводится. Ваши действия?
Уточнить окружение, версию сборки, данные и роль; проверить в инкогнито и другом браузере; посмотреть логи и записи по времени; попробовать по шагам того, кто нашёл. Если не удалось — закрыть с подробным описанием попыток, а не молча.

25. Разработчик говорит «так и задумано». Что делать?
Найти источник требования. Если требование говорит иначе — приложить ссылку. Если требования нет — это не спор, а вопрос к аналитику или продакту: дефект превращается в уточнение требований.

26. Нашли дефект на проде за час до релиза. Что делаете?
Оцениваю влияние: сколько пользователей, есть ли обходной путь, теряются ли деньги и данные. Сообщаю сразу с этой оценкой, а не «нашёл баг». Решение о переносе релиза принимает не тестировщик, но данные для решения даёт он.

Инструменты, API и SQL

27. Как посмотреть запрос из браузера?
DevTools → Network, фильтр Fetch/XHR, выбрать запрос: Headers, Payload, Response, Timing. Кнопка «Copy as cURL» повторяет запрос в терминале или Postman.

28. Что такое API?
Интерфейс, через который программы обмениваются данными. В вебе чаще всего HTTP + JSON: клиент шлёт запрос по адресу с методом и телом, получает код ответа и данные.

29. GET и POST — в чём разница?
GET читает и не меняет состояние, параметры в адресе, кэшируется, повторяем. POST создаёт или изменяет, данные в теле, не кэшируется, повторный вызов может создать дубль.

30. Что такое идемпотентность?
Повторный одинаковый запрос не меняет результат. GET, PUT, DELETE идемпотентны, POST — нет. Отсюда классический дефект: двойной клик создаёт два заказа.

31. Что означают коды 401, 403, 404, 500?
401 — не представились, 403 — представились, но нельзя, 404 — не найдено, 500 — упало на сервере. Полный список — в шпаргалке по кодам HTTP.

32. Чем cookie отличается от localStorage?
Cookie уходят на сервер с каждым запросом, имеют срок жизни и флаги (HttpOnly, Secure, SameSite). localStorage живёт только в браузере, объём больше, сам никуда не отправляется. sessionStorage — то же, но умирает с вкладкой.

33. Напишите запрос: найти дубли по e-mail.
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;

34. Чем INNER JOIN отличается от LEFT JOIN?
INNER оставляет только совпавшие пары, LEFT — все строки левой таблицы, подставляя NULL, где пары нет. LEFT JOIN + WHERE ... IS NULL находит записи-сироты.

35. Как проверить, что данные записались?
Пройти сценарий в интерфейсе и выполнить SELECT по нужной таблице; сверить поля с тем, что вводили; отдельно проверить расчётные поля — суммы и статусы.

36. Что такое Git и зачем он тестировщику?
Система контроля версий. Тестировщику нужна, чтобы понимать, какая версия на стенде, читать историю изменений и хранить свои автотесты и тестовую документацию.

О работе

37. С чего начнёте тестировать новую фичу?
Прочитаю требования и макеты, задам вопросы по неясным местам (это уже находит дефекты), составлю чек-лист от главного сценария к краям, уточню окружение и тестовые данные, начну с позитивного сценария и потом пойду по границам.

38. Требований нет. Что делаете?
Источники всё равно есть: макеты, поведение прошлой версии, аналоги, здравый смысл, устные договорённости. Составляю список предположений и иду с ним к аналитику или продакту — так пробелы в требованиях становятся видимыми.

39. Времени на тестирование дали в два раза меньше. Что делаете?
Расставляю приоритеты по риску: деньги, авторизация, потеря данных — в первую очередь; редкие сценарии и косметика — в последнюю. И честно сообщаю, что осталось непроверенным, чтобы решение принимала команда.

40. Почему вы идёте в тестирование?
Здесь нет правильного ответа, но есть проверяемый: расскажите, что уже сделали сами — прошли курс, разобрали чужое приложение, завели репорты, написали чек-лист. Конкретика убеждает сильнее слов «мне интересно качество».

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