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

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

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

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

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

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

Я предлагаю рассмотреть несколько открытые вопросы вроде этого:

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

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

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

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

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

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

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

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

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

Отношение

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

Навыки

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

Знания

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

Доступность

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

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

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

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

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