Каковы хорошие требования для инженера QA? [закрыто]

9

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

Немного информации: среда представляет собой два отдельных (но переплетенных) веб-приложения для стека Microsoft (ASP.NET, SQL Server, IIS).

kelloti
источник

Ответы:

9

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

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

Опишите поведение, вызванное реальной ошибкой в ​​вашей системе, которая была довольно трудной для понимания. Спросите их, что они будут делать, если увидят эту ошибку во время тестирования. Здесь вы ищете уменьшение ошибок - возможность найти простейший набор обстоятельств, которые могут воспроизвести ошибку. Это значительно упрощает отладку для разработчиков, так как они имеют более точное представление о том, что вызвало проблему, и демонстрируют четкую способность решать проблемы и четкое понимание того, какие факторы могут взаимодействовать, вызывая ошибки. С вашим конкретным продуктом обсуждение условий гонки может быть увлекательным.

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

Спросите их, что они будут делать, если SDE ответит на ошибку «Нет репро» или «Не будет исправлено», если они думают, что ошибка важна. Здесь вы ищете кого-то, кто не будет просто слабаком, но и не будет противником. Разумные ответы включают добавление примеров сценариев, которые более четко демонстрируют серьезность ошибки, а затем повторное открытие заявки, беседа с разработчиком, чтобы попытаться понять, почему все было решено таким образом, перед закрытием и т. Д.

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

Если это SDET / инженер по автоматизации, дайте им несколько вопросов об интервью для разработчиков, имеющих примерно от 1/3 до половины их общего опыта работы.

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

Этель Эванс
источник
1
И всегда есть стереотипный вопрос теста MS. , , "Как бы вы проверили эту ручку?" Это эквивалент SDET "Почему крышка люка круглая?"
Этель Эванс
+1 Отличный ответ - особенно включая пробное прослушивание. Некоторые люди звучат великолепно, когда говорят, но единственный способ по-настоящему оценить тестера - это заставить его пройти тестирование.
testerab
1
Да . , , Моя первая работа вне колледжа была получена, потому что меня попросили сесть и протестировать приложение-календарь в Windows XP в течение 3 минут, и я обнаружил ошибку интеграции с MS Outlook. Человек, попросивший меня проверить, допустил ошибку, позволив мне использовать его рабочую машину, и, по-видимому, мне удалось испортить его настройку :-p
Этель Эванс,
По вашему мнению, кто-то, чья работа сосредоточена исключительно на автоматизации тестирования? то есть: разработчики пишут свои модульные тесты, и их основной задачей является их автоматизация и запуск, генерация отчетов и т. д. (больше разработки инструментов и систем, чем ручное тестирование или создание тестовых случаев). Какими должны быть их конкретные обязанности и что вы ожидаете от них с точки зрения обеспечения качества? Какова грань между их обязанностями и обязанностями разработчиков?
K-RAN
1
@ K-RAN, философия, которая мне нравится больше всего для баланса ответственности разработчиков и разработчиков за качество, заключается в следующем: «Разработчики начинаются с уровня 1 фут, а тестеры начинаются с уровня 10000 футов и встречаются где-то посередине. Если тестеров меньше, что где-то будет выше, может быть, даже при системной интеграции; если будет больше тестеров, этот уровень будет ниже, и, может быть, чуть выше модульных тестов ». Если вы действительно ищете долгосрочную работу инструментов и систем - нет мнения экспертов о качестве тестов, реальных тестирований и т. Д., То нанимайте, как если бы вы нанимали разработчика на эту роль.
Этель Эванс
6

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

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

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

Это для некодирующих позиций QA. Кодируя позиции QA, я даю им комбо-интервью dev / test.

rreeverb
источник
Пожалуйста. Удачи =)
rreeverb
Я добавил этот подход в свои собственные тестовые интервью. Спасибо.
Этель Эванс
3

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

Прежде чем начать собеседование, поищите несколько книг по тестированию и немного о том, что должен делать специалист по контролю качества. Это поможет вам оценить их ответы.

Кроме того, вы также ищете хорошую индивидуальность. Вы не хотите, чтобы QA человек был слабым, но вы также не хотите хулигана или придурка. Но вам нужен кто-то, кто будет противостоять руководству, когда что-то не так, а не просто одобрять все, потому что руководство хочет уложиться в срок. Вам нужен кто-то, кто будет эффективно работать с разработчиками и кто понимает требования того, что они тестируют. Кто-то с некоторым опытом в типе приложения, которое вы тестируете, может быть хорошим. Тестер, имеющий опыт работы в сфере здравоохранения, будет знать, что нужно проверить, а кто-то из другой области может не знать об этом.

HLGEM
источник
-1

Я думаю, вы не можете ожидать, что они будут иметь серьезные знания технологии - тот, кто имеет, скорее всего, откажется работать в качестве мирского тестера.

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


источник
какие-нибудь любимые вопросы или особенности?
Келлоти
4
Это зависит от того, где вы живете. Я сталкиваюсь с тем, что все больше и больше разработчиков переходят на тестирование из-за его уникальных задач и лучших перспектив карьерного роста, но я нахожусь в очень сложной программной области. Хорошее тестирование не является чем-то простым, и если вы платите достаточно и имеете среду, в которой уважаемые опытные тестировщики равны опытным разработчикам, то вы можете получить тестировщиков рок-звезд, которые знают свое дело.
Этель Эванс
2
Это скорее говорит о том, в каких компаниях вы работали, чем о тестировщиках в целом. Как говорит Этель, вы получаете то, что ожидаете - если вы ожидаете, что ваши тестеры будут обыденными и будут платить соответственно, вы просто не будете привлекать действительно квалифицированных тестеров.
testerab