Надеюсь, что будет полезным при проведении собеседований.
Ниже представлен небольшой список теоретических вопросов, которые иногда задаю на собеседованиях. Позже опишу процесс собеседования более подробно(этапы, вопросы, задания).
Вопросы на сообразительность
Сколько необходимо произвести кукол, чтобы удовлетворить спрос в куклах 1 млн города?
Сколько теннисных мячей влезет в автобус?
Как будете тестировать эскалатор/верёвку/будильник?
Подсчитайте примерную площадь застройки г. N в % от площади РФ
Как объясните свою работу человеку, не знакомого с тестированием?
Напишите формулу вычисления угла между часовой и минутной стрелками на часлах?
Как вы готовились для интервью?
Сколько ступенек на лестнице, по которой вы поднимались к нам?
Ситуационные вопросы
Ситуация: вам необходимо производить тестирование приложения, которое очень часто обновляется с минимальными изменениями (примерно раз в 2 дня или чаще). Как бы вы тестировали данное приложение, чтобы минимизировать свои трудозатраты?
Ситуация: вам необходимо протестировать кнопку “старт” в веб-приложении, кнопка находиться на 3-ей по счёту странице, начиная со стартовой? Как вы будете тестировать этот функционал?
Ситуация: Есть проект, для которого написано 500 тестов. Приходит заказчик и говорит, что хочет продать продукт и должен быть уверенным, что он рабочий. И хочет, чтобы вы прогнали все эти тесты. Как вы оцените трудозатраты (кол-во дней/часов) и как будет общаться с заказчиком по этому поводу?
Ситуация: Вы попали на новый проект и вы единственный тестировщик на нём. С чего вы начнёте в первую очередь?
Ситуация: У вас есть приложение, которое вычисляет среднее значение оценок студента. Какие входные параметры нам необходимо будет проверять?
Ситуация: Представте, что вы Менеджер, как вы будетете оценивать работу тестировщика на ревью? По каким критериям?
Общие вопросы на темы
Как вы планируете тестирование приложения?
Жизненный цикл разработки приложение и тестирование в нём. Когда необходимо начинать тестировать?
Дизайн тест кейсов, планов и прочих артефактов. Приходилось ли их разрабатывать?Что такое тестирование сверху вниз и снизу вверх ?
Анализ требований, тест кейсов, результатов тестирования, отчётов об ошибках. Как вообще определяете, что необходимо тестировать?
Знаете ли что-нибудь о классах эквивалентности?
Как определить, что тестирование закончено?
Типы тестов (exploration/script, ручное/автоматизир, функц/нагруз/безопасности). Какие из них применяли? В чём они выражались?
Жизненый цикл дефектов (ошибок). Что включаете в ошибку при её описании?
Как будете тестировать приложение, если для продукта нет документации?
Как вы определяете эталонные результаты?
Что такое тестовое окружение?
Расскажите о методологиях тестирования
Опишите любой дефект, который вы помните. Вспомнитие ваш самый “лучший” баг.
Каков смысл тестирования в процессе разработки?
В чём разница между валидацией и верификацией?
Что по вашему является хорошим требованием?
В чём смысл автоматизации тестирования? Когда она необходима и что необходимо тестировать? Каковы на неё трудозатраты? Нужна ли автоматизация вообще?
Каковы минусы полной автоматизации тестирования ?
Что вам нравиться/не нравиться в вашей работе?
Как вы организуете свой процесс работы?
В чём различие тестирования методом чёрного/белого/серого ящика? Какой из методов лучше?
Необходимо ли нам тестировать все возможные комбинации/сценарии для программы?
В чём смысл unit тестов?
Знаете ли вы какие-либо техники/методологии разработки приложения, которые основываются на тестировании(BDD, TDD)?
Необходим ли тестировщику общаться с разработчиками? Зачем?
Есть ли смысл в баг-трекинг системах?
Как вы производите приоритезацию дефектов?
Что такое тестирование граничных значений?
Использует ли ваша команда CI? Если да, то зачем?
Где вы черпаете новые знания о методологиях тестирования и о самом тестировании?
Что вы будете делать, когда устанете делать монотонную работу (тестировать к примеру один модуль несколько месяцев подряд) ?
P.S.: Это всего лишь вершина айсберга, для собеседования более серьёзных кандидатов необходимо влкючать логические задачи, алгоритмы, знание языков программирования и пр. и т.д.
Do different tests instead of repeating the same tests
На такие вопросы, я даже не стараюсь отвечать, ибо приходится сначала указывать на ошибки в поставленном вопросе, а потом вести диалог, и причем сам кандидат почему то становится виноватым.
Равносильно:
Уже даже сам гугл отказался от таких вопросов на сообразительность. Кстати часть вроде из решебника - “80 вопросов на сообразительность, которые задавали в Google”, что-то такое вроде…
Самое забавное, эти вопросы задают практически все… Но самое идеальное собеседование - это наверное не когда тебя спрашивают теорию, а к примеру, придумывают нормальные живые сценарии, по вебу или мобайлу (смотря какое собеседование). И просят рассказать, чтобы вы делали в таких случаях… Вот тогда действительно виден ход мыслей человека… И задачки эти придумывать бы не пальцем в небо, а исходя из живого, личного опыта интервъювера…
Тогда выходит можно реально опыт спроецировать человека, который пришел на собеседование…
Нужно не задавать вопросы - а уметь слушать кандидата. Если мы говорим не о банальном junior, а о middle или senior - то у него есть минимум пару проектов о которых он может рассказать. Вот тут то и нужно слушать, видеть ход мыслей человека при решении задач. А то начинается то классы эквивалентности, то еще какая-нибудь муть, то вот мы еще в интернетах нашли каверзные вопросы - “как вы построите тестирование на проекте?.и т.д…” А когда спрашиваешь, что у вас будет запускать новый проект? - Нет, нам просто интересно… Получается, что половину того, что спрашивают не нужно на проекте, а то что важно и нужно спрашивают кое-как.
Если мы хотим взять именно “того” специалиста который нам нужен - тогда мы должны определить компетенции которым должен владеть человек, расставить их по важности - выделить основные, которые must have и которые nice to be, подготовить вопросы и ситуации с помощью которых он может показать уровень компетенции, посмотреть по резюме - поискать там… Вообще team lead должен быть настоящим team lead, а не человеком который просто технически более опытен - тогда он просто технический специалист и все. И к собеседованию его не нужно подпускать. Нужно понимать, какой человек нужен, его роль на проекте, обязанности - как его можно мотивировать, как он вольется в команду и т.д.
Вообще почитайте Канера http://kaner.com/pdfs/JobsRev6.pdf
Привет, немного прокомментирую.
Это лишь вопросы, которые можно время от времени задавать - это не гайдлайн, как проводить собеседование. Сам подход к проведению собеседования постараюсь описать позже.
Спасибо.
Такие вопросы сгодятся в онлайн форме, чтобы проводить предварительный отсев кандидатов. Чтобы уж совсем случайные люди не отнимали время. А если кандидат дошел до интервью с руководителем QA, то по моему опыту самое эффективное это обычный импровизированный диалог за жизнь и за работу, где быстро будет понятно, подходит ли этот конкретный кандидат на это конкретное место.
Мда, такие типы вопросов задавали мне ТОЛЬКО на позиции интернов или джунов и то только аутсорсовые конторы, хотя и аутсорс разный есть, по компетентности сотрудников! Я бы сказал, что такие типы вопросов - это “обо всём и ни о чём”.
Ещё не понимаю зачем такие вопросы * Как будете тестировать эскалатор/верёвку/будильник? давать, ибо абстрактные они и не применимы к будущей деятельности чела (если вы конечно не нанимаете его тестировать будильники), лучше приближенно к предметной области, например, как будешь тестить docker pull команду.
Отличная вещь, здесь есть еще один сайт с кучей других вопросов для инженеров QA. Возможно, стоит взглянуть на всех, кто интересуется другими вопросами по тестированию QA.
testomat.io управление авто тестами
