Поэтому я и сказал, что речь про подготовку среды, пользователей и прочие пререквизиты, когда настройка окружения занимает существенное время и вызывает дополнительные сложности. Как вариант - настройка кастомного образа для виртуальной машинки для анализа файлов на киберуязвимости. Когда каждый регресс приходилось делать много сложной работы по настройке нужного образа и его нельзя было подготовить заранее, потому что надо было проверять полноценную установку и работу с определенным набором программ. Вот тогда автотесты экономят много времени и мы избегаем дополнительных сложностей с настройкой.
А так да, если функционал не основной и сами автотесты сложнее, ненадежнее и нестабильнее ручных проверок, то понятное дело эти факторы учитываем для приоритета автоматизации.
Опять же за общее распределение задач, но они не отвечают за задачи по тестированию и они не контролируют приоритеты тестирования. Они могу что угодно хотеть, но у вас помимо этого проекта есть и другие задачи, которые могут быть важнее.
Не, я прошел только тестовое для Амазона, потом мне назначили техническое интервью через две недели, а за пару дней до него закрыли много позиций QA, в том числе и ту, на которую я собеседовался. А потом ещё небольшая волна сокращений у них была, я уже решил пока с ними не общаться)
А в остальном, спасибо за разъяснения, мне стало понятнее, почему такой подход к вопросам, это имеет смысл.
Только если вы Джун или Мидл. Да и в этом случае вы обязаны сами исходить из приоритетов задачи, оценивать риски и сроки, а так же исходить из того, что у вас есть другие задачи, более важные. Руководитель - не ваша нянька, которая смотрит за тем, чем вам заниматься сегодня и какие задачи и в каком приоритете их выполнять, а вы каждый раз его дергаете по этим вопросам. Надо самостоятельно уметь выстраивать свою работу, руководитель может определить, скажем, новую фичу или функционал, за которую вы ответственны, но опять же пул проверок задач и их приоритетность вы должны определять сами.
От себя добавлю, что главное — с чего-то начать, например, выбрать хотя бы первые 10 тестов.
Это неправильный подход к автоматизации регресса. Тут два основных подхода. Или же мы выбираем самые затратные по времени ручные тесты или же мы выбираем самые сложные сценарии для подготовки среды, пользователей и т.д.
И вот уже в зависимости от этого мы составляем приоритет для покрытия автотестами нашего регресса. И делаем задачи согласно приоритету.
Задайте вопрос ChatGPT: "Ты приходишь на работу, у тебя в рабочем чате пришло сообщение, что тебе надо протестировать страницу про розовых котиков. Твои действия?"
Он даст развернутый ответ про изучение требований, документацию, сам процесс тестирования. Отличный обширный ответ. Также он скажет, что сразу же приступит к ней. И все это без попытки задуматься, а с чего это он должен делать эту задачу именно сейчас, не уточнит приоритеты и сроки. Не уточнит стадию готовности фичи. Не уточнит степень автоматизации.
ChatGPT отлично понимает суть вопроса, но не может критически мыслить за его гранью.
Расскажи о своем самом смешном баге в продакшене, который ты пропустил.
Как профессионал, я стараюсь подходить к своей работе с максимальной ответственностью и не считаю какие-либо баги смешными, особенно те, которые могут негативно повлиять на пользовательский опыт, репутацию продукта или получение прибыли.
Мне кажется, вот правильный ответ на этот вопрос.
А так тут мало действительно хороших вопросов на критическое мышление и анализ. Я недавно проходил тестовое задание для Амазона, там основное задание - тебе дают разные рабочие ситуации, потом задают по каждой ситуации серию вопросов, тебе просто нужно оценить от 1 до 5 (с разной шкалой оценки) правильное решение в данной ситуации. И таких сценариев десятки и по каждому 5-6 вопросов. Я пробовал скормить это ChatGPT, он не справился с этим. В 9/10 случаев его оценка не совпадала с моей, и, когда я просил его объяснить позицию, я видел, что он очень поверхностно подходит и не может мыслить за гранью сути вопроса.
То есть дать ответ на конкретные (так ещё и на изъезженные вопросы как в этой статье) он может без труда. А вот правильно анализировать сценарий, где уже надо критически мыслить и иметь понимание всей ситуации, ещё и на основе опыта других ответов - вот тут он теряется. К слову, тестовое я успешно прошёл.
"Собеседование на работу – это разговор двух лжецов"
Абсолютно нормально спрашивать кандидата вопросы, на которые он может приукрасить, умолчать информацию, сказать не всю правду и т.д. Поэтому даже в обычных вопросах про самый сложный проект и как кандидат справляется с возникающими проблемами, есть смысл, потому что ваша задача понять ход мыслей соискателя и реально оценить, что человек придумал для решения. Да, вы всю информацию не проверите, но вам это и не нужно, вам нужно понять подход. Еще лучше спрашивать про гипотетические ситуации и сценарии у человека, тогда сразу можно оценить его критическое и аналитическое мышление, глубину и ширину шагов для решения ситуации.
А так, интервьювер тот же лгун, который приукрашивает внутренние процессы, увиливает от неудобных вопросов, умалчивает, уходит от ответов. И ничего с этим не поделаешь, с опытом приходить понимание чтения между строк и нужных вопросов для выявления истины. А иногда и этого не хватает и все выявляется во время ИС.
Расскажу немного про свой 8+ летний опыт тестирования и собеседований.
Бумажка о вашем сертификате не нужна никому. Есть иногда те, кто смотрят немного на ISTQB (в Бельгии и Нидерландах это обязательно для соискателя), но в остальном все ваши вот эти курсы нужны так же, как грамота в школе за 1 место по математике за 5-й класс. Можете с гордостью повесить на стену и забыть. Меня ни разу не спрашивали про курсы.
Классы эквивалентности, граничные значения и прочие термины тест-дизайна спрашивают очень редко. Понимать, как это работает - надо. Применять на практике при решении задачи - надо. Учить определение терминов - такое себе. Если спрашивают на собеседовании и мучают другими вопросами тест-дизайна - бегите от этой конторы. Если вы меня спросите перечислить все техники тест-дизайна, я не назову и половины. Если мне дать практическую задачку и спросить как я буду ее решать - вы увидите все эти техники на практике.
Для интервьюверов: не надо по бумажке спрашивать определения "классов эквивалентности" у соискателя. Нужно задавать кейсы на критическое и аналитическое мышление, выявлять на основе этого умение у соискателя и правильно расставлять приоритеты, и категоризировать свои проверки, и в целом определять глубину проверок, позитивные и негативные кейсы на основе ответов.
На работе нужно работать, вы ищете сотрудника, который будет решать практические задачи и тестировать конкретный функционал, а не задумываться, какую технику тест-дизайна ему нужно применить в конкретном случае. Соискатель должен понимать, как устроены у вас процессы, с каким техстэком и инструментами ему придется работать, а вам надо определить насколько он подходит именно как работник для этой должности.
Если вы самоучка, держите лайфхак — берёте программу платного курса, выписываете себе все темы и гуглите каждую по отдельности.
Вот это очень здравая мысль. Я бы еще закинул все в ChatGPT и попросил составить тебе программу, дает домашние задания и пусть он еще проверяет ответы.
Платные курсы не нужны, до всего можно дойти самоучкой или бесплатными курсами.
Да много факторов может быть. Я на позицию Senior QA шел, может старались больше про опыт спрашивать и меньше про знания. Может и тэх стек другой был. Линукс вообще спрашивали только в одной компании, и то поверхностно.
А вообще в целом достаточно рандомно все, сложно подготовиться ко всем вопросам) Пишут один тех стэк в позиции, спрашивают про другой. Часто еще и ищут на позицию в другую команду, не на ту, что откликался, с другим набором требований, просто потому что что-то там передумали внутри команды. Я так уже с тремя менеджерами перезнакомился, потому что они не знали, куда меня пристроить)
О чём чаще всего спрашивают тестировщиков на технических собеседованиях
Удивительно насколько мой опыт поиска работы разнится в плане вопросов на собеседовании. У меня не было ни одного глубокого вопроса про Docker, Linux, устройство CI/CD. Если и были по ним вопросы, то формата с чем работал и что делал. Рассказываешь про свой опыт, подкрепляешь свой ответ дополнительным примером того, как это было релевантно в рамках своей позиции, после этого не требовались дополнительные знания.
А вот про клиент-серверное взаимодействие спрашивали очень много. Я бы сказал, что надо делать больше упор на него. Причем надо не заучить базовые вещи, а больше порыться в структуре запросов, ответах, в целом понимать как и что происходит. А если есть в позиции мобилки, прочитать про них все, включая структуру APK или IPA.
Все остальное в статье, включая "Чем отличаются собеседования в QA три года назад и сейчас" звучит очень похоже. Кроме того, сложилось ощущение, что стало больше технически слабых интервьюеров с небольшим опытом, которые не умеют рассуждать, критически мыслить и не могут принять ответ за рамками какой-то бумажки, где у них есть ответы. Я так задавал пару вопросов на уточнение и понимаю, что люди хлопают глазами и не могут ответить на вопрос и плывут.
Наличие диплома по ИТ или прохождение специальных курсов и сертификаций даст тестировщику преимущество в поиске работы и повышении профессионального уровня.
Нет, не даёт никакого преимущества. До всего можно отлично найти самоучкой без курсов и образования.
Тестировщики полностью заменяемы автоматизированными тестами
И да, и нет. Поддержка и написание новых тестов действительно требует человека и QA, ответственный за это, действительно необходим. Но я так же знаю много примеров на практике, когда команда тестирования сокращалась в несколько раз после покрытия ручного тестирования автоматизацией в 95% и более. Я не согласен с такой реальностью, но для небольших компаний - это естественное урезание расходов.
А так вы описываете мифы, которые лет 10 уже никто не озвучивает, это уже давно в прошлом.
Меня несколько моментов смущают. Речь идет о One Day Offer и делается акцент на "этапы прохождения собеседования за один день". Вот тут сразу странная ситуация с тем, что автор опоздала на этап лайвкодинга по причине перелета. То есть получается, что весь день на все этапы собеседования был тогда же, когда и назначен перелет? Эээ, странно. Ну ладно, допустим. Автор успешно проходит рано утром все этапы до лайвкодинга, летит 7-8 часов из Таиланда в Казахстан + сколько-то часов на путь до взлета и после прилета, и все это время и после компания переносит этап лайвкодинга (трижды), а интервьювер видимо на работе допоздна сидит и ждет.
Ладно, другой момент, вместо любой онлайн кодилки интервью проходит на IDE соискателя? Тоже странно, но ладно. И автор не может просто проверить, что установлена IntelliJ IDEA перед собеседованием, а устанавливает прямо во время?
Я просто не понимаю, как можно строить данные и называть статью "Сколько зарабатывает ручной тестировщик", если меньше 20% компаний указывают доход? При такой выборке очень сложно получить реальные данные.
Сейчас на HH 2000+ вакансий на QA и из них только в 370 указан доход. Причем доход - не точная цифра, а диапазон от или до какого-то числа. Получается что брали рандомно 200 позиций, брали числа, где могло быть и "от" или "до" и составили статистику? Ну такое себе. При этом не брали крупные IT компании для выборки, не проводили опросов, не собирали каких-нибудь данных с glassdor.
А, ну тогда по вашей диванной аналитике уже сейчас разработчикам стоит опасаться за будущее больше, учитывая, что Unit-тесты пишут в основном они) Код кстати ChatGPT пишет неплохой, я тут недавно писал игрушку на шарпах, он большой молодец, надо просто модель достаточно хорошо научить. Но у него есть проблема с большими блоками кода и с запоминанием. Он через 20-30 новых запросов может забыть все методы класса, который сам же и описал.
За 10 минут ему удалось в красках расписать всю автобиографию, начиная со знакомства его родителей.
Для этого хороший HR одергивает кандидата в начале повествования, объясняет, что именно подразумевает под вопросом "расскажите о себе" и не выслушивает все 10 минут.
Также часто спрашивают, какие виды тестирования существуют.
Не стоит употреблять малознакомые термины, размыто говорить сразу обо всём или наоборот, слишком вдаваться в подробности, потому что каждое такое уточнение может стать поводом для новых, обычно более сложных вопросов.
Для этого надо спрашивать, не какие виды тестирования существуют, а спросить, по каким основным классификациям можно выделить виды тестирования. Дополнительно, можно обозначить их и спросить кандидата отдельно по каждой классификации. А то так спросили виды тестирования, кандидат и начинает перечислять все, которые знает.
Отвечать «я не знаю» тоже не следует, потому что интервьюер может подумать, что эта тема вам вовсе не интересна и у вас нет мотивации узнавать новое.
Мне кажется, что отвечать "Я не знаю" абсолютно адекватный и честный ответ на вопрос. Это не значит, что тема не интересна и что у человека нет мотивации, это значит, что он просто не знает ответ на вопрос и честно признается в этом.
В любой непонятной ситуации задавайте уточняющие вопросы.
Так можно закопать себя еще больше. Например простой вопрос: "В чем отличия между HTTP и HTTPS протоколами"? Допустим, человек не знает ответа, какой уточняющий вопрос его спасет в этой ситуации, а не сделает еще хуже? "Что вы подразумеваете под HTTP протоколом?" Единственное, если кандидат действительно это знает или читал об этом, но забыл, можно сказать честно об этом, попросить дать ответ на вопрос, а потом самому дополнить ответ, чтобы показать, что действительно знаком с темой.
Также в этом блоке интервьюер может проверить знание SQL и дать логические задачки «на засыпку».
А дают еще на собеседованиях задачки на логику? А то я давно не встречал такие даже среди джунов. Чаще просто дают сценарии для тестирования и смотрят на то, как человек размышляет.
Поэтому я и сказал, что речь про подготовку среды, пользователей и прочие пререквизиты, когда настройка окружения занимает существенное время и вызывает дополнительные сложности. Как вариант - настройка кастомного образа для виртуальной машинки для анализа файлов на киберуязвимости. Когда каждый регресс приходилось делать много сложной работы по настройке нужного образа и его нельзя было подготовить заранее, потому что надо было проверять полноценную установку и работу с определенным набором программ. Вот тогда автотесты экономят много времени и мы избегаем дополнительных сложностей с настройкой.
А так да, если функционал не основной и сами автотесты сложнее, ненадежнее и нестабильнее ручных проверок, то понятное дело эти факторы учитываем для приоритета автоматизации.
Опять же за общее распределение задач, но они не отвечают за задачи по тестированию и они не контролируют приоритеты тестирования. Они могу что угодно хотеть, но у вас помимо этого проекта есть и другие задачи, которые могут быть важнее.
Не, я прошел только тестовое для Амазона, потом мне назначили техническое интервью через две недели, а за пару дней до него закрыли много позиций QA, в том числе и ту, на которую я собеседовался. А потом ещё небольшая волна сокращений у них была, я уже решил пока с ними не общаться)
А в остальном, спасибо за разъяснения, мне стало понятнее, почему такой подход к вопросам, это имеет смысл.
Только если вы Джун или Мидл. Да и в этом случае вы обязаны сами исходить из приоритетов задачи, оценивать риски и сроки, а так же исходить из того, что у вас есть другие задачи, более важные. Руководитель - не ваша нянька, которая смотрит за тем, чем вам заниматься сегодня и какие задачи и в каком приоритете их выполнять, а вы каждый раз его дергаете по этим вопросам. Надо самостоятельно уметь выстраивать свою работу, руководитель может определить, скажем, новую фичу или функционал, за которую вы ответственны, но опять же пул проверок задач и их приоритетность вы должны определять сами.
Это неправильный подход к автоматизации регресса. Тут два основных подхода. Или же мы выбираем самые затратные по времени ручные тесты или же мы выбираем самые сложные сценарии для подготовки среды, пользователей и т.д.
И вот уже в зависимости от этого мы составляем приоритет для покрытия автотестами нашего регресса. И делаем задачи согласно приоритету.
Задайте вопрос ChatGPT: "Ты приходишь на работу, у тебя в рабочем чате пришло сообщение, что тебе надо протестировать страницу про розовых котиков. Твои действия?"
Он даст развернутый ответ про изучение требований, документацию, сам процесс тестирования. Отличный обширный ответ. Также он скажет, что сразу же приступит к ней. И все это без попытки задуматься, а с чего это он должен делать эту задачу именно сейчас, не уточнит приоритеты и сроки. Не уточнит стадию готовности фичи. Не уточнит степень автоматизации.
ChatGPT отлично понимает суть вопроса, но не может критически мыслить за его гранью.
Как профессионал, я стараюсь подходить к своей работе с максимальной ответственностью и не считаю какие-либо баги смешными, особенно те, которые могут негативно повлиять на пользовательский опыт, репутацию продукта или получение прибыли.
Мне кажется, вот правильный ответ на этот вопрос.
А так тут мало действительно хороших вопросов на критическое мышление и анализ. Я недавно проходил тестовое задание для Амазона, там основное задание - тебе дают разные рабочие ситуации, потом задают по каждой ситуации серию вопросов, тебе просто нужно оценить от 1 до 5 (с разной шкалой оценки) правильное решение в данной ситуации. И таких сценариев десятки и по каждому 5-6 вопросов. Я пробовал скормить это ChatGPT, он не справился с этим. В 9/10 случаев его оценка не совпадала с моей, и, когда я просил его объяснить позицию, я видел, что он очень поверхностно подходит и не может мыслить за гранью сути вопроса.
То есть дать ответ на конкретные (так ещё и на изъезженные вопросы как в этой статье) он может без труда. А вот правильно анализировать сценарий, где уже надо критически мыслить и иметь понимание всей ситуации, ещё и на основе опыта других ответов - вот тут он теряется. К слову, тестовое я успешно прошёл.
"Собеседование на работу – это разговор двух лжецов"
Абсолютно нормально спрашивать кандидата вопросы, на которые он может приукрасить, умолчать информацию, сказать не всю правду и т.д. Поэтому даже в обычных вопросах про самый сложный проект и как кандидат справляется с возникающими проблемами, есть смысл, потому что ваша задача понять ход мыслей соискателя и реально оценить, что человек придумал для решения. Да, вы всю информацию не проверите, но вам это и не нужно, вам нужно понять подход.
Еще лучше спрашивать про гипотетические ситуации и сценарии у человека, тогда сразу можно оценить его критическое и аналитическое мышление, глубину и ширину шагов для решения ситуации.
А так, интервьювер тот же лгун, который приукрашивает внутренние процессы, увиливает от неудобных вопросов, умалчивает, уходит от ответов. И ничего с этим не поделаешь, с опытом приходить понимание чтения между строк и нужных вопросов для выявления истины. А иногда и этого не хватает и все выявляется во время ИС.
Расскажу немного про свой 8+ летний опыт тестирования и собеседований.
Бумажка о вашем сертификате не нужна никому. Есть иногда те, кто смотрят немного на ISTQB (в Бельгии и Нидерландах это обязательно для соискателя), но в остальном все ваши вот эти курсы нужны так же, как грамота в школе за 1 место по математике за 5-й класс. Можете с гордостью повесить на стену и забыть. Меня ни разу не спрашивали про курсы.
Классы эквивалентности, граничные значения и прочие термины тест-дизайна спрашивают очень редко. Понимать, как это работает - надо. Применять на практике при решении задачи - надо. Учить определение терминов - такое себе. Если спрашивают на собеседовании и мучают другими вопросами тест-дизайна - бегите от этой конторы. Если вы меня спросите перечислить все техники тест-дизайна, я не назову и половины. Если мне дать практическую задачку и спросить как я буду ее решать - вы увидите все эти техники на практике.
Для интервьюверов: не надо по бумажке спрашивать определения "классов эквивалентности" у соискателя. Нужно задавать кейсы на критическое и аналитическое мышление, выявлять на основе этого умение у соискателя и правильно расставлять приоритеты, и категоризировать свои проверки, и в целом определять глубину проверок, позитивные и негативные кейсы на основе ответов.
На работе нужно работать, вы ищете сотрудника, который будет решать практические задачи и тестировать конкретный функционал, а не задумываться, какую технику тест-дизайна ему нужно применить в конкретном случае. Соискатель должен понимать, как устроены у вас процессы, с каким техстэком и инструментами ему придется работать, а вам надо определить насколько он подходит именно как работник для этой должности.
Вот это очень здравая мысль. Я бы еще закинул все в ChatGPT и попросил составить тебе программу, дает домашние задания и пусть он еще проверяет ответы.
Платные курсы не нужны, до всего можно дойти самоучкой или бесплатными курсами.
Да много факторов может быть. Я на позицию Senior QA шел, может старались больше про опыт спрашивать и меньше про знания. Может и тэх стек другой был. Линукс вообще спрашивали только в одной компании, и то поверхностно.
А вообще в целом достаточно рандомно все, сложно подготовиться ко всем вопросам) Пишут один тех стэк в позиции, спрашивают про другой. Часто еще и ищут на позицию в другую команду, не на ту, что откликался, с другим набором требований, просто потому что что-то там передумали внутри команды. Я так уже с тремя менеджерами перезнакомился, потому что они не знали, куда меня пристроить)
Удивительно насколько мой опыт поиска работы разнится в плане вопросов на собеседовании. У меня не было ни одного глубокого вопроса про Docker, Linux, устройство CI/CD. Если и были по ним вопросы, то формата с чем работал и что делал. Рассказываешь про свой опыт, подкрепляешь свой ответ дополнительным примером того, как это было релевантно в рамках своей позиции, после этого не требовались дополнительные знания.
А вот про клиент-серверное взаимодействие спрашивали очень много. Я бы сказал, что надо делать больше упор на него. Причем надо не заучить базовые вещи, а больше порыться в структуре запросов, ответах, в целом понимать как и что происходит. А если есть в позиции мобилки, прочитать про них все, включая структуру APK или IPA.
Все остальное в статье, включая "Чем отличаются собеседования в QA три года назад и сейчас" звучит очень похоже. Кроме того, сложилось ощущение, что стало больше технически слабых интервьюеров с небольшим опытом, которые не умеют рассуждать, критически мыслить и не могут принять ответ за рамками какой-то бумажки, где у них есть ответы. Я так задавал пару вопросов на уточнение и понимаю, что люди хлопают глазами и не могут ответить на вопрос и плывут.
Нет, не даёт никакого преимущества. До всего можно отлично найти самоучкой без курсов и образования.
И да, и нет. Поддержка и написание новых тестов действительно требует человека и QA, ответственный за это, действительно необходим. Но я так же знаю много примеров на практике, когда команда тестирования сокращалась в несколько раз после покрытия ручного тестирования автоматизацией в 95% и более. Я не согласен с такой реальностью, но для небольших компаний - это естественное урезание расходов.
А так вы описываете мифы, которые лет 10 уже никто не озвучивает, это уже давно в прошлом.
Меня несколько моментов смущают. Речь идет о One Day Offer и делается акцент на "этапы прохождения собеседования за один день". Вот тут сразу странная ситуация с тем, что автор опоздала на этап лайвкодинга по причине перелета. То есть получается, что весь день на все этапы собеседования был тогда же, когда и назначен перелет? Эээ, странно. Ну ладно, допустим. Автор успешно проходит рано утром все этапы до лайвкодинга, летит 7-8 часов из Таиланда в Казахстан + сколько-то часов на путь до взлета и после прилета, и все это время и после компания переносит этап лайвкодинга (трижды), а интервьювер видимо на работе допоздна сидит и ждет.
Ладно, другой момент, вместо любой онлайн кодилки интервью проходит на IDE соискателя? Тоже странно, но ладно. И автор не может просто проверить, что установлена IntelliJ IDEA перед собеседованием, а устанавливает прямо во время?
Короче, сплошные красные флаги.
А почему статья называется "Как QA собеседование проходил", если повествование от лица девушки?
Я просто не понимаю, как можно строить данные и называть статью "Сколько зарабатывает ручной тестировщик", если меньше 20% компаний указывают доход? При такой выборке очень сложно получить реальные данные.
Сейчас на HH 2000+ вакансий на QA и из них только в 370 указан доход. Причем доход - не точная цифра, а диапазон от или до какого-то числа. Получается что брали рандомно 200 позиций, брали числа, где могло быть и "от" или "до" и составили статистику? Ну такое себе. При этом не брали крупные IT компании для выборки, не проводили опросов, не собирали каких-нибудь данных с glassdor.
А, ну тогда по вашей диванной аналитике уже сейчас разработчикам стоит опасаться за будущее больше, учитывая, что Unit-тесты пишут в основном они)
Код кстати ChatGPT пишет неплохой, я тут недавно писал игрушку на шарпах, он большой молодец, надо просто модель достаточно хорошо научить. Но у него есть проблема с большими блоками кода и с запоминанием. Он через 20-30 новых запросов может забыть все методы класса, который сам же и описал.
Для этого хороший HR одергивает кандидата в начале повествования, объясняет, что именно подразумевает под вопросом "расскажите о себе" и не выслушивает все 10 минут.
Для этого надо спрашивать, не какие виды тестирования существуют, а спросить, по каким основным классификациям можно выделить виды тестирования. Дополнительно, можно обозначить их и спросить кандидата отдельно по каждой классификации. А то так спросили виды тестирования, кандидат и начинает перечислять все, которые знает.
Мне кажется, что отвечать "Я не знаю" абсолютно адекватный и честный ответ на вопрос. Это не значит, что тема не интересна и что у человека нет мотивации, это значит, что он просто не знает ответ на вопрос и честно признается в этом.
Так можно закопать себя еще больше. Например простой вопрос: "В чем отличия между HTTP и HTTPS протоколами"? Допустим, человек не знает ответа, какой уточняющий вопрос его спасет в этой ситуации, а не сделает еще хуже? "Что вы подразумеваете под HTTP протоколом?"
Единственное, если кандидат действительно это знает или читал об этом, но забыл, можно сказать честно об этом, попросить дать ответ на вопрос, а потом самому дополнить ответ, чтобы показать, что действительно знаком с темой.
А дают еще на собеседованиях задачки на логику? А то я давно не встречал такие даже среди джунов. Чаще просто дают сценарии для тестирования и смотрят на то, как человек размышляет.
А каких тестов, расскажите подробнее? Unit-тесты или E2E тесты?
Тогда уж трех. Я вот редко встречаю чисто ручных QA и чисто AQA, везде есть распределение.
А можно подробнее, откуда вы взяли эти 200 вакансий и откуда получили точные данные по зарплате?