Планка для джуна-QA за 12 лет: что изменилось и зачем всё это на самом деле спрашивают

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

Это не легенда и не «рассказы про старые добрые времена». Это была нормальная практика. Людей не хватало, рынок рос быстрее, чем успевали обучать, и компании брали за способность думать, а остальное планировали доучить на месте.

Сегодня на ту же позицию просят техники тест-дизайна, понимание HTTP, умение написать SQL-запрос с join, базовое представление об XSS и SQL-инъекциях, опыт работы с Postman, а иногда ещё и «плюсом будет автоматизация».

Вопрос, который в такой ситуации возникает первым, — это вообще законно? Разберём честно: часть этих требований обоснована, часть нет, и различать полезно.

Почему планка поднялась

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

Изменилась сама работа. QA двенадцать лет назад — это в основном человек, который кликает интерфейс по сценарию и заводит баги. Сегодня тот же джун открывает DevTools, смотрит в Network, идёт в Postman проверить, что вернул бэкенд, и в базу — убедиться, что сохранилось. Не потому что так модно, а потому что продукт стал распределённым и половина дефектов живёт не на экране.

Сократилось время на обучение. Команды меньше, релизы чаще. Раньше джун мог полгода тихо врастать рядом с сеньором. Теперь от него хотят пользы со второго спринта, и компании пытаются купить эту готовность на входе.

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

Последний пункт важен, и о нём честно скажем в конце. Но сначала — о том, что попало в список не зря.

Зачем это спрашивают на самом деле

Техники тест-дизайна

Чаще всего их считают теорией ради теории: выучил эквивалентное разбиение, рассказал, забыл.

На деле техника отвечает на единственный вопрос, который вам зададут в работе: почему ты проверил именно это и почему этого достаточно.

Без техники ответ звучит как «ну я покликал основные сценарии». Это не аргумент — его невозможно ни проверить, ни оспорить. С техникой ответ такой: «поле принимает от 18 до 65, я проверил по одному значению из каждого класса и границы — шесть тестов вместо ста двадцати, и вот почему остальные ничего не добавят».

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

SQL

Самое распространённое недоразумение: «зачем тестировщику база, я же проверяю интерфейс».

Интерфейс показывает то, что нарисовал фронтенд. Он не показывает, что на самом деле записалось.

Классическая ситуация: пользователь сохраняет профиль, страница говорит «сохранено», вы идёте дальше. А в базе поле осталось пустым, потому что бэкенд вернул 200 на запрос, который ничего не изменил. Через неделю это находит клиент.

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

Реально нужный джуну объём невелик: select с where, сортировка, join на две таблицы, count и group by. Это не «знание SQL», это четыре конструкции.

API и HTTP

Здесь причина самая простая. Основная работа джуна-QA — не найти дефект, а локализовать его.

«Не работает» — это не баг-репорт. Разработчик потратит час, чтобы выяснить то, что вы могли выяснить за минуту: ушёл запрос или нет, что пришло в ответе, это 400 из-за ваших данных или 500 из-за их кода.

Отсюда и вопросы про статус-коды, и про DevTools, и про Postman. Это не эрудиция, это умение сказать, на чьей стороне проблема. Тестировщик, который это умеет, экономит команде часы каждую неделю — и именно поэтому это спрашивают на входе.

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

XSS, SQL-инъекции и базовая безопасность

Кажется самым «не для джуна» пунктом. Но причина здесь не в глубине, а в цене ошибки.

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

При этом простейшие проверки стоят ничего. Вставить <script>alert(1)</script> в поле имени и посмотреть, выполнится ли. Попробовать кавычку в поиске и увидеть, не упадёт ли запрос с ошибкой базы. Это чек-лист на пять пунктов, который делается за десять минут и закрывает самый дешёвый класс атак.

От джуна не ждут пентеста. Ждут, что он не пропустит очевидное.

Знание сред и логов

Вопросы про dev/staging/prod и про то, как посмотреть логи, тоже вызывают недоумение. Причина снова практическая: половина «багов» — это не баги, а неправильная среда, старый билд или конфиг.

Тестировщик, который перед заведением дефекта проверяет, на какой сборке он воспроизводится и что написано в логах, заводит меньше мусора. А мусор в трекере стоит команде дороже, чем кажется.

А что из этого — избыток

Теперь честная часть.

Вопросы про уровни модели OSI, репликацию в SQL Server, разницу между SIP и PRI на позиции джуна-мануальщика — это не проверка готовности к работе. Это либо списанный откуда-то перечень, либо попытка отсеять хоть как-то, когда откликов двести.

Признак здорового собеседования простой: на каждый вопрос интервьюер может ответить, как это понадобится в первый месяц работы. «Ты будешь проверять данные в базе» — может. «Ты будешь настраивать репликацию» — на джуновской позиции вряд ли.

Если на собеседовании таких вопросов большинство, это говорит не о вас, а о процессе найма в компании. И это нормальная причина не жалеть об отказе.

Что с этим делать

Планка не опустится — прежнее соотношение людей и вакансий не вернётся. Но список реально нужного значительно короче, чем выглядит в вакансиях.

Минимум, который закрывает большинство джуновских собеседований:

• Тест-дизайн — эквивалентное разбиение, границы, таблица решений. С готовыми примерами на конкретных полях, а не определениями.
• HTTP — методы, классы статус-кодов, вкладка Network в DevTools, умение сказать, на чьей стороне ошибка.
• API — Postman, GET и POST, чтение ответа, проверка того, чего нет в интерфейсе.
• SQL — select, where, order by, join, count с group by. Четыре конструкции.
• Безопасность — чек-лист из пяти пунктов: XSS в полях ввода, кавычка в поиске, доступ к чужой записи по id в URL, маскирование пароля, сообщение об ошибке, не раскрывающее существование логина.
• Баг-репорт — и понимание, что предусловия важнее скриншота.

Это несколько недель сосредоточенной подготовки, а не год обучения. Основная часть отказов случается не потому, что человек этого не знает, а потому что знает в формате «слышал об этом», а не «могу применить и объяснить зачем».

И последнее. Каждый пункт выше стоит уметь сказать вслух. Написанный в конспекте ответ выглядит полным; произнесённый впервые на собеседовании рассыпается. Это не проблема знаний, и чтением она не лечится.

---

Если нужен материал для подготовки — у нас собраны вопросы для Manual QA с разборами ответов, отдельно для junior и middle — читать можно свободно. А чтобы проговорить ответы вслух и услышать оценку, нужен аккаунт: три интервью в месяц бесплатны.