Какие вопросы для интервью разработчик должен задать тестеру? - PullRequest
8 голосов
/ 27 августа 2009

У нас есть несколько интервью, в рамках которых мы набираем на должность по обеспечению качества. Цель участия разработчиков - понять, будет ли человек хорошо работать с командой разработчиков.

Каковы наиболее важные вопросы, которые разработчик должен задать специалисту по обеспечению качества? Я ищу практические вопросы больше, чем пушистые открытые вопросы, ваши мысли?

Ответы [ 6 ]

10 голосов
/ 27 августа 2009

К сожалению, иногда пушистые открытые вопросы дают вам лучшее представление о человеке.

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

Вам необходимо установить, что:

  • человек будет хорошо работать в команде.
  • человек будет нести ответственность за работу с разработчиками, чтобы исправить ошибки, а не просто "Вот ошибка, исправьте ее, а затем вернитесь ко мне".
  • Эго человека не помешает работе команды (например, борьба за классификацию или серьезность ошибок). Я нахожу, что это обычно большая проблема с разработчиками, которые защищаются от "своего" кода.

Я считаю, что наилучший подход к собеседованию - представить сценарии и спросить кандидата, что они думают, например:

  • Сегодня пятница, 16:00, и Боб, разработчик, согласился вернуться к работе, чтобы исправить ошибку с высокой степенью серьезности. Нам нужен тестер, чтобы подтвердить исправление, и вы единственный, кто есть, но у вас был ужин. Что бы вы предложили?

Только по ответу на этот вопрос в одиночку вы можете оценить, является ли кандидат:

  • бесполезно («Извините, я не могу пропустить ужин»).
  • думает о внешних ограничениях («Есть ли действительно , других тестеров нет в наличии?», «Могу ли я проверить это в субботу утром?», «Может ли Боб работать в другой раз в выходные?»).
  • адаптируется («Я мог бы отложить ужин только один раз»).

и т. Д.

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

9 голосов
/ 27 августа 2009

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

Можете ли вы вести себя как обычный или неопытный пользователь?

Теперь, это кажется глупым, но это дает очень хорошее понимание. Если кандидат говорит «да», откровенно говоря, это не то, чем он кажется. Ни один человек, работающий в области информационных технологий в области разработки (в частности), анализа или тестирования, не может сделать это; просто за то, что мы находимся далеко от уровня неопытного пользователя. Тогда вам нужно найти ответ:

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

Или производный от этого. Это показывает некоторую важную информацию.

  1. Они реалистичны
  2. Они могут мыслить нестандартно
  3. Они готовы выполнять надлежащие методы, установленные в QA

Это то, что я нашел, по крайней мере.

Надеюсь, это так или иначе поможет.

6 голосов
/ 28 августа 2009

Я бы предложил рассмотреть несколько открытых вопросов, таких как:

Если бы я подошел к вам и сказал: «Мог бы Вы тестируете эту новую вещь, которую я сделал? "Что будут ваши первые несколько вопросов?

Вот несколько мыслей, которые я хотел бы задать:

  1. Есть ли упоминание о технических требованиях или требованиях? Если их нет, как это повлияет на тестирование?
  2. Они хотят, чтобы я спарился с ними, чтобы они могли знать, что я сделал?
  3. Они хотят знать, что я сделал?
  4. У них есть время, чтобы сделать это и спросить, сколько, я думаю, это может занять?
  5. Какого рода тестирование вы ожидаете: комплексное тестирование на дым, удобство использования в коридоре?
  6. Какие инструменты будут использоваться для этого?

При записи ошибки, что такое минимальная информация, которую вы считаете Разработчик должен иметь перед исправлением это?

Это тип вопроса, в зависимости от того, какой фон они имеют, вероятно, будет фактором в их ответе, поскольку несколько вещей, на которые следует обратить внимание, будут включать следующее:

  • Воспроизводимость - Можете ли вы получить это предсказуемым образом?
  • Шаги воспроизводимости
  • Это ошибка кода, данных, сети или другого типа?
  • Насколько серьезна ошибка в некотором масштабе?
  • Окружающая среда - что мне нужно, чтобы это повторилось? Есть ли у меня какие-то особые браузеры, операционные системы или другие вещи?
  • Какие ожидаемые и фактические результаты показывают, что это ошибка?
  • Версия программного обеспечения - это было найдено в какой сборке системы?

