64 QA Interviews Stream. 07.05.2022 at 08:45 GMT(UTC) +3
Запись тренировочного стрима QA с разбором ответов кандидатов и практическими комментариями ведущего. Темы охватывают самопрезентацию, API и клиент-серверную архитектуру, тестирование оборудования, тест-дизайн, базы данных, Linux и Git.
Трёхчасовой стрим посвящён тренировочным собеседованиям по QA: перед интервью ведущий объявляет новый поток обучения, конференцию и возможность практики на реальных проектах. Затем он разбирает самопрезентацию и технические ответы нескольких кандидатов, спрашивая о REST API, JSON, HTTP, клиент-серверной архитектуре, локализации дефектов, тест-дизайне, базах данных, Linux и Git. На примере печатного оборудования обсуждаются сбор требований, критический путь, позитивные и негативные сценарии; отдельно ведущий связывает ценность QA с работой критичных для бизнеса пользовательских функций, а не с числом найденных багов.
Прошлый опыт можно представлять как релевантный для QA через конкретные задачи: сбор требований, приёмку функциональности, описание инцидентов, работу с пользователями и проверку результата.
Если документации нет, кандидат предлагает источники требований: пользователей и стейкхолдеров, конкурентные продукты, нормы и законы, собственный опыт и исследования; затем явно обозначает границы своей экспертизы.
Отвечая про REST API и JSON, стоит быть готовым раскрыть термины глубже: схему Body, названия ключей, обязательность полей, типы значений, endpoint и ожидаемую сервером структуру.
Для локализации случая, когда форма отправляет пять полей, а в БД сохраняются четыре, нужно проверить запрос в DevTools, Body и его схему, endpoint, обработку на backend, логи и фактическое хранение в БД.
При тестировании оборудования или незнакомого продукта сначала нужно уточнить требования и конфигурацию, затем пройти критический путь от входа до ожидаемого результата и дополнить его негативными сценариями.
Ведущий подчёркивает, что результат QA измеряется работоспособностью критичных бизнес-сценариев — например, возможностью клиента оплатить заказ, — а не количеством баг-репортов или чек-листов.
Для собеседования полезно перечислять варианты тестов и сценариев до тех пор, пока интервьюер не остановит, а не завершать ответ после первого очевидного варианта.