Оцените себя по десятибальной шкале по бэкенду
Что проверяют
Калибровку и понимание, зачем тестировщику бэкенд. Ждут не число, а расшифровку: что именно вы умеете на стороне сервера. Заодно смотрят, отличаете ли вы умение проверять сервис от умения его писать. Для QA важно первое, и это стоит проговорить вслух.
Как отвечать
Назовите число из середины шкалы и сразу привяжите его к делу. Удобная структура: что делаю уверенно, что с помощью разработчиков, чего не делаю.
- уверенно: проверяю API по контракту, коды и тела ответов, обработку некорректных данных, авторизацию; хожу в базу запросами и сверяю состояние после операции; читаю логи и трассировки, воспроизвожу через консольный клиент, пишу автотесты на сервисном уровне;
- с поддержкой: разбираю поведение очередей, повторную доставку сообщений и идемпотентность обработчика, читаю код сервиса, чтобы понять ветку логики;
- не делаю: сами сервисы не пишу и не проектирую, схему базы и инфраструктуру не сопровождаю.
Отдельно уточните шкалу вслух: сравниваем с тестировщиком, пришедшим из ручной проверки интерфейса, или с бэкенд-разработчиком. Это не увиливание, а правильный вопрос, его обычно засчитывают. Закончите примером: дефект, найденный не через интерфейс, а по логам или по расхождению данных в базе.
Где спотыкаются
Называют девять или десять. Верхние оценки почти всегда влекут проверочный вопрос, и один разговор про транзакции или про идемпотентность повторной отправки превращает такую оценку в минус. Обоснованная средняя выглядит сильнее.
Второе: называют цифру и замолкают. Само по себе число интервьюеру бесполезно, он ждёт, из чего оно складывается, и пауза читается как отсутствие представления о собственных границах.
Третье: приравнивают бэкенд к умению программировать и занижают себя до двойки, хотя реально умеют многое: проверить контракт, воспроизвести проблему запросом, посмотреть состояние в базе, разобрать лог. Это и есть бэкенд для тестировщика, и говорить стоит именно об этом.