«Я прошел через множество собеседований и, общаясь с коллегами, заметил общую закономерность во многих собеседованиях по QA. Они, как правило, фокусируются на несущественных деталях, погружаясь в сухую теорию, вместо того чтобы задавать действительно важные вопросы.
Но чтобы «подготовить сцену», давайте сначала определим, что для меня означает каждый уровень опыта в QA.
Junior: Имеет твердое представление о теории QA и обычно следует установленным процессам. Он все еще нуждается в менторе и должен больше слушать на митингах. Ему еще предстоит многому научиться.
Middle: Работают самостоятельно и не нуждаются в наставничестве, способны взять на себя ответственность за фичу или небольшой продукт. Они вносят больше предложений во время митингов, высказывая свои предложения и опасения. Способны писать сквозные автоматизированные тесты и менторить джунов.
Senior: Обладают глубоким пониманием всей системы и имеют собственные представления о том, как она должна работать. Менторят миддлов и джунов. Они могут выявлять недостатки в архитектуре и предлагать решения. Являются экспертами в автоматизации тестирования. Основным направлением их работы является долгосрочное улучшение качества и процессов тестирования.
Давайте представим, что мы проходим собеседование и начинаем с вопросов следующего типа:
- Какой тип документации вы используете для подобных целей?,
- Что такое тест-кейс/тест-план/баг/…?,
- Что вы знаете о таком-то типе тестирования?
Поймите меня правильно, понимание теории тестирования остается крайне важным, и никто не может позволить себе нанять человека, который не знает, как правильно написать баг-репорт.
Подход, которого я стараюсь придерживаться, заключается в следующем: Я стараюсь дополнить эти легкие вопросы контекстом, и ситуациями, чтобы понять, сможет ли претендент на должность использовать полученные знания, а не просто знать теорию тестирования.
И, конечно, я ожидаю разных ответов в зависимости от уровня претендента.
Знания — это лишь инструмент; важно то, насколько эффективно вы его используете.
Важно понимать, что на некоторые вопросы нет единственно правильного ответа; их цель — проверить мышления кандидата. Одной из главных целей беседы на собеседовании должно быть знакомство, и определение того, хотели бы вы работать с этим человеком в команде.
И это относится к обеим сторонам процесса собеседования. Кроме того, необходимо оценить, насколько быстро кандидат сможет обучаться и адаптироваться к потребностям продукта.
А сейчас самое время ознакомиться с примерами вопросов.
Вопрос 1: Читаете ли вы статьи о тестировании, разработке, посещаете ли конференции? Расскажите нам, как вы учитесь.
Это один из моих любимых вопросов, потому что многие кандидаты не готовят ответ заранее. Если у кандидата нет собственного плана обучения, это может быть тревожным сигналом.
Если человек читает статьи, книги, и активно пытается совершенствоваться, это очень положительный сигнал для его вхождения в команду.
Постоянное обучение — показатель желания расти.
Вопрос 2: Расскажите о своем последнем месте работы. Каков был размер команды, и как вы в ней работали?
Этот вопрос задается, чтобы лучше понять биографию кандидата. Его цель:
- Оценить опыт работы кандидата в различных структурах.
- Проверить, насколько много и с кем кандидату приходилось общаться и сотрудничать.
- Понять, с какими структурами и процессами работал кандидат.
- Определить объем роли кандидата в команде.
У каждой команды своя структура и свои обязанности. С точки зрения интервьюера, этот вопрос должен выяснить, насколько хорошо вы впишетесь в коллектив.
Вопрос 3: Каков был ваш вклад в работу команды?
Этот вопрос должен показать сильные стороны кандидата и то, какой вклад вы внесли в работу на последнем месте. Лично я стараюсь думать об этом перед каждым собеседованием и даже делать заметки, потому что это легко забыть, если вы немного нервничаете.
Вопрос 4: Что вы думаете об идеальном соотношении QA и разработчиков?
В ходе этого обсуждения вы можете ожидать уточняющих вопросов, например, о том, есть ли в компании какая-то особая система автоматизации и насколько велик и сложен продукт. Даже получив ответы на эти вопросы, бывает сложно назвать конкретную цифру.
На самом деле нет правильного ответа, но определенно могут быть неправильные. Например, если кандидат говорит что-то вроде «четыре QA на одного разработчика и точка». В конечном итоге идеальное соотношение зависит от конкретной ситуации в компании, сложности проекта и многих других факторов. Здесь нужно проявлять гибкость и кругозор.
Вопрос 5: Должен ли мобильный QA разбираться в автоматизации или разработке?
Это зависит от структуры команды, но я убежден, что не должно быть резкого разделения между Automation QA, Manual QA и SDET.
Это означает, что QA должен быть человеком, который делает все, что поможет команде повысить или хотя бы удержать качество продукта (даже если вам нужно разработать совершенно новый QA-инструмент для вашей команды).
Вопрос 6: Как вы решаете, какой тест автоматизировать? Вы автоматизируете баги?
Это один из моих любимых вопросов, связанных с автоматизацией. Лично я рассматриваю фреймворк автоматизированного тестирования как способ быстрой проверки работоспособности всего приложения (в течение часа).
Набор инструментов автоматизации должен быть максимально быстрым и надежным и охватывать как можно больше критических фич.
Красным флажком здесь будет, если кандидат хочет автоматизировать абсолютно всё — критические сценарии, баги и все тест-кейсы.
Во-первых, время, необходимое для поддержания системы, в которой всё автоматизировано, будет значительным. Во-вторых, общее время работы огромного набора значительно увеличится.
Вопрос 7: Представьте, что вы присутствуете на доработке новой фичи, а PO/PM представляет то, что точно не будет работать. Что бы вы сделали?
Этот вопрос направлен на выявление навыков решения проблем и умения кандидата общаться «в целом».
Красным флажком будет, если кандидат предпочтёт промолчать. QA должен всегда чётко общаться и как можно раньше высказывать свое мнение и опасения по поводу качества. Для разработки выдающегося продукта с хорошим качеством очень важно сотрудничество между ролями.
Вопрос 8: Представьте себе другую ситуацию. Вы обнаружили критический баг прямо перед релизом. Он затронет многих пользователей, когда команда выпустит новую версию приложения. Как бы вы с этим справились?
Сильный ответ продемонстрирует ясность в общении. Например, кандидат может объяснить, какие шаги он предпримет: создаст тикет, опубликует его в соответствующем канале связи по релизу, или обсудит срочность проблемы с разработчиками и владельцем продукта. Как только багфикс будет готов к тестированию, важно приостановить другие работы и перепроверить фичу, чтобы убедиться, что релиз не откладывается.
Вопрос 9: Представьте себе ситуацию, когда вы были в отпуске и только что вернулись. Ваша команда оставила вам подарок — 15 тикетов в колонке QA. Как бы вы расставили приоритеты в своей работе?
Сначала я бы запустил автоматизированные тесты (если они у нас есть), чтобы убедиться, что ничего не сломано. Как только они будут запущены, я пойду и поговорю с PO/PM, чтобы понять сроки и текущие приоритеты, и задам следующие вопросы:
- Какая фича должна быть выпущена первой, и какие у нас сроки?
- Были ли какие-то важные новости за последние X недель, о которых я должен знать? Потому что я был в отпуске, возможно, что-то пропустил.
Как только я получу эту информацию, я просмотрю тикеты в колонке QA, сосредоточившись на самых важных.
Я бы определил приоритетными пункты, связанные с фичей, полученной от владельца продукта, а следующим приоритетом стали бы такие пункты, как обновления SDK, тикеты на рефакторинг и те, которые, как уже известно, обычно вызывают проблемы.
Вопрос 10: Этот вопрос больше относится к формальной теории и может быть задан даже миддлу. Приходилось ли вам выполнять исследовательское тестирование? Что можете сказать о его преимуществах и недостатках?
Преимущества:
- Можно обнаружить множество проблем и крайних случаев.
- Оно позволяет максимизировать покрытие, особенно в случае жесткого графика релиза.
Недостатки:
- Менее структурированное и организованное, что может привести к пропуску багов, которые более формальный подход к тестированию мог бы выявить.
- Некоторые найденные баги бывает трудно воспроизвести.
В целом, это весьма эффективный способ тестирования, особенно если использовать его вместе со структурированными методами тестирования. Однако этим не любят заниматься, кто любит иметь подробный план для каждого действия.
Вопрос 11: Каковы ваши амбиции? Как вы видите свой рост?
Это важный вопрос для команды, она должна понять кандидата. Иногда кандидат хорошо отвечает на все вопросы, но тот путь, по которому он хочет развиваться, отличается от того, что мы можем ему предложить. В итоге мы говорим ему «нет» — но это спасает кандидата от разочарования и потенциального ухода через год.
Мы все взрослые люди, и для идеальной совместимости полезно согласовывать ожидания.
В заключение я хочу подчеркнуть, что кандидатам очень полезно перед собеседованием поразмышлять о своем опыте и вспомнить интересные ситуации из своей работы.»
