Comments 21
Со стороны интервьюеров, кстати, тоже можно использовать чат для оценки вопросов, согласна)
Если хочешь проверить вопрос/задачу на неочевидность и что нужно хорошо подумать - можно задать вопрос чату. Соответственно, если его ответ неправильный или неполный, значит вопрос хороший :D (ну или вопрос неправильный, но это на совести собеседующего).
Но все равно на собеседованиях часто есть вопросы для проверки общих знаний. Если чат на них отвечает хорошо, не значит, что вопросы не стоит задавать совсем. Главное, чтобы собес не состоял только из таких очевидных вопросов "по учебнику".
В книге "Верховный алгоритм" Педро Домингос как раз описывает будущее, в котором нейросеть работодателя собеседует нейросети кандидатов и по результатам сразу приглашает работников. Сети, естественно, не универсальные (как ChatGPT), а уникальные, обученные на конкретных персонажах, так что они точно "знают" их возможности и предпочтения. В итоге все счастливы: никому никуда не надо ходить, всё происходит быстро и "автоматически".
на самом деле ваш пример говорит о том, что вместо индусотестеров или джунов можно уже использовать ChatGPT По сути своими вопросами (за исключением первых "стандартноидиотских" типа вспомни самый смешной) которые скорее всего и покрывают 75% задач вы показали, что из трех сотрудников компании можно легко оставить одного :-)
« В задаче сказано, что это поисковая выдача вакансий, значит, скорее всего, она состоит из одинаковых по коду элементов, по умолчанию имеющих одинаковый идентификатор, что приведет к ошибке автотеста, либо к проверке не того элемента. Так же совершенно неправильно явно указывать количество скроллов, так как UI автотесты могут гоняться на разных разрешениях экранов. Сегодня на экран помещается 2–3 вакансии, а завтра 5–6, и тест упадет, хотя функционал работает ». Он исправился и в конце выдал кусочек идеальнейшего кода.»
Вот таких собеседователей надо гнать поганой метлой.
Сначала дели конкретное задание для теста:
Задача: необходимо проверить поисковую выдачу, в поисковой выдаче — карточки вакансий. Тебе нужно проверить корректность 21-й карточки в выдаче, при условии, что на 1 экран помещается в среднем 2-3 карточки. Как ты автоматизируешь эту проверку?
А потом сказали что надо было решать совершенно другую задачу.
Возможно это и есть причина почему на Хабре за все эти годы баги не вычистили.
Вам аналитик/ или кто-то там поставил задачу -автоматизировать тест. С конкретными условиями, а потом говорит что тест «не торт» и писать надо было другое.
Если в условиях теста сказано что выдают по 2-3 карточки значит выдача по 3-4 или иному числу- ошибка- тест должен упасть.
Если сказали что надо 21/2 или 21/3 скроллом значит их столько и должно быть.
Если у вас задача протестировать алгоритм выдачи, то не важно сколько элементов выдал запрос. Тогда можно тупо тестировать первый элемент.
Если нужно просто протестировать скроллинг то нужно тестировать 1- вый, последний в первом экране, первый на втором экране, последний на втором экране и последний элемент в выдаче.
Если надо тестировать алгоритм разбиения на страницы то так и надо ставить задачу:
Есть поисковая выдача состоящая из M, нет M мало, пусть будет N, элементов. Алгоритм разбивает ее на страницы по K Элементов проверьте правильность разбиения на страницы при N: 1,2,3, 16,255,256,1023,1024,1025 элементов и k: 1,2,3,5,7,9,10,11,31,32,64,65,100,101…
Мы задаем примерно такой вопрос на собеседованиях мобильных автоматизаторов только для тех, у кого есть реальный опыт автоматизации.
Во-первых, для QA, у которых реально есть опыт автоматизации мобилок, сразу понимают суть вопроса и в чем его прикол. Это показательно.
Во-вторых, стараемся задавать открытые вопросы. Все вопросы разговорные, "не жесткие" задачи, поэтому на мой взгляд НЕ задать сразу все условия и озвучить все нюансы для задачи на собеседовании - это нормально. Кандидат может задать сколько угодно уточняющих вопросов - на все получит ответы.
Ну и в третьих, мы не оцениваем ответы на собеседованиях, как правильные/неправильные. Мы обращаем внимание на то, как рассуждал, какие вопросы задавал, какие решения предлагал. Да и на крайний случай, как себя повел, когда пришла "непонятная" задача, если она для него стала таковой.
Если кандидат отвечает на поставленную задачу прямо, можем сами донакинуть "а если так", "а при обновлении симуляторов что произойдет с этим тестом? А как тогда написать сразу более стабильный" и тп.
По итогу, если бы мы составляли ТЗ или задачу для тестового задания, на которое нам нужно было сразу выдать готовое правильное решение - вы правы. Но для собеседований я считаю задачу корректной и полезной.
Чем же «мобильный QA” от не «мобильного» отличается? Тем более что дальше вы говорите:
« и тест упадёт хотя функционал работает» исходя из этой фразы можно предположить что функционал должен работать и в мобильной и в десктопный версии.
Мне кажется что ваша позиция обусловлена тем, что вы и заказчик и исполнитель в одном лице. Все меняется если разработка отдана на аутсорс одной компании а QA тестирование делается своими силами или силами другой компании. Тогда у разработчика нет возможности сказать «это не баг -это фича» поскольку QA проверяют то что написано в тесте а не то что разработчик/ аналитик подумал. Когда у вас за Х*1000 тестов, ваши подходы не сработают. Тест должен один в один совпадать со спецификацией.
Иначе будет такой треш, что сам черт ногу сломит.
P.S. В рамках собеседования я ответил на ваш вопрос? :)
В данном вопросе мобильный от немобильного может отличаться ограниченным количеством разрешений экрана, например. Если спуститься в вообще конкретный кейс, в например натив на iOS, - симулятор для тестирования обновляется раз в год с обновлением XCode (ну как минимум). Хороший тест для нас это такой, который не упадет из-за того, что ранее он гонялся на более маленьком экране старого айфона. Это как один из примеров специфики, которые мобильные автоматизаторы знают, если с этим работали.
Сюда же, к примеру, если в элемент выдачи добавилась какая-то новая надпись, ячейки стали шире > на экран симулятора стало помещаться меньше ячеек. Функциональный автотест, который проверяет что-то вообще другое в этом списке не должен упасть из-за этого. И тд и тп.
Вообще судя по тому, что мы обсуждаем этот кейс, он все-таки интересный. И на собеседовании его было бы так же приятно и полезно обсудить)
P.S.: пф, в рамках собеседования вы однозначно ответили на вопрос!))) Мы бы может и продолжили копать эту тему дополнительными нюансами и реальными кейсами, но в целом, профессиональный зачёт, так как было интересно ;)
На рынке есть же продукт, который можно подключить к собесу и он будет исходя из вопрос, сразу представлять ответы от АИ.
А вообще заданные вопросы сложно отнести к вопрос техническим
Расскажи о своем самом смешном баге в продакшене, который ты пропустил.
Как профессионал, я стараюсь подходить к своей работе с максимальной ответственностью и не считаю какие-либо баги смешными, особенно те, которые могут негативно повлиять на пользовательский опыт, репутацию продукта или получение прибыли.
Мне кажется, вот правильный ответ на этот вопрос.
А так тут мало действительно хороших вопросов на критическое мышление и анализ. Я недавно проходил тестовое задание для Амазона, там основное задание - тебе дают разные рабочие ситуации, потом задают по каждой ситуации серию вопросов, тебе просто нужно оценить от 1 до 5 (с разной шкалой оценки) правильное решение в данной ситуации. И таких сценариев десятки и по каждому 5-6 вопросов. Я пробовал скормить это ChatGPT, он не справился с этим. В 9/10 случаев его оценка не совпадала с моей, и, когда я просил его объяснить позицию, я видел, что он очень поверхностно подходит и не может мыслить за гранью сути вопроса.
То есть дать ответ на конкретные (так ещё и на изъезженные вопросы как в этой статье) он может без труда. А вот правильно анализировать сценарий, где уже надо критически мыслить и иметь понимание всей ситуации, ещё и на основе опыта других ответов - вот тут он теряется. К слову, тестовое я успешно прошёл.
Это очень круто, я вас от души поздравляю) Пройти собеседование в Амазон - звучит мощно!)
Что касается вопросов. На такие вопросы нет правильных или неправильных ответов. Ваш ответ в том числе является "правильным", если их так категоризировать.
Такой вопрос для некоторых кандидатов может являться "расслабляющим". Просто в начале вспомнить какой-нибудь забавный рабочий случай. Если вспомнил - здорово. Дальше мы бы пошли по ветви более серьезных вопросов формата "что сделал, чтобы такого больше не допустить". Если не вспомнил и растерялся - звоночек для собеседующего, что кандидат, возможно, сильно нервничает, нужно еще немного поговорить о чем-то или пойти дальше. Если ответил, как вы, вопрос скорее всего будет переформулирован в "самый запомнившийся баг" и какими способами можно было его не допустить.
К тому же, не все вопросы из статьи взяты конкретно из собеседований в нашу компанию. Некоторые вопросы взяты из распространенных, которые подходили для нашей цели - чат хорошо справляется с такими вопросами, это мы и проверяли.
И последнее - каждая компания (а скорее даже каждая команда внутри компании) подбирает вопросы для своих собеседований специально под себя. Вопросы должны раскрывать софт-скиллы кандидата, которые потом будут оцениваться как подходящие или неподходящие для комфортной работы в команде. Задачи подбираются под реальные потребности команды. В каких-то командах есть упор на софт-скиллы, на бизнес ориентированность, в то время как другим может быть нужен жесткий технарь и софт-скиллы отойдут на второй план. В зависимости от этого разные вопросы, разные собеседования.
Не, я прошел только тестовое для Амазона, потом мне назначили техническое интервью через две недели, а за пару дней до него закрыли много позиций QA, в том числе и ту, на которую я собеседовался. А потом ещё небольшая волна сокращений у них была, я уже решил пока с ними не общаться)
А в остальном, спасибо за разъяснения, мне стало понятнее, почему такой подход к вопросам, это имеет смысл.
Задайте вопрос ChatGPT: "Ты приходишь на работу, у тебя в рабочем чате пришло сообщение, что тебе надо протестировать страницу про розовых котиков. Твои действия?"
Он даст развернутый ответ про изучение требований, документацию, сам процесс тестирования. Отличный обширный ответ. Также он скажет, что сразу же приступит к ней. И все это без попытки задуматься, а с чего это он должен делать эту задачу именно сейчас, не уточнит приоритеты и сроки. Не уточнит стадию готовности фичи. Не уточнит степень автоматизации.
ChatGPT отлично понимает суть вопроса, но не может критически мыслить за его гранью.
Так это задача руководителя ставить задачи
Только если вы Джун или Мидл. Да и в этом случае вы обязаны сами исходить из приоритетов задачи, оценивать риски и сроки, а так же исходить из того, что у вас есть другие задачи, более важные. Руководитель - не ваша нянька, которая смотрит за тем, чем вам заниматься сегодня и какие задачи и в каком приоритете их выполнять, а вы каждый раз его дергаете по этим вопросам. Надо самостоятельно уметь выстраивать свою работу, руководитель может определить, скажем, новую фичу или функционал, за которую вы ответственны, но опять же пул проверок задач и их приоритетность вы должны определять сами.
Как мы собеседовали ChatGPT на позицию QA