Мы нанимаем специалиста по обеспечению качества, и я должен задать несколько вопросов для интервью. Правда в том, что я не знаю много о том, что должен знать хороший инженер по обеспечению качества, и тем более о том, что могут включать хорошие вопросы об интервью. У кого-нибудь есть предложения?
Немного информации: среда представляет собой два отдельных (но переплетенных) веб-приложения для стека Microsoft (ASP.NET, SQL Server, IIS).
Ответы:
Если у вас нет большого опыта работы с тестировщиками, прочитайте первые несколько глав «Тестирование компьютерного программного обеспечения» Cem Kaner, чтобы понять, какие термины вы хотите услышать: тестирование границ, тестирование ошибок, тестирование «счастливого пути», функционал, производительность, безопасность, интеграция и т. д. Если вы не говорите на языке, вы не сможете провести хорошее интервью.
Дайте им спецификацию для небольшой части вашей системы. Попросите их проверить это. Вы ищете организацию мышления и умение придумывать интересные тесты. Вы хотите, чтобы они разбили области тестирования упорядоченным образом, а затем углубились в каждую область, разработав все больше и больше интересных тестовых случаев. Действительно хорошие тестировщики могут делать это часами со всеми, кроме самых тривиальных проблем, поэтому вам, возможно, придется их отключить и перевести их в другую категорию, чтобы лучше понять, как они думают.
Опишите поведение, вызванное реальной ошибкой в вашей системе, которая была довольно трудной для понимания. Спросите их, что они будут делать, если увидят эту ошибку во время тестирования. Здесь вы ищете уменьшение ошибок - возможность найти простейший набор обстоятельств, которые могут воспроизвести ошибку. Это значительно упрощает отладку для разработчиков, так как они имеют более точное представление о том, что вызвало проблему, и демонстрируют четкую способность решать проблемы и четкое понимание того, какие факторы могут взаимодействовать, вызывая ошибки. С вашим конкретным продуктом обсуждение условий гонки может быть увлекательным.
Дайте им простую программу командной строки, которую вы взломали вместе (возможно, с ошибками), и простую спецификацию, и пусть они сядут за компьютер и поиграются с ним, чтобы найти проблемы. Здесь вы ищете креативность и способность нацеливаться на проблемные зоны. Они должны проверять такие вещи, как большие входы, маленькие входы, странные входы, пустые входы. Если они найдут ошибку, попросите их попытаться выяснить, когда именно эта ошибка возникла (опять же, с уменьшением ошибки!).
Спросите их, что они будут делать, если SDE ответит на ошибку «Нет репро» или «Не будет исправлено», если они думают, что ошибка важна. Здесь вы ищете кого-то, кто не будет просто слабаком, но и не будет противником. Разумные ответы включают добавление примеров сценариев, которые более четко демонстрируют серьезность ошибки, а затем повторное открытие заявки, беседа с разработчиком, чтобы попытаться понять, почему все было решено таким образом, перед закрытием и т. Д.
Поговорите с ними о вашем заявлении на высоком уровне. Спросите их, какие виды тестирования они хотели бы выполнить. Здесь вы найдете общие области тестирования, такие как тестирование функциональных компонентов, интеграционное тестирование, тестирование производительности, тестирование безопасности.
Если это SDET / инженер по автоматизации, дайте им несколько вопросов об интервью для разработчиков, имеющих примерно от 1/3 до половины их общего опыта работы.
Если это ваш первый специалист по обеспечению качества, убедитесь, что он может начать самостоятельно. Спросите их, как они себе представляют свою первую неделю или месяц работы. Они должны что-то сказать о сборе требований и настройке инструментов, а затем описать разумный подход к началу тестирования. Вы ищете человека, которому не нужен начальник, который скажет им, как начать тестирование, и сможет самостоятельно управлять. Если у вас уже есть персонал QA, это менее важно.
Когда я беру интервью у кандидатов в QA, я делаю, чтобы они набросали стратегию тестирования для приложения. Я обычно даю им свой телефон и выбираю приложение с ограниченными возможностями - или позволяю им выбрать то, с чем они более знакомы. Когда они перечисляют стратегию высокого уровня (некоторые не могут), я мог бы попросить их развернуть список и перечислить несколько тестовых случаев.
После этого я мог бы дать им сценарий, в котором у нас ограничены ресурсы, и посмотреть, как они расставляют приоритеты.
Я также спрашиваю их, когда программное обеспечение достаточно хорошо для поставки, как справляться с ситуациями, когда PM или dev не считают ошибку важной, но они это делают. Типичные сценарии разработки продукта.
Это для некодирующих позиций QA. Кодируя позиции QA, я даю им комбо-интервью dev / test.
Спросите их, как они будут разрабатывать планы испытаний. Спросите их, имеют ли они опыт использования регрессионного тестирования и как они это сделали, если это так. Спросите их, как они тестируют пользовательский интерфейс. Спросите их, как они будут проводить тестирование импорта данных, которые не проходят через пользовательский интерфейс (если вы делаете такие вещи). Спросите их, как они будут сообщать разработчикам о своих проблемах и как они будут проверять решение проблемы. Я бы спросил их о самой интересной (или самой трудной для поиска) ошибке, которую они нашли, и о том, как они ее нашли.
Прежде чем начать собеседование, поищите несколько книг по тестированию и немного о том, что должен делать специалист по контролю качества. Это поможет вам оценить их ответы.
Кроме того, вы также ищете хорошую индивидуальность. Вы не хотите, чтобы QA человек был слабым, но вы также не хотите хулигана или придурка. Но вам нужен кто-то, кто будет противостоять руководству, когда что-то не так, а не просто одобрять все, потому что руководство хочет уложиться в срок. Вам нужен кто-то, кто будет эффективно работать с разработчиками и кто понимает требования того, что они тестируют. Кто-то с некоторым опытом в типе приложения, которое вы тестируете, может быть хорошим. Тестер, имеющий опыт работы в сфере здравоохранения, будет знать, что нужно проверить, а кто-то из другой области может не знать об этом.
Я думаю, вы не можете ожидать, что они будут иметь серьезные знания технологии - тот, кто имеет, скорее всего, откажется работать в качестве мирского тестера.
Лучшее, что вы можете сделать, - это искать общие вещи, такие как внимание к деталям, пытливый ум, энтузиазм к экспериментам и так далее.