Я упоминаю большинство из них, потому что именно об этом я и подумал, задавая вопрос о том, какие параметры у них изначально есть, когда задается неопределенный вопрос или запрос, который должен содержать больше деталей, но какие детали имеют значение, так это проблема. Я бы также отметил, сколько времени потребовалась пауза для ответа, где я сказал бы, что 15-30 секунд - это нормально, что-то меньшее, и я бы подумал, что это ожидаемый вопрос, и если нужно больше, чем это, то следует попросите пару минут подумать об этом, поскольку весь смысл в том, что когда возникает такая ситуация, каковы ожидания каждой стороны?

Другой идеей было бы упомянуть, какую методологию разработки программного обеспечения вы используете, а затем спросить, какие проблемы связаны с QA при использовании этого подхода? Например, если разработчики используют TDD, как это влияет на QA? Что если это более водопадный подход? Здесь вы хотите увидеть, насколько хорошо они могут думать на своих ногах, а также какие дополнительные вопросы о том, что используется, задаются так, как на самом деле, если я скажу, что мы используем Scrum, насколько хорошо это определяет реализацию общего концепции Scrum, действительно.

3 голосов
/ 27 августа 2009

Разработчик может проверить, предоставив ему сценарий, который должен проверить следующее

Отношение

Есть ли у тестера испытательное отношение? Дайте ему сценарий и проверьте, сколько действительных вопросов он / она задает?

Навыки

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

Знание

Проверьте ширину и глубину тестера в той области, где вы собираетесь нанять тестера. Даже если тестер не работает с текущим полем, проверьте, сколько тестер знает об этом поле.

Доступность

Дайте тестировщику сценарий, как будто есть проблема с клиентом, и разработчик находится в отпуске всю неделю. Проблема должна быть срочно обострена, и в качестве тестера вам нужно было найти ее причину. Как вы подойдете в такой ситуации

2 голосов
/ 27 августа 2009

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

  • общение - может ли кандидат писать / отправлять по электронной почте / говорить в четкой и сжатой форме, чтобы другие члены команды могли понять обнаруженный ими дефект
  • решение проблем - Здесь вам пригодятся вопросы-загадки для интервью. С этими типами вопросов, более важно узнать, как кандидат будет решать проблему, а не как близко они будут определять «сколько синих автомобилей в США».
  • ответственность - Важно понимать, выполнит ли кандидат до конца. На этот вопрос сложнее найти верный ответ, поскольку люди во время интервью с энтузиазмом могут соглашаться на многое, но на самом деле это не так. Прошлые истории кандидата о том, как они справились с проблемой или проблемой, могут быть полезны. Бонусные баллы, если проблема ухудшилась для кандидата, и он остался на вершине.
  • техническая экспертиза - Требуемый уровень для этого предмета будет варьироваться в зависимости от тестера: будут ли они писать автоматические тесты? Ручное тестирование? Автоматизированные тесты требуют, по крайней мере, некоторой степени технической экспертизы, в то время как ручное тестирование потребует меньше. В любом случае наличие тестера, который хотя бы знаком с техническими аспектами приложения, может быть очень полезным при работе над проблемой.
1 голос
/ 27 августа 2009

Я думаю, что это действительно зависит от типа тестера, который вы ищете. Вы ищете кого-то, кто будет нажимать на кнопки и говорить, что он не выглядит правильно, или вы ищете кого-то, кто может понять технологию или даже код и найти более глубокие ошибки? Как разработчик в цикле собеседований, я бы предположил, что существуют также традиционные типы QA. Если это так, они будут задавать типичные вопросы теста. Вы должны понять, насколько они технические и как они будут взаимодействовать. Имея это в виду, попробуйте ответить на следующие вопросы:

  1. Вопросы программирования. Посмотрите на резюме. Они знают C #? Javascript? Попросите их написать что-нибудь для вас. Чем больше они знают, тем больше ошибок они смогут регистрировать.
  2. Обработка вопросов. Они понимают систему контроля версий? Они использовали это? Получают ли они концепцию сборки? Они знакомы с модульным тестированием?
  3. Вопросы по разработке программного обеспечения. Они понимают, что такое dll / assembly / jar? Они знают, как работает память? Понимают ли они разницу между режимом пользователя и режима ядра (или тем, что подходит для вашего домена)?
  4. Технологические вопросы. Насколько хорошо они понимают ваш домен? Они понимают, что движет индустрией виджетов? Знают ли они, что ищут клиенты виджетов? Они когда-нибудь использовали виджет?
  5. Они понимают свои ошибки на глубоком уровне? Спросите о своей любимой ошибке. Сколько деталей они могут рассказать о том, что пошло не так?
  6. Могут ли они противостоять вам? Это тот тип или тестер, который отступит, когда на него нападает dev, или они будут сражаться? Спросите их о времени, когда они пытались что-то сделать и встретили оппозицию. Как они отреагировали?
...