Какие вопросы на собеседовании разработчик должен задать тестировщику?

Question

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

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

Answer 1

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

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

Вам нужно установить, что:

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

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

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

Основываясь только на ответе на этот вопрос, вы могли бы оценить, подходит ли кандидат:

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

и так далее.

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

Answer 2

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

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

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

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

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

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

По крайней мере, это то, что я нашел.

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

Answer 3

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

Если бы я подошел к вам и сказал: "Не могли бы вы протестировать то новое, что я сделал?" какими были бы ваши первые несколько вопросов?

Вот несколько мыслей, которые у меня возникли бы, задавая этот вопрос:

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

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

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

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

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

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

Answer 4

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

Отношение

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

Навыки

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

Знание

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

Доступность

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

Answer 5

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

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

Answer 6

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

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