Вопросы на собеседовании QA Engineer: 40 вопросов и ответов для Junior-тестировщика
Короткий ответ: на собеседовании Junior QA проверяют четыре вещи — знаете ли вы теорию тестирования в терминах ISTQB, умеете ли применять техники тест-дизайна на живом примере, можете ли понятно оформить баг-репорт и ориентируетесь ли в технической базе: HTTP, API, SQL, DevTools. В этой статье 40 вопросов с короткими ответами, сгруппированные по семи темам, пять практических задач с решениями, типичные ошибки кандидатов и план подготовки на две недели.
Я четыре года работала QA Engineer, а сейчас как Project Delivery Manager отвечаю за delivery проектов и вижу тестирование с другой стороны: какие навыки тестировщика действительно помогают команде выпустить продукт. Вопросы ниже я отбирала с этой точки зрения и с учётом работы над курсами по QA. Почти в каждом ответе важнее не определение, а пример, которым вы его подтверждаете.
Определения даны по смыслу глоссария ISTQB и программы Certified Tester Foundation Level v4.0. SQL-запросы выполнены в SQLite 3.51, пример на JavaScript — в Node.js 22, автотест — в Playwright 1.59; вывод в статье настоящий. Подборка вопросов — авторский отбор на основе опыта работы в тестировании, а не статистика: в конкретной компании список может отличаться.
Как проходит собеседование на QA Engineer?
Обычно собеседование на Junior QA состоит из четырёх этапов: скрининг с рекрутером, техническое интервью, практическое задание и финальная встреча с руководителем или командой. Порядок и количество этапов зависят от компании: в небольших командах всё может уместиться в один разговор.
| Этап | Что проверяют | Как готовиться |
|---|---|---|
| Скрининг с рекрутером | Мотивацию, английский, ожидания по зарплате и формату работы, общее понимание профессии | Подготовьте рассказ о себе на две минуты, ответ «почему тестирование» и вилку ожиданий |
| Техническое интервью | Теорию, тест-дизайн, документацию, HTTP и API, SQL, иногда основы автоматизации | Повторите вопросы из этой статьи и к каждому определению подберите свой пример |
| Практическое задание | Умение протестировать объект или требование, написать тест-кейсы, оформить баг-репорт, составить SQL-запрос | Решите задачи из раздела с практикой письменно и с таймером |
| Финальная встреча | Как вы общаетесь, реагируете на спорные ситуации, вписываетесь ли в команду | Вспомните ситуации из учёбы или прошлой работы: конфликт, ошибка, сжатые сроки |
Если вы только присматриваетесь к профессии, начните с обзора что такое QA и статьи QA Engineer в эпоху AI. Медианные зарплаты по уровням собраны на странице зарплаты QA Engineer.
Какие темы спрашивают и на каком уровне?
Junior спрашивают прежде всего теорию, тест-дизайн, документацию и техническую базу; с Middle глубже обсуждают процессы, планирование, API и автоматизацию. Таблица показывает, что именно проверяют в каждой теме. Отметка уровня — ориентир автора, а не стандарт.
| Тема | Что проверяют | Уровень |
|---|---|---|
| Теория тестирования | Термины ISTQB, принципы, уровни и типы тестирования | Junior |
| Техники тест-дизайна | Умение применить технику к конкретному полю или требованию | Junior |
| Тестовая документация | Тест-кейс, чек-лист, баг-репорт, severity и priority | Junior |
| Тест-план, оценка, критерии завершения | Умение спланировать тестирование и объяснить, что не будет проверено | Middle |
| Процессы | Жизненный цикл разработки, роль тестировщика в Scrum-команде | Junior / Middle |
| Веб и клиент-сервер | HTTP-методы, коды ответов, cookies, DevTools | Junior |
| Тестирование API | REST, Postman, проверки ответа, негативные сценарии | Junior / Middle |
| SQL | SELECT, JOIN, GROUP BY | Junior |
| Мобильное тестирование | Специфика мобильных приложений, устройства и эмуляторы | Junior / Middle |
| Автоматизация | Что автоматизировать, пирамида тестирования, инструменты на уровне концепций | Junior — концепции, Middle — практика |
| AI-инструменты | Где ассистент помогает и как вы проверяете его результат | Junior / Middle |
Теория тестирования
Определения в этом блоке следуют глоссарию ISTQB. Учить их дословно не нужно, но смысл должен совпадать: интервьюер, как правило, сверяет ответ именно с ним.
Чем отличаются QA, QC и тестирование?
QA (обеспечение качества) — это работа над процессом, чтобы дефекты не появлялись; QC (контроль качества) — проверка готового продукта; тестирование — одна из форм контроля качества. В программе ISTQB это сформулировано так: QA — процессно-ориентированный, предупреждающий подход, QC — продукт-ориентированный, корректирующий.
Пример: договориться, что каждое требование проходит ревью до начала разработки, — это QA. Проверить собранную версию и найти, что кнопка оплаты не работает, — QC, и конкретно тестирование. Должность при этом обычно называется QA Engineer, хотя большая часть ежедневной работы — тестирование. Подробнее — в глоссарии: тестирование программного обеспечения.
В чём разница между верификацией и валидацией?
Верификация отвечает на вопрос «соответствует ли продукт спецификации?», валидация — «соответствует ли он потребностям пользователя и заказчика?». Короткая формула: верификация — «делаем продукт правильно», валидация — «делаем правильный продукт».
Пример: в требовании написано, что пароль содержит не менее 8 символов. Вы проверили, что 7 символов не принимаются, — это верификация. Пользователи на приёмочном тестировании не могут найти кнопку «Показать пароль» и бросают регистрацию, хотя всё реализовано по спецификации, — это провал валидации.
Какие принципы тестирования вы знаете?
В программе ISTQB Foundation Level семь принципов. Перечислите их и к одному-двум приведите пример.
- Тестирование показывает наличие дефектов, а не их отсутствие.
- Исчерпывающее тестирование невозможно.
- Раннее тестирование экономит время и деньги.
- Дефекты скапливаются: большая их часть обычно находится в небольшом числе модулей.
- Тесты изнашиваются: одни и те же проверки со временем перестают находить новые дефекты (в прежних версиях программы это называлось «парадоксом пестицида»).
- Тестирование зависит от контекста.
- Заблуждение об отсутствии дефектов: продукт без найденных дефектов может всё равно не решать задачу пользователя.
Что хотят услышать: не список наизусть, а вывод. Например: раз исчерпывающее тестирование невозможно, набор проверок выбирают с помощью техник тест-дизайна и оценки рисков.
Какие уровни тестирования существуют?
Программа ISTQB v4.0 выделяет пять уровней: компонентное (модульное), компонентное интеграционное, системное, системное интеграционное и приёмочное тестирование. Уровни различаются объектом проверки и тем, кто обычно её выполняет.
| Уровень | Что проверяют | Кто обычно выполняет |
|---|---|---|
| Компонентное | Отдельную функцию, класс или модуль в изоляции | Разработчики |
| Компонентное интеграционное | Взаимодействие компонентов между собой | Разработчики |
| Системное | Поведение всей системы целиком, включая нефункциональные характеристики | Команда тестирования |
| Системное интеграционное | Взаимодействие системы с внешними системами и сервисами | Команда тестирования |
| Приёмочное | Готовность системы к использованию и соответствие потребностям бизнеса | Пользователи, заказчик, владелец продукта |
В глоссарии разобраны модульное, интеграционное и сквозное (E2E) тестирование.
Какие типы тестирования вы знаете?
Типы тестирования группируют проверки по цели: функциональное тестирование проверяет, что система делает, нефункциональное — насколько хорошо она это делает. К нефункциональным характеристикам относятся производительность, безопасность, удобство использования, совместимость, надёжность.
Отдельная ось — на чём основаны тесты. Тестирование методом чёрного ящика строится на спецификации и не требует знания кода, методом белого ящика — на внутренней структуре кода. Третья ось — статическое тестирование (ревью требований и кода без запуска программы) и динамическое (с запуском).
Типичная ошибка: путать уровни и типы. «Системное» — это уровень, «функциональное» — тип; функциональные тесты выполняются на любом уровне.
Чем отличаются smoke, sanity, повторное и регрессионное тестирование?
Smoke-тест проверяет, что основная функциональность сборки работает и её имеет смысл тестировать дальше; повторное (подтверждающее) тестирование проверяет, что конкретный дефект исправлен; регрессионное — что изменения не сломали то, что работало раньше.
С sanity аккуратнее: в глоссарии ISTQB это синоним smoke-теста. В разговорной практике команд sanity часто называют быструю узкую проверку одной изменённой области после небольшой правки. На собеседовании назовите оба варианта и уточните, как термин используют в этой команде.
Пример: вышла сборка с исправлением расчёта скидки. Smoke — приложение открывается, можно войти и оформить заказ. Повторный тест — скидка теперь считается верно в сценарии из баг-репорта. Регрессия — корзина, оплата и история заказов работают как прежде.
Что такое ошибка, дефект и отказ?
Ошибка — это действие человека, которое приводит к неправильному результату; дефект — изъян в коде или документе, появившийся из-за ошибки; отказ — событие, когда система во время работы ведёт себя не так, как должна. Цепочка выглядит так: человек ошибся, в продукте появился дефект, при выполнении дефектного кода может произойти отказ.
Не каждый дефект приводит к отказу: дефектный код может ни разу не выполниться. А слово «баг» в командах используют и для дефекта, и для отказа, и это нормально, пока вы понимаете разницу.
Техники тест-дизайна
Это главный практический блок. В каждом вопросе интервьюер ждёт, что вы возьмёте поле или требование и покажете технику на нём. Первые примеры построены на одном требовании: поле «Возраст» принимает целые числа от 18 до 65 включительно.
Что такое техники тест-дизайна и зачем они нужны?
Техники тест-дизайна — это способы выбрать из бесконечного числа возможных проверок небольшой набор, который с наибольшей вероятностью найдёт дефекты. Они нужны, потому что исчерпывающее тестирование невозможно.
ISTQB делит техники на три группы: чёрного ящика (классы эквивалентности, анализ граничных значений, таблицы решений, переходы состояний), белого ящика (покрытие операторов и ветвей) и основанные на опыте (предположение об ошибках, исследовательское тестирование, тестирование по чек-листам).
Что такое разбиение на классы эквивалентности?
Это техника, при которой входные данные делят на группы, внутри которых система должна вести себя одинаково, и из каждой группы берут по одному значению. Если одно значение класса обработано верно, предполагается, что и остальные будут обработаны так же.
Для поля «Возраст» получается три класса по числовой оси: меньше 18 (недопустимый), от 18 до 65 (допустимый), больше 65 (недопустимый). Достаточно трёх проверок, например 10, 40 и 80. Отдельные недопустимые классы — не числа вовсе: пустое поле, текст, дробное число, отрицательное число, пробелы.
Что хотят услышать: что вы назвали и допустимые, и недопустимые классы и что недопустимые значения проверяются по одному, чтобы одна ошибка не маскировала другую.
Что такое анализ граничных значений?
Это техника, которая проверяет значения на границах классов эквивалентности, потому что дефекты чаще всего возникают именно там, например из-за знака «больше» вместо «больше или равно». Она применима только к упорядоченным данным: числам, датам, длине строки.
В двухзначном варианте берут границу и ближайшее значение из соседнего класса: 17, 18, 65, 66. В трёхзначном — границу и обоих её соседей: 17, 18, 19 и 64, 65, 66. Ниже те же шесть значений в виде небольшого автоматического теста на встроенном тест-раннере Node.js.
const test = require('node:test');
const assert = require('node:assert/strict');
// Requirement: the "Age" field accepts whole numbers from 18 to 65 inclusive.
function isValidAge(value) {
return Number.isInteger(value) && value >= 18 && value <= 65;
}
const cases = [
[17, false], // just below the lower boundary
[18, true], // lower boundary
[19, true], // just above the lower boundary
[64, true], // just below the upper boundary
[65, true], // upper boundary
[66, false], // just above the upper boundary
];
for (const [age, expected] of cases) {
test(`age ${age} -> ${expected}`, () => {
assert.equal(isValidAge(age), expected);
});
}
Запуск командой node --test age.test.js заканчивается сводкой:
# tests 6
# pass 6
# fail 0
Что такое таблица решений?
Таблица решений — это техника для логики, где результат зависит от комбинации нескольких условий: в столбцах перечисляют все комбинации условий, в строках — условия и ожидаемые действия. Каждый столбец становится тест-кейсом.
Пример требования: постоянный клиент получает скидку 10 %, заказ от 1000 грн даёт скидку 5 %, скидки суммируются. Два условия дают четыре правила.
| Правило 1 | Правило 2 | Правило 3 | Правило 4 | |
|---|---|---|---|---|
| Постоянный клиент | Да | Да | Нет | Нет |
| Сумма заказа от 1000 грн | Да | Нет | Да | Нет |
| Скидка | 15 % | 10 % | 5 % | 0 % |
При n условиях с ответами «да/нет» полная таблица содержит 2n столбцов, поэтому техника хорошо показывает пропущенные в требованиях комбинации.
Что такое тестирование переходов состояний?
Эту технику применяют, когда поведение системы зависит от её текущего состояния: описывают состояния, события и допустимые переходы, а затем проверяют и допустимые, и недопустимые переходы.
Пример — заказ в интернет-магазине со статусами «Новый», «Оплачен», «Отправлен», «Доставлен», «Отменён».
| Текущее состояние | Событие | Следующее состояние |
|---|---|---|
| Новый | Оплата прошла | Оплачен |
| Новый | Отмена пользователем | Отменён |
| Оплачен | Передан в доставку | Отправлен |
| Оплачен | Отмена пользователем | Отменён (с возвратом денег) |
| Отправлен | Получен покупателем | Доставлен |
| Доставлен | Отмена пользователем | Переход недопустим: статус не меняется, показано сообщение |
Что хотят услышать: что вы проверяете не только «счастливый путь», но и запрещённые переходы — оплатить отменённый заказ, отменить доставленный.
Что такое попарное тестирование (pairwise)?
Pairwise — это комбинаторная техника, при которой набор тестов покрывает каждую пару значений любых двух параметров хотя бы один раз, вместо перебора всех возможных комбинаций. Она опирается на наблюдение, что дефекты чаще вызывает одно значение или сочетание двух параметров, чем трёх и больше.
Пример: браузер (Chrome, Firefox, Edge), операционная система (Windows, macOS), язык интерфейса (UA, EN). Полный перебор — 3 × 2 × 2 = 12 комбинаций. Все пары покрываются шестью.
| № | Браузер | ОС | Язык |
|---|---|---|---|
| 1 | Chrome | Windows | UA |
| 2 | Chrome | macOS | EN |
| 3 | Firefox | Windows | EN |
| 4 | Firefox | macOS | UA |
| 5 | Edge | Windows | UA |
| 6 | Edge | macOS | EN |
На реальных проектах такие наборы строят инструментом, а не вручную. В программу ISTQB Foundation Level pairwise не входит, но спрашивают о нём часто, поэтому знать идею полезно.
Что такое исследовательское тестирование и предположение об ошибках?
Это техники, основанные на опыте. В исследовательском тестировании тесты проектируют, выполняют и оценивают одновременно, по ходу изучения продукта; предположение об ошибках — это догадка, где дефекты вероятны, на основе опыта и знания типичных проблем.
Исследовательское тестирование не означает «кликать как попало»: обычно его проводят сессиями с целью и ограничением по времени, а результаты записывают. Пример предположения об ошибках для любого текстового поля: пробелы в начале и конце, очень длинная строка, эмодзи, вставка из буфера обмена, двойной клик по кнопке отправки.
Тестовая документация и баг-репорты
Чем тест-кейс отличается от чек-листа?
Тест-кейс — это подробное описание одной проверки: предусловия, входные данные, шаги, ожидаемый результат и постусловия. Чек-лист — список того, что нужно проверить, без детальных шагов.
Тест-кейсы нужны, когда проверку должен одинаково выполнить любой человек, когда сценарий сложный или его планируют автоматизировать. Чек-лист быстрее писать и поддерживать, он подходит опытной команде и часто меняющемуся продукту. Цена чек-листа — результат сильнее зависит от того, кто его проходит.
Признаки хорошего тест-кейса: он проверяет одну вещь, не зависит от других кейсов, а его ожидаемый результат конкретен — «показано сообщение „Неверный email или пароль“», а не «система работает корректно».
Что входит в тест-план?
Тест-план описывает цели, объём, подход, ресурсы и расписание тестирования. На Junior достаточно назвать основные разделы; составлять план обычно просят на уровне Middle.
- Что тестируем и что остаётся за рамками.
- Подход: уровни и типы тестирования, техники, доля автоматизации.
- Критерии входа и выхода: когда начинаем и когда считаем работу законченной.
- Окружения, тестовые данные, инструменты.
- Роли, сроки и оценка трудозатрат.
- Риски и то, как с ними работаем.
- Отчётность: какие метрики собираем и кому сообщаем.
Как оформить баг-репорт?
Хороший баг-репорт позволяет разработчику воспроизвести проблему с первого раза, не задавая вопросов. Обязательные части: заголовок, окружение, шаги воспроизведения, фактический и ожидаемый результат, серьёзность, вложения.
| Поле | Пример заполнения |
|---|---|
| Заголовок | Корзина: промокод SALE10 применяется повторно после обновления страницы |
| Окружение | Тестовый стенд, сборка 2.14.0, Chrome последней версии, Windows 11 |
| Предусловия | Пользователь авторизован, в корзине один товар на 1000 грн |
| Шаги | 1. Открыть корзину. 2. Ввести промокод SALE10 и нажать «Применить». 3. Обновить страницу. 4. Снова ввести SALE10 и нажать «Применить» |
| Фактический результат | Скидка применена дважды, сумма к оплате — 800 грн |
| Ожидаемый результат | Показано сообщение «Промокод уже применён», сумма к оплате — 900 грн |
| Severity / Priority | Critical / High |
| Вложения | Видео воспроизведения, ответ сервера на запрос применения промокода из вкладки Network |
Заголовок удобно строить по схеме «где — что — при каких условиях». Типичные ошибки: заголовок «Не работает корзина», несколько дефектов в одном репорте, оценочные слова вместо фактов, отсутствие ожидаемого результата.
Чем severity отличается от priority?
Severity (серьёзность) показывает, насколько сильно дефект влияет на работу системы; priority (приоритет) — насколько срочно его нужно исправить с точки зрения бизнеса. Серьёзность обычно оценивает тестировщик, приоритет — владелец продукта или менеджер.
| Сочетание | Пример |
|---|---|
| Высокая серьёзность, высокий приоритет | Не проходит оплата у всех пользователей |
| Высокая серьёзность, низкий приоритет | Приложение падает при экспорте отчёта в формат, которым пользуются единицы и для которого есть обходной путь |
| Низкая серьёзность, высокий приоритет | Опечатка в названии компании на главной странице накануне рекламной кампании |
| Низкая серьёзность, низкий приоритет | Смещённая на пару пикселей иконка в редко посещаемом разделе настроек |
Какой жизненный цикл у дефекта?
Типовой путь: новый → назначен → в работе → исправлен → на проверке → закрыт; если исправление не подтвердилось, дефект переоткрывают. Названия статусов зависят от трекера и договорённостей команды.
Боковые ветки: отклонён (не дефект, дубликат, не воспроизводится) и отложен (исправят в одной из следующих версий). Тестировщик участвует в двух точках: создаёт репорт и после исправления проводит повторное тестирование, а затем проверяет соседнюю функциональность на регрессию.
Что вы сделаете, если разработчик отвечает «это не баг» или «у меня не воспроизводится»?
Сначала проверю собственный репорт, затем вернусь к требованиям, а если требования не дают ответа — вынесу вопрос на того, кто принимает решение о продукте. Спорить о мнениях бессмысленно, нужны факты.
- Воспроизвожу ещё раз на чистых данных, уточняю окружение, сборку, учётную запись, добавляю видео и логи.
- Если не воспроизводится у разработчика — сравниваем окружения и данные, при необходимости показываю на своей машине.
- Если спор «баг или фича» — ищу требование или макет. Если их нет, это пробел в требованиях: вопрос решает владелец продукта или бизнес-аналитик.
- Фиксирую решение в задаче, чтобы к нему не возвращаться.
Что хотят услышать: что вы защищаете качество продукта, а не свою правоту, и не закрываете дефект молча.
Процессы: SDLC, STLC, Agile и Scrum
Что такое SDLC и STLC?
SDLC — жизненный цикл разработки программного обеспечения: от сбора требований до сопровождения. STLC — жизненный цикл тестирования, то есть последовательность активностей тестирования внутри SDLC.
В терминах ISTQB процесс тестирования состоит из планирования, мониторинга и контроля, анализа («что тестировать»), проектирования («как тестировать»), реализации (подготовка тест-кейсов, данных и окружения), выполнения и завершения. В последовательных моделях вроде Waterfall тестирование — отдельная фаза после разработки, и поздно найденные дефекты обходятся дорого. В Agile те же активности повторяются в каждой короткой итерации вместе с разработкой, регрессия проводится постоянно, поэтому растёт роль автоматизации.
Что делает тестировщик в Scrum-команде?
Тестировщик участвует во всём цикле спринта: уточняет требования до начала разработки, проектирует и выполняет тесты во время спринта и помогает команде решить, готов ли инкремент.
Стоит знать, что в Scrum Guide отдельной роли тестировщика нет: в Scrum-команде есть Product Owner, Scrum Master и Developers, и тестировщик входит в число Developers. За качество отвечает вся команда.
| Событие | Что делает тестировщик |
|---|---|
| Уточнение бэклога (refinement) | Задаёт вопросы к историям, находит противоречия, предлагает критерии приёмки |
| Планирование спринта | Оценивает объём тестирования, называет риски и зависимости |
| Ежедневная встреча | Сообщает, что проверено, что блокирует, какие дефекты критичны |
| В течение спринта | Пишет тест-кейсы или чек-листы, тестирует готовые задачи, заводит дефекты, проводит регрессию |
| Обзор спринта и ретроспектива | Помогает показать результат, предлагает улучшения процесса |
Когда нужно начинать тестирование?
Как можно раньше — с момента появления требований, а не готовой сборки. Это прямо следует из принципа «раннее тестирование экономит время и деньги»; такой подход называют shift left.
Тестирование требований — это статическое тестирование: вы проверяете их на полноту, однозначность, непротиворечивость и проверяемость. Пример вопроса к требованию «поле принимает возраст от 18 до 65»: включены ли границы, что показать при ошибке, можно ли ввести дробное число. Дефект, найденный на этом этапе, исправляется правкой текста, а не кода.
Как понять, что тестирование можно заканчивать?
Тестирование заканчивают, когда выполнены заранее согласованные критерии выхода, а не когда «дефекты перестали находиться». В Agile-командах эту роль играет Definition of Done.
Типичные критерии: запланированные тесты выполнены, требования покрыты, критичных и блокирующих дефектов нет, оставшиеся дефекты известны и приняты владельцем продукта, регрессия пройдена. Если время закончилось раньше, честный ответ — отчёт об остаточных рисках: что не проверено и чем это грозит. Решение о выпуске принимает бизнес, тестировщик даёт для него информацию.
Те же темы — с преподавателем и практикой
Курс QA в Prog Academy — это 5 модулей за 4 месяца: AI Start, QA Manual, QA Java, QA Automation и SQL. В модуле QA Manual есть техники тест-дизайна, тестовая документация, баг-репорты, тестирование API и Postman, а также разбор вопросов и задач для подготовки к собеседованию на позицию QA Engineer.
Программа курса QA →Веб, клиент-сервер и тестирование API
Что такое клиент-серверная архитектура и что происходит, когда вы открываете страницу?
В клиент-серверной архитектуре клиент (браузер или мобильное приложение) отправляет запросы, а сервер обрабатывает их и возвращает ответы. Коротко по шагам:
- Браузер через DNS узнаёт IP-адрес сервера по доменному имени.
- Устанавливает соединение, для HTTPS — с шифрованием TLS.
- Отправляет HTTP-запрос: метод, адрес, заголовки, иногда тело.
- Сервер обрабатывает запрос, при необходимости обращается к базе данных.
- Сервер возвращает ответ: код состояния, заголовки и тело (HTML, JSON, файл).
- Браузер строит страницу и дозагружает стили, скрипты, изображения отдельными запросами.
Что хотят услышать: понимание, что дефект может быть на клиенте, на сервере или в данных, и что вы умеете это различить по вкладке Network.
Какие HTTP-методы вы знаете и чем они отличаются?
Основные методы — GET (получить данные), POST (создать ресурс или отправить данные на обработку), PUT (полностью заменить ресурс), PATCH (частично изменить) и DELETE (удалить). Их свойства определены в RFC 9110.
| Метод | Назначение | Безопасный | Идемпотентный |
|---|---|---|---|
| GET | Получение данных | Да | Да |
| POST | Создание ресурса, отправка данных на обработку | Нет | Нет |
| PUT | Полная замена ресурса | Нет | Да |
| PATCH | Частичное изменение ресурса | Нет | Нет |
| DELETE | Удаление ресурса | Нет | Да |
Безопасный метод не должен менять состояние сервера. Идемпотентный — тот, у которого несколько одинаковых запросов подряд дают то же состояние сервера, что и один. Для тестировщика это готовая проверка: два одинаковых PUT не должны создать два объекта, а повторная отправка POST при двойном клике может создать дубликат заказа.
Какие коды ответов HTTP нужно знать?
Коды делятся на пять классов: 1xx — информационные, 2xx — успех, 3xx — перенаправление, 4xx — ошибка на стороне клиента, 5xx — ошибка на стороне сервера.
| Код | Значение |
|---|---|
| 200 OK | Запрос выполнен успешно |
| 201 Created | Ресурс создан |
| 204 No Content | Успех, тела ответа нет |
| 301 / 302 | Постоянное / временное перенаправление |
| 304 Not Modified | Ресурс не изменился, можно взять из кеша |
| 400 Bad Request | Некорректный запрос |
| 401 Unauthorized | Клиент не аутентифицирован: нет действительных учётных данных |
| 403 Forbidden | Сервер понял запрос, но отказывается его выполнять, например не хватает прав |
| 404 Not Found | Ресурс не найден |
| 500 Internal Server Error | Непредвиденная ошибка на сервере |
| 502 / 503 | Ошибка шлюза / сервис временно недоступен |
Частый уточняющий вопрос — разница между 401 и 403: 401 означает «представьтесь», 403 — «я знаю, кто вы, но вам сюда нельзя». И ещё одно правило: ответ 500 на некорректные данные от пользователя — это дефект, сервер должен вернуть понятную ошибку 4xx.
Чем cookies отличаются от localStorage и sessionStorage?
Cookies браузер автоматически отправляет на сервер с каждым запросом к соответствующему домену, а localStorage и sessionStorage доступны только JavaScript на странице и сами на сервер не передаются.
| Cookies | localStorage | sessionStorage | |
|---|---|---|---|
| Отправка на сервер | Автоматически с запросами | Нет | Нет |
| Срок жизни | До даты истечения или до закрытия браузера | Пока данные не удалят | Пока открыта вкладка |
| Объём | Около 4 КБ на одну cookie | Около 5 МБ на источник | Около 5 МБ на источник |
| Типичное применение | Сессия, авторизация | Настройки интерфейса, черновики | Данные одного визита во вкладке |
У cookies есть атрибуты, о которых стоит упомянуть: HttpOnly закрывает cookie от JavaScript, Secure разрешает передачу только по HTTPS, SameSite ограничивает отправку с чужих сайтов. Подробности — в документации MDN о cookies и Web Storage API. Всё это видно во вкладке Application в DevTools.
Как вы используете DevTools в работе?
DevTools нужны, чтобы понять, на какой стороне дефект, и приложить к баг-репорту доказательства. Перечислите вкладки и что вы в них делаете.
- Network — запросы и ответы: метод, код состояния, тело, время; здесь же имитация медленной сети и отключение кеша.
- Console — ошибки JavaScript, которые часто объясняют «кнопка не нажимается».
- Elements — структура и стили страницы, проверка вёрстки и локаторов.
- Application — cookies, localStorage и sessionStorage: посмотреть, изменить, удалить.
- Режим устройств — проверка адаптивной вёрстки на разных размерах экрана.
Пример: после нажатия «Сохранить» ничего не происходит. В Network виден запрос с ответом 500 — дефект на сервере, прикладываю тело ответа. Запроса нет, а в Console ошибка — дефект на клиенте. Справка — в документации Chrome DevTools.
Что такое REST API и что вы проверяете в ответе?
REST API — это интерфейс, в котором клиент работает с ресурсами по адресам (URL) с помощью HTTP-методов, а данные чаще всего передаются в формате JSON. Тестирование API проверяет логику без пользовательского интерфейса.
Что проверять в ответе:
- код состояния — соответствует ли он сценарию;
- тело ответа — структура, обязательные поля, типы и значения;
- заголовки, например
Content-Type; - время ответа;
- состояние системы после запроса: объект действительно создан, изменён или удалён (проверяется следующим GET или запросом в базу данных).
И негативные сценарии: запрос без токена, с чужим токеном, без обязательного поля, с неверным типом данных, с несуществующим идентификатором, со значениями на границах и за ними.
Как вы тестируете API в Postman?
В Postman я собираю запросы в коллекцию, выношу адрес стенда и токены в переменные окружения и добавляю к запросам автоматические проверки в скриптах. Коллекцию можно запускать целиком и передавать коллегам.
Минимальный пример проверок во вкладке скриптов запроса (выполняются после получения ответа):
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response contains user id", function () {
const body = pm.response.json();
pm.expect(body.id).to.eql(1);
});
Синтаксис описан в документации Postman. Что хотят услышать: что вы проверяете не только код 200, но и содержимое ответа, и умеете связать запросы в цепочку — например, сохранить идентификатор созданного объекта в переменную и использовать его в следующем запросе.
SQL и мобильное тестирование
Все запросы ниже выполнены в SQLite на небольшой учебной базе интернет-магазина. Её можно создать у себя и повторить примеры. Если SQL для вас пока новая тема, начните со статьи SQL для начинающих или бесплатного курса по SQL.
CREATE TABLE users (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
email TEXT NOT NULL,
city TEXT
);
CREATE TABLE orders (
id INTEGER PRIMARY KEY,
user_id INTEGER NOT NULL REFERENCES users(id),
amount INTEGER NOT NULL,
status TEXT NOT NULL
);
INSERT INTO users (id, name, email, city) VALUES
(1, 'Olena', '[email protected]', 'Kyiv'),
(2, 'Taras', '[email protected]', 'Lviv'),
(3, 'Iryna', '[email protected]', 'Kyiv'),
(4, 'Maksym', '[email protected]', NULL),
(5, 'Sofiia', '[email protected]', 'Odesa');
INSERT INTO orders (id, user_id, amount, status) VALUES
(101, 1, 1200, 'paid'),
(102, 1, 450, 'paid'),
(103, 2, 900, 'cancelled'),
(104, 3, 2500, 'paid'),
(105, 3, 300, 'new'),
(106, 3, 700, 'paid');
Зачем тестировщику SQL и как выбрать данные из таблицы?
SQL нужен тестировщику, чтобы проверить, что данные действительно сохранились в базе так, как показывает интерфейс, и чтобы подготовить или найти тестовые данные. Базовый запрос — SELECT с фильтром WHERE и сортировкой ORDER BY.
SELECT id, name, city
FROM users
WHERE city = 'Kyiv'
ORDER BY name;
id name city
-- ----- ----
3 Iryna Kyiv
1 Olena Kyiv
Типичная ошибка: сравнивать с NULL через знак равенства. Условие city = NULL не вернёт ни одной строки, правильно — city IS NULL.
Чем INNER JOIN отличается от LEFT JOIN?
INNER JOIN возвращает только те строки, для которых нашлась пара в обеих таблицах; LEFT JOIN возвращает все строки левой таблицы, а там, где пары нет, подставляет NULL.
INNER JOIN — оплаченные заказы с именами покупателей:
SELECT u.name, o.id AS order_id, o.amount, o.status
FROM users u
INNER JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid'
ORDER BY o.amount DESC;
name order_id amount status
----- -------- ------ ------
Iryna 104 2500 paid
Olena 101 1200 paid
Iryna 106 700 paid
Olena 102 450 paid
LEFT JOIN — количество заказов у каждого пользователя, включая тех, у кого заказов нет:
SELECT u.name, COUNT(o.id) AS orders_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id, u.name
ORDER BY orders_count DESC, u.name;
name orders_count
------ ------------
Iryna 3
Olena 2
Taras 1
Maksym 0
Sofiia 0
С INNER JOIN Maksym и Sofiia в результат не попали бы вовсе. Обратите внимание на COUNT(o.id): он считает только строки, где значение не NULL, поэтому у пользователей без заказов получается 0, а не 1.
Что делает GROUP BY и чем WHERE отличается от HAVING?
GROUP BY объединяет строки в группы, чтобы посчитать по каждой агрегат — COUNT, SUM, AVG, MIN, MAX. WHERE фильтрует строки до группировки, HAVING — группы после неё.
SELECT u.name, COUNT(o.id) AS orders_count, SUM(o.amount) AS total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid'
GROUP BY u.id, u.name
HAVING SUM(o.amount) > 2000;
name orders_count total
----- ------------ -----
Iryna 2 3200
Здесь WHERE сначала оставил только оплаченные заказы, GROUP BY собрал их по покупателям, а HAVING отобрал тех, у кого сумма больше 2000. У Olena сумма оплаченных заказов 1650, поэтому её в результате нет. Синтаксис — в документации SQLite по SELECT.
В чём особенности тестирования мобильных приложений?
Мобильное приложение работает на множестве устройств с разными экранами и версиями ОС, в нестабильной сети и постоянно прерывается внешними событиями, и всё это нужно проверять дополнительно к функциональности.
- Типы приложений: нативные (написаны под конкретную платформу), веб-приложения (открываются в браузере) и гибридные (веб-содержимое внутри нативной оболочки).
- Прерывания: входящий звонок, уведомление, сворачивание и возврат, блокировка экрана, разряд батареи.
- Сеть: переключение между Wi-Fi и мобильной сетью, слабый сигнал, режим полёта, работа офлайн.
- Разрешения: камера, геолокация, уведомления — что происходит при отказе и при отзыве разрешения в настройках.
- Устройство: поворот экрана, разные размеры и плотность экранов, тёмная тема, размер системного шрифта.
- Жизненный цикл: установка, обновление поверх старой версии с сохранением данных, удаление.
Про устройства: эмулятор Android и симулятор iOS удобны для быстрых проверок вёрстки и логики на разных версиях ОС, но перед релизом ключевые сценарии проходят на реальных устройствах — производительность, камеру, жесты, уведомления и поведение сети на эмуляторе достоверно не проверить. Инструменты описаны в документации Android Emulator и Xcode.
Основы автоматизации и AI-инструменты
От ручного тестировщика не ждут готового фреймворка, но ждут понимания, зачем нужна автоматизация тестирования и где её границы.
Что стоит автоматизировать, а что нет?
Автоматизировать стоит стабильные, часто повторяющиеся проверки с однозначным ожидаемым результатом; не стоит — то, что часто меняется, выполняется один раз или требует человеческой оценки.
| Хорошие кандидаты | Плохие кандидаты |
|---|---|
| Регрессионные и smoke-проверки | Функциональность, которая ещё активно меняется |
| Проверки API | Разовые проверки |
| Один сценарий на большом наборе данных | Удобство использования и внешний вид «на глаз» |
| Критичные для бизнеса сценарии: вход, оплата | Исследовательское тестирование |
Что хотят услышать: что автоматизация — это вложение: тест нужно написать и потом поддерживать, поэтому решение принимают по соотношению затрат и пользы, а не по принципу «автоматизируем всё».
Что такое пирамида тестирования?
Пирамида тестирования — это модель распределения автотестов по уровням: в основании много быстрых модульных тестов, в середине меньше интеграционных (в том числе тестов API), на вершине немного медленных сквозных тестов через пользовательский интерфейс.
Логика простая: чем выше уровень, тем тест медленнее, дороже в поддержке и менее стабилен, зато ближе к реальному сценарию пользователя. Обратная ситуация, когда почти все автотесты идут через интерфейс, приводит к долгим и хрупким прогонам. Классическое описание — в заметке Мартина Фаулера Test Pyramid.
Чем Selenium отличается от Playwright?
Оба инструмента управляют браузером из кода. Selenium WebDriver работает через стандартизованный W3C протокол WebDriver; Playwright — более новый инструмент со встроенным автоматическим ожиданием элементов и собственным тест-раннером.
| Selenium WebDriver | Playwright | |
|---|---|---|
| Языки | Java, Python, C#, JavaScript, Ruby, Kotlin | JavaScript/TypeScript, Python, Java, .NET |
| Браузеры | Chrome, Firefox, Edge, Safari через драйверы браузеров | Движки Chromium, Firefox и WebKit |
| Ожидания | Настраиваются в коде теста (явные и неявные) | Перед действием автоматически проверяется, что элемент готов к нему |
| Тест-раннер | Внешний: JUnit, TestNG, pytest и другие | Собственный Playwright Test |
Источники: документация Selenium WebDriver и описание автоожиданий Playwright. Сравнивать «что лучше» на собеседовании не нужно: выбор зависит от стека проекта, а принципы — локаторы, ожидания, независимость тестов — одинаковы.
Как выглядит простой автотест?
Любой автотест повторяет структуру ручного тест-кейса: подготовка, действия и проверка ожидаемого результата. Ниже тест на Playwright для негативного сценария входа: неверный пароль должен показать сообщение об ошибке и оставить пользователя на странице логина.
const { test, expect } = require('@playwright/test');
test('login with a wrong password shows an error', async ({ page }) => {
await page.goto('/login.html');
await page.getByLabel('Email').fill('[email protected]');
await page.getByLabel('Password').fill('wrong-password');
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('alert')).toHaveText('Invalid email or password');
await expect(page).toHaveURL(/login/);
});
Тест проверен на учебной странице с формой входа; адрес стенда задаётся параметром baseURL в конфигурации. Вывод запуска:
Running 1 test using 1 worker
✓ 1 tests/login.spec.js:3:1 › login with a wrong password shows an error (177ms)
1 passed (1.4s)
Что стоит уметь объяснить: элементы найдены по подписи и роли, то есть так, как их видит пользователь, а не по хрупким CSS-классам (рекомендации по локаторам); в тесте нет пауз вроде «подождать 3 секунды» — проверка expect сама ждёт нужного состояния. Тест, который то проходит, то падает без изменений в коде, называют нестабильным (flaky); самые частые причины — жёсткие паузы, зависимость от других тестов и общие тестовые данные.
Как вы используете AI-инструменты в тестировании?
Я использую AI-ассистента как помощника для черновой работы и всегда проверяю результат сама: ответственность за тесты остаётся на тестировщике.
- Где помогает: набросать тест-кейсы и чек-лист по требованию, найти пропущенные негативные сценарии, сгенерировать тестовые данные, составить SQL-запрос или регулярное выражение, разобрать лог или трассировку ошибки, переформулировать баг-репорт.
- Где ошибается: придумывает требования, которых нет, уверенно выдаёт неверные факты, не знает контекста вашего продукта и бизнес-правил.
- Чего делать нельзя: отправлять в публичные сервисы персональные данные пользователей, ключи доступа и закрытый код, если это не разрешено правилами компании.
Что хотят услышать: конкретный пример из вашей практики и то, как именно вы проверили результат ассистента. Как AI меняет профессию в целом, разобрано в статье QA Engineer в эпоху AI.
Практические задачи с решениями
На практической части оценивают не количество идей, а структуру: сначала уточняющие вопросы, потом группы проверок, потом приоритеты. Ниже пять типичных задач.
Задача 1. Протестируйте форму входа
Дана форма: email, пароль, кнопка «Войти», ссылка «Забыли пароль?». Начните с вопросов: какие требования к email и паролю, есть ли блокировка после нескольких неудачных попыток, сколько живёт сессия. Затем разложите проверки по группам.
| Группа | Проверки |
|---|---|
| Позитивные | Вход с верными данными; email в другом регистре; вход по клавише Enter; переход по ссылке восстановления пароля |
| Негативные | Неверный пароль; незарегистрированный email; пустые поля; email без символа @; пробелы в начале и конце |
| Границы | Пароль минимальной и максимальной длины и на один символ короче и длиннее |
| Безопасность | Пароль скрыт при вводе; сообщение об ошибке не раскрывает, что именно неверно — email или пароль; ограничение числа попыток; данные передаются по HTTPS; после выхода кнопка «Назад» не возвращает в личный кабинет |
| Интерфейс и удобство | Порядок перехода по Tab; понятные тексты ошибок; отображение на мобильном экране; работа менеджера паролей |
| Сессия | Вход в двух вкладках; истечение сессии; поведение после смены пароля на другом устройстве |
Задача 2. Протестируйте карандаш (или лифт)
Задача проверяет не знание карандашей, а способ мышления. Правильное начало — вопросы: для кого он и для чего, какие к нему требования, простой он или механический, есть ли ластик. Без требований невозможно сказать, что является дефектом.
Затем покажите структуру по типам тестирования:
- Функциональное: пишет на бумаге; линия нужной толщины и цвета; затачивается; ластик стирает след.
- Удобство использования: удобно держать, не скатывается со стола, маркировка твёрдости читается.
- Надёжность и нагрузка: грифель не ломается при обычном нажиме; что происходит при сильном нажиме и после падения со стола.
- Совместимость: разные виды бумаги, разные точилки.
- Негативные сценарии: письмо по мокрой или глянцевой поверхности, использование на морозе.
- Безопасность: нетоксичные материалы, отсутствие заноз.
Для лифта логика та же, но добавляются состояния и переходы: двери открыты или закрыты, кабина движется или стоит, вызовы с нескольких этажей одновременно, перегруз, отключение питания. Это хороший повод применить тестирование переходов состояний.
Задача 3. Напишите тест-кейсы по требованию
Требование: «При регистрации пароль должен содержать от 8 до 64 символов, минимум одну латинскую букву и минимум одну цифру. При нарушении правила под полем показывается сообщение об ошибке, аккаунт не создаётся».
| № | Проверка | Тестовые данные | Ожидаемый результат |
|---|---|---|---|
| 1 | Допустимый пароль минимальной длины | 8 символов: буквы и цифра | Аккаунт создан |
| 2 | Допустимый пароль максимальной длины | 64 символа: буквы и цифра | Аккаунт создан |
| 3 | Пароль короче минимума | 7 символов: буквы и цифра | Сообщение об ошибке, аккаунт не создан |
| 4 | Пароль длиннее максимума | 65 символов: буквы и цифра | Сообщение об ошибке, аккаунт не создан |
| 5 | Пароль без цифр | 10 латинских букв | Сообщение об ошибке, аккаунт не создан |
| 6 | Пароль без букв | 10 цифр | Сообщение об ошибке, аккаунт не создан |
| 7 | Пустое поле | — | Сообщение об ошибке, аккаунт не создан |
И обязательно назовите вопросы к требованию — это часто ценнее самих кейсов: разрешены ли спецсимволы, пробелы и кириллица; считается ли кириллическая буква «буквой»; учитывается ли регистр; обрезаются ли пробелы по краям; каков точный текст сообщения.
Задача 4. Найдите граничные значения для поля
Требование: «Поле „Количество“ в корзине принимает целые числа от 1 до 99».
- Классы эквивалентности: меньше 1 (недопустимый), от 1 до 99 (допустимый), больше 99 (недопустимый).
- Граничные значения, двухзначный вариант: 0, 1, 99, 100.
- Трёхзначный вариант: 0, 1, 2 и 98, 99, 100.
- Недопустимые классы вне числовой оси: пустое поле, отрицательное число, дробное число (1,5), буквы, пробел, очень большое число.
Дополнительный балл — заметить то, чего в требовании нет: что происходит, если на складе осталось меньше товара, чем введено, и можно ли изменить значение в поле в обход кнопок «плюс» и «минус».
Задача 5. Напишите SQL-запросы
Используется база из раздела про SQL. Первая часть: найдите пользователей, у которых нет ни одного заказа.
SELECT u.id, u.name
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL
ORDER BY u.id;
id name
-- ------
4 Maksym
5 Sofiia
Вторая часть: найдите email, которые встречаются в таблице пользователей больше одного раза. Это типичная проверка тестировщика — убедиться, что в базе нет дубликатов там, где значение должно быть уникальным.
SELECT email, COUNT(*) AS cnt
FROM users
GROUP BY email
HAVING COUNT(*) > 1;
email cnt
----------------- ---
[email protected] 2
Типичные ошибки кандидатов
Чаще всего кандидатов подводит не незнание определений, а неумение применить их к примеру. Список составлен по опыту автора.
- Определение без примера. «Валидация — это проверка соответствия ожиданиям пользователя» и тишина. Сразу добавляйте случай из практики или учебного проекта.
- Тестирование без вопросов. Кандидат сразу перечисляет проверки для формы, не спросив ни об одном требовании.
- Только позитивные сценарии. Нет негативных проверок, границ и запрещённых переходов.
- Путаница в терминах. Severity и priority, уровни и типы тестирования, повторное и регрессионное тестирование.
- Расплывчатый баг-репорт. Заголовок «не работает», шаги «зайти и проверить», ожидаемый результат отсутствует.
- Отсутствие приоритетов. Тридцать проверок одним списком без ответа на вопрос «что вы проверите первым, если есть десять минут».
- Заученные ответы. Первый же уточняющий вопрос показывает, что за текстом нет понимания.
- Инструменты «в резюме». Postman и SQL указаны, но кандидат не может отправить запрос или написать JOIN.
- Позиция «разработчик — противник». Интервьюер ищет человека, который помогает команде, а не выигрывает споры.
- Нет вопросов к компании. Это читается как отсутствие интереса к работе.
Что спросить у интервьюера?
Вопросы кандидата показывают, что он понимает, как устроена работа тестировщика, и помогают самому оценить команду. Выберите пять-шесть из списка.
- Сколько тестировщиков в команде и как выглядит соотношение с разработчиками?
- Как устроен процесс: Scrum, Kanban, какова длина спринта, как проходит релиз?
- Кто пишет требования и на каком этапе тестировщик подключается к задаче?
- Какая тестовая документация ведётся: тест-кейсы, чек-листы, в каком инструменте?
- Есть ли автоматизация, на каком стеке и может ли ручной тестировщик в неё развиваться?
- Какие тестовые окружения есть и как туда попадают сборки?
- Как выглядит онбординг и будет ли у меня наставник в первые месяцы?
- По каким критериям оценивают работу тестировщика и как проходит пересмотр уровня?
- Какие правила использования AI-инструментов приняты в команде?
- Какие задачи я получу в первый месяц?
План подготовки на две недели
План рассчитан на час-два в день и на человека, который уже прошёл обучение и повторяет материал. Это авторский ориентир: темы, в которых вы уверены, сокращайте, слабые — растягивайте.
| Дни | Тема | Что сделать |
|---|---|---|
| 1–2 | Теория тестирования | Повторить термины по глоссарию ISTQB, к каждому из семи принципов и каждому уровню записать свой пример |
| 3–4 | Техники тест-дизайна | Взять три формы на реальных сайтах и для каждой выписать классы эквивалентности, границы и одну таблицу решений |
| 5 | Документация | Написать пять тест-кейсов и три баг-репорта для любого приложения, которым вы пользуетесь; попросить кого-то воспроизвести дефект по вашему репорту |
| 6 | Процессы | Прочитать Scrum Guide, подготовить ответ о роли тестировщика в спринте и о критериях завершения тестирования |
| 7 | Повторение | Ответить вслух на вопросы первых четырёх блоков, записать себя и прослушать |
| 8–9 | Веб и API | Открыть DevTools на любом сайте и разобрать запросы во вкладке Network; отправить в Postman GET, POST и DELETE к открытому учебному API и добавить проверки |
| 10 | SQL | Создать базу из этой статьи и написать по памяти запросы с WHERE, JOIN, GROUP BY и HAVING |
| 11 | Мобильное тестирование и автоматизация | Составить чек-лист мобильных проверок для одного приложения; повторить пирамиду тестирования и критерии выбора тестов для автоматизации |
| 12 | Практические задачи | Решить пять задач из раздела с практикой письменно, с ограничением по времени |
| 13 | Пробное собеседование | Провести пробное интервью с коллегой или одногруппником; подготовить рассказ о себе и вопросы к компании |
| 14 | Резюме и пробелы | Проверить, что всё указанное в резюме вы можете показать на практике; повторить вопросы, на которые отвечали неуверенно |
Если после собеседований становится ясно, что не хватает системной базы, её даёт курс QA. Следующий шаг после уверенного ручного тестирования — курс QA Automation.
Частые вопросы
Сколько времени нужно на подготовку к собеседованию на Junior QA?
Если теория и практика уже пройдены, на повторение обычно хватает двух недель по часу-два в день: неделя на теорию, тест-дизайн и документацию, неделя на веб, API, SQL и пробные собеседования. Это ориентир автора, а не статистика. Если вы ни разу не писали тест-кейсы и баг-репорты руками, сначала нужна практика, и на неё уйдёт больше времени.
Нужно ли знать программирование для собеседования на ручного тестировщика?
Для позиции ручного тестировщика писать код обычно не просят. Но от кандидата ждут технической грамотности: понимать клиент-серверную архитектуру, читать JSON, пользоваться DevTools и Postman, писать простые SQL-запросы. Базовое понимание того, что такое автотест и что стоит автоматизировать, будет плюсом.
Нужен ли сертификат ISTQB, чтобы пройти собеседование?
Сертификат не является обязательным условием, если он прямо не указан в вакансии. Гораздо важнее знать терминологию ISTQB: вопросы по теории почти всегда опираются на программу Foundation Level, и ответы в этих терминах звучат увереннее, чем пересказ своими словами.
Какой уровень английского нужен тестировщику на собеседовании?
Нужен английский, достаточный для чтения требований и документации и для письменного описания дефекта: баг-репорты во многих командах пишут на английском. Если в вакансии указан разговорный уровень, часть собеседования проведут на английском, поэтому заранее потренируйтесь рассказывать о себе и о своём учебном проекте.
Дают ли тестовое задание и как его выполнять?
Часто дают: протестировать сайт или форму, написать тест-кейсы по требованию, оформить несколько баг-репортов. Оценивают не количество найденных дефектов, а ход мысли и аккуратность оформления: понятные заголовки, шаги воспроизведения, ожидаемый и фактический результат, расстановку приоритетов. Обязательно напишите, что вы проверили и что осталось за рамками.
Можно ли пользоваться AI-инструментами на собеседовании и в тестовом задании?
Зависит от правил компании, поэтому спросите об этом прямо. В тестовом задании ассистента часто разрешают как помощника, но за результат отвечаете вы: каждый тест-кейс и каждый баг-репорт нужно уметь объяснить. Во время живого разговора читать ответы с экрана не стоит: это заметно и оценивается хуже, чем честное «не знаю».
Что делать, если не знаете ответа на вопрос?
Скажите об этом прямо и покажите, как рассуждаете: что вы знаете о смежной теме, как бы искали ответ, что проверили бы в первую очередь. Для тестировщика умение уточнять и рассуждать вслух важнее заученного определения. Придуманный ответ хуже, чем признание пробела.
Спрашивают ли SQL и API на собеседовании Junior QA?
Да, в большинстве вакансий на тестирование веб-приложений это входит в ожидаемую базу. Обычно достаточно уметь написать SELECT с фильтром, JOIN двух таблиц и GROUP BY, объяснить HTTP-методы и коды ответов и показать, как вы отправляете запрос в Postman и что проверяете в ответе.
Что отвечать на вопрос о зарплатных ожиданиях?
Назовите вилку, а не одну цифру, и опирайтесь на свежие открытые данные по рынку для своего уровня, а не на слухи. Добавьте, что готовы обсуждать сумму с учётом задач и условий. Отказ называть ожидания обычно выглядит хуже, чем спокойный аргументированный ответ.
Источники
- ISTQB Glossary — глоссарий терминов тестирования
- ISTQB: Certified Tester Foundation Level, программа v4.0
- Ken Schwaber, Jeff Sutherland: The Scrum Guide
- RFC 9110: HTTP Semantics — методы и коды состояния
- MDN: Using HTTP cookies
- MDN: Web Storage API
- Chrome DevTools documentation
- Postman documentation: Write scripts to test API response data
- SQLite documentation: SELECT
- Node.js documentation: Test runner
- Playwright documentation: Auto-waiting
- Playwright documentation: Locators
- Selenium documentation: WebDriver
- Martin Fowler: Test Pyramid
- Android Developers: Run apps on the Android Emulator
- Apple Developer: Running your app in Simulator or on a device
