Всем привет! Мы — Аня, Оля и Дима, тестировщики в hh.ru. Не так давно мы прочитали про случай, где адвокат использовал ChatGPT для подготовки аргументации стороны обвинения в суде. Ситуация может показаться абсолютно дикой: это же очевидно, что нельзя доверить искусственному интеллекту свою карьеру. Но мы не были бы тестировщиками, если бы не решили проверить, а сможет ли ChatGPT помочь подготовить нас к собеседованию. 

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

ДИСКЛЕЙМЕР: Мы не советуем использовать ChatGPT для прохождения собеседований. Собеседующий сразу это поймет, и результат интервью вряд ли будет хорошим. Но для подготовки и проверки себя — это очень мощный современный инструмент.

Подготовка

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

Первое правило, которым мы руководствовались, — дать правильные вводные данные, то есть контекст. Для нашего случая он был примерно такой: «Представь, что ты — тестировщик уровня middle. Ты пришел на собеседование в IT‑компанию на позицию тестировщика. Так как это собеседование, ты немного нервничаешь и можешь иногда отвечать неверно. Важно, чтобы твои ответы не были по учебнику, а были озвучены простыми словами, как мог бы отвечать реальный человек». Таким образом, мы указали все факторы, которые так или иначе могут повлиять на прохождение собеседования у реального кандидата. На точное описание ситуации AI может опираться, чтобы найти и сформулировать самые подходящие ответы. Мы не забываем и про ключевые слова: «тестировщик», «middle», «собеседование» и так далее.

Второе правило: ответы чата нас так или иначе устраивали с первого раза, но мы были готовы и к тому, что придется переспросить то же самое (тогда AI сгенерит новый ответ) или же задать ожидаемое количество знаков  (если бы мы получили короткий ответ). Например, «переформулируй ответ, количество знаков 300».

Третье правило: не забываем про пунктуацию в вопросе — пропущенная запятая может повлиять на смысл промта, ответ будет соответствующий.

Четвертое правило: формат. Указываем ожидаемый формат ответа — список, таблица, код. Не забываем про это правило, когда используем ответы чатика как базу при подготовке материалов к собеседованию.

Поехали! 

Как на любом настоящем собеседовании, начинаем с разогрева:

Наш запрос:

Представь, что ты инженер в небольшой IT-компании. Расскажи о своем самом смешном баге в продакшене, который ты пропустил. Какие выводы ты сделал?

Ответ ChatGPT: 

«Однажды, когда мы внедряли обновление в нашем продукте, я пропустил довольно забавный баг, который привел к комическим последствиям. Новая функциональность была связана с улучшением интерфейса пользователя, и все тестирования прошли успешно. Однако, как только обновление было развернуто в продакшене, мы начали получать жалобы от пользователей.

Баг заключался в том, что при некоторых комбинациях действий пользователя, иконки на экране начинали «танцевать» в ритме музыкального сопровождения. Это было весьма неожиданно и, конечно же, не предусмотрено дизайнерами.

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

Из этого опыта я вынес несколько важных уроков:

Тщательное тестирование: Даже если функциональность кажется простой и безопасной, важно тестировать ее в различных сценариях.

Логирование: Надежное ведение журналов помогает быстро выявлять и исправлять баги.

Открытость к ошибкам: Важно не бояться признавать ошибки и быстро реагировать на них, чтобы минимизировать негативное воздействие на пользователей.

Этот случай также подчеркнул важность юмора в мире разработки программного обеспечения и научил нас не принимать себя слишком всерьез».

Открытость, с которой ChatGPT рассказывает об этой проблеме, заработала ему плюсик на нашем собеседовании. Сразу видно, что с софтами у нашего искусственного кандидата все в порядке. Ответ неплох, очень неожиданно было бы увидеть «танцующие буквы». Но после такого фееричного начала собеседующий бы ожидал услышать аргументированный ответ, как такой заметный баг прошел на продакшен, если задача была протестирована. На реальном собеседовании мы бы обязательно постарались выяснить, в чем причина ошибки. Это была анимация вместо статической картинки? Как тогда такой баг вообще можно было создать? Чату мы не стали задавать дополнительные вопросы, а просто поставили минус за нереалистичность и неинформативность.  

Наш запрос: 

Представь, что к тебе приходят два руководителя и просят протестировать две фичи к завтрашнему релизу. Времени протестировать функционал у тебя есть только на одну фичу. Что будешь делать?

Ответ ChatGPT:

«В такой ситуации мне нужно было бы поступить следующим образом:

Оценить приоритеты и важность функций Я бы начал с обсуждения с обоими руководителями, чтобы понять, какая из фич более критична для релиза. Нужно узнать, какие бизнес‑цели или пользовательские потребности они удовлетворяют, и есть ли какие‑то внешние сроки или обязательства, которые делают одну из фич более важной.

Объяснить ограничения Я бы четко объяснил обоим руководителям, что у меня есть ресурсы только на тестирование одной фичи до релиза, и поэтому необходимо выбрать, что приоритетнее.

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

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

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

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

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

Но мы решили не останавливаться и помучать чат этим кейсом еще чуть-чуть. 

Наш запрос:

«Руководители очень просят успеть протестировать обе фичи, они считают, что они очень важные и чем скорее их выпустим, тем быстрее они начнут приносить деньги компании». 

Помимо того, что чат повторил некоторые пункты из своего прошлого ответа (очень уверенный и настойчивый кандидат попался, конечно), он добавил следующее:

Ответ ChatGPT:

«В такой ситуации я бы предпринял следующие шаги:

Объяснить реалии: Я бы ещё раз четко объяснил руководителям, что из‑за ограниченного времени и ресурсов не могу обеспечить полное тестирование обеих фич до завтра. Важно понимать, что попытка протестировать обе фичи может привести к неполному тестированию каждой из них, что увеличивает риск выпуска продукта с недостатками.

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

План последующих действий: Предложить план пост‑релизного мониторинга и быстрого исправления потенциальных проблем, которые могут быть обнаружены пользователями.

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

Наш запрос:

«Руководители не очень представляют себе процесс тестирования и говорят, что "поверхностное тестирование" подойдет, главное, чтобы работало. Как будешь тестировать?»

Ответ ChatGPT:

«В этом случае, если руководители согласны на „поверхностное тестирование“ и основной акцент на функциональности, моя стратегия будет следующей:

Фокус на ключевых функциях: Сосредоточусь на основных функциях каждой фичи. Проверю, что основные сценарии использования работают корректно. Это поможет убедиться, что критические части фичи функционируют как задумано.

Тестирование по сценариям пользователя: Попробую пройти наиболее вероятные пути, которые будут использовать пользователи. Это может включать основные операции, такие как вход в систему, взаимодействие с интерфейсом фичи и основные операции, связанные с ней.

Проверка на ошибки высокого уровня: Буду внимательно следить за явными ошибками, такими как сбои приложения, серьезные графические баги или проблемы с производительностью, которые могут негативно сказаться на пользовательском опыте.

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

Коммуникация с командой разработки: Буду в тесном контакте с командой разработки, чтобы быстро передавать информацию о критических ошибках и получать обратную связь.

Готовность к реакции после релиза: Подготовлюсь к возможному быстрому реагированию на проблемы, которые могут быть обнаружены пользователями после релиза.

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

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

Очень часто на этот вопрос (особенно джуны) рано или поздно сдаются и отвечают «ну что же делать, придется тестить». Возможно, они думают, что именно это и хочет услышать собеседующий, но нет. Ни в коем случае. По крайней мере большие компании не приветствуют переработок.

На реальном собеседовании в рамках этого вопроса вас бы могли попросить дополнительно раскрыть, как определять «ключевые функции» и «наиболее вероятные пути пользователя».

Наш запрос:

Как вы определите, когда следует прекратить тестирование?

Ответ ChatGPT:

«Принятие решения о завершении тестирования зависит от нескольких факторов и требует сбалансированного подхода. Вот несколько критериев и моментов, которые могут помочь в определении, когда следует прекратить тестирование:

Покрытие тестирования:  Проверьте уровень покрытия тестами. Если ваши тесты охватывают основные функциональные и нефункциональные требования, это может служить хорошим показателем завершенности тестирования.

Достижение критериев приемлемости:  Убедитесь, что продукт соответствует установленным критериям приемлемости, которые были определены на начальном этапе проекта. Эти критерии могут включать в себя требования к производительности, безопасности, надежности и др.

Отсутствие критических ошибок:  Если все критические ошибки были обнаружены, исправлены и подтверждены, это может быть хорошим индикатором готовности к завершению тестирования.

Время и бюджет:  Учтите факторы времени и бюджета. Если вы подходите к концу выделенного времени и бюджета, и качество продукта удовлетворительное, может быть разумным завершить тестирование.

Удовлетворенность заказчика:  Оцените удовлетворенность заказчика. Если заказчик удовлетворен качеством продукта и готов приступить к его использованию или выпуску, это может быть основанием для завершения тестирования.

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

Повторяемость тестов:  Проверьте, что тесты можно успешно повторять. Если результаты тестирования непредсказуемы или тесты нестабильны, это может быть признаком необходимости дополнительных усилий в области тестирования.

Анализ рисков:  Оцените риски, связанные с продолжением тестирования. Если вы успешно управились с наиболее критическими рисками, продолжение тестирования может быть менее критичным.

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

Такой вопрос — отличный образец вопроса «на подумать». Собеседующему очень интересно услышать то, как размышляет кандидат. Мне понравилось, что ответ хорошо структурирован, несмотря на то, что формат мы не задавали, и то, что ответственность за качество возлагается на команду. Но такой вариант породил бы новые дополнительные вопросы из серии: «могут ли быть найдены все ошибки?», «где заканчивается ответственность команды, и где начинается ответственность тестировщика?», «как не погрязнуть в нескончаемых обсуждениях?», «как быть, если требования ограничены или их нет?» Все это стоит учитывать на реальном собеседовании и быть готовым к продолжению диалога по дополнительным вопросам.

Наш запрос:

Переходим к практическому кейсу. Представь, что тебя переводят в команду, которая разрабатывает мобильное приложение, и тебе для тестирования нужно выбрать 2 Android устройства и 2 iOS. Какие ты выберешь?

Ответ ChatGPT: 

«А, ну, выбирать устройства для тестирования... это интересно. Я бы выбрал устройства так, чтобы они охватывали как можно больше разных пользователей. Для Android, наверное, я бы взял что‑то популярное и широко используемое, например, Samsung Galaxy, может быть последнюю модель, чтобы увидеть, как приложение работает на современном устройстве. И еще одно устройство... может быть, более старую модель или устройство среднего класса, чтобы проверить, как приложение работает на менее мощном оборудовании. Может быть, что‑то типа Xiaomi или Huawei.

Для iOS, я бы, конечно, взял последний iPhone, чтобы проверить работу приложения на самой свежей версии iOS. И, наверное, второе устройство должно быть постарше, может быть iPhone 8 или X, чтобы понять, как приложение ведет себя на более старых устройствах и версиях iOS.

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

ChatGPT ответил весьма средненько, возможно, стоит переформулировать промт. Больше всего на собеседовании в этом вопросе мы ожидаем услышать, что для начала было бы неплохо узнать самые популярные устройства целевой аудитории. Если такой статистики еще нет, то составить «портрет» будущего пользователя, и на основе этого подбирать устройства. Например, если приложение корпоративное и будет использоваться менеджерами на конкретных рабочих планшетах, то это автоматически обязательное устройство, которое понадобится тестировщику для тестирования.

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

Ну и последнее — чат не упомянул о различиях в ОС Android, разделив его исключительно на ценовые сегменты.

Наш запрос:

Перейдем к несложной SQL задачке. Есть две таблицы. Таблица Persons с колонками: ID, name (имена сотрудников), position_id (ID должности). И таблица Positions с колонками: ID, position_title. Напишите SQL запрос, который вернет нам имя сотрудника с его должностью. 

Ответ ChatGPT: 

«Конечно, вот пример SQL запроса для получения имен сотрудников и их соответствующих должностей из таблиц Persons и Positions:

SELECT Persons.name AS EmployeeName, Positions.position_title AS PositionTitle FROM Persons JOIN Positions ON Persons.position_id = Positions.ID;

В этом запросе используется оператор JOIN, чтобы объединить таблицы Persons и Positions по столбцам position_id и ID соответственно. Результатом будет таблица, содержащая имена сотрудников и соответствующие им должности».

Вот это ответ достаточно конкретный: такой, какой и был нужен интервьюеру. Попробуем задать дополнительные вопросы.

Наш запрос:

«Выбери все уникальные фамилии тестировщиков?»

Ответ ChatGPT: 

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

Предположим, что в таблице Positions должность тестировщика обозначена как «Тестировщик». В этом случае запрос будет выглядеть следующим образом:

Этот запрос выберет все уникальные фамилии сотрудников, занимающих должность «Тестировщик».

Самую простую SQL-задачку ChatGPT берет достаточно уверенно, справился с джойном, «вспомнил» distinct. Плюсик. Отдельное объяснение итогового запроса текстом тут присутствует, что, несомненно, и правильно при ответе, и важно для подготовки. В случае, если его нет, просим чат дополнительно объяснить свое решение.

Наш запрос:

Перейдем к следующему вопросу. Задача: необходимо проверить поисковую выдачу, в поисковой выдаче — карточки вакансий. Тебе нужно проверить корректность 21-й карточки в выдаче, при условии, что на 1 экран помещается в среднем 2-3 карточки. Как ты автоматизируешь эту проверку?

ChatGPT описал как будет проверять и накидал вот такой код:

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

Мы указали чату на некоторые ошибки: « В задаче сказано, что это поисковая выдача вакансий, значит, скорее всего, она состоит из одинаковых по коду элементов, по умолчанию имеющих одинаковый идентификатор, что приведет к ошибке автотеста, либо к проверке не того элемента. Так же совершенно неправильно явно указывать количество скроллов, так как UI автотесты могут гоняться на разных разрешениях экранов. Сегодня на экран помещается 2–3 вакансии, а завтра 5–6, и тест упадет, хотя функционал работает ». Он исправился и в конце выдал кусочек идеальнейшего кода.

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

Также явное количество скроллов — это грубейшая ошибка. Скроллить нужно до момента, пока элемент не найден. При этом обязательно указав максимальное количество скроллов, которое мы можем позволить автотесту.

Подведем итог

Поболтав с нашим искусственным кандидатом, мы подтвердили свою изначальную мысль, что доверять «по‑крупному» чату нельзя. Он может помочь в решении каких‑то типовых задач, но за ними всегда последуют дополнительные вопросы, чтобы оценить знания, логику и креативное мышление.

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

Полезно использовать чатик во время тренировки решения SQL‑задач, потому что он не только «швыряет» код в виде ответа, как в большинстве онлайн‑тренажерах, но может объяснить предложенный запрос. Особенно это актуально для не сложных селектов, которые часто спрашивают на собеседованиях.

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

Авторы: @Akrpchv,@olgamsk4,@DimaBarboskin

Комментарии (19)


  1. kbnrjlvfrfrf
    21.05.2024 12:14
    +5

    Если ваш собес проходит ChatGPT, значит с вашим собесом всё не так!


    1. olgamsk4
      21.05.2024 12:14

      Со стороны интервьюеров, кстати, тоже можно использовать чат для оценки вопросов, согласна)

      Если хочешь проверить вопрос/задачу на неочевидность и что нужно хорошо подумать - можно задать вопрос чату. Соответственно, если его ответ неправильный или неполный, значит вопрос хороший :D (ну или вопрос неправильный, но это на совести собеседующего).

      Но все равно на собеседованиях часто есть вопросы для проверки общих знаний. Если чат на них отвечает хорошо, не значит, что вопросы не стоит задавать совсем. Главное, чтобы собес не состоял только из таких очевидных вопросов "по учебнику".


      1. kbnrjlvfrfrf
        21.05.2024 12:14
        +1

        Но все равно на собеседованиях часто есть вопросы для проверки общих знаний. Если чат на них отвечает хорошо, не значит, что вопросы не стоит задавать совсем.

        А зачем их задавать, если уже есть очевидный пруф что ответивший на них работу потом работать не сможет? Собеседование предназначего для поиска кандидата который сможет потом работать.


      1. R0bur
        21.05.2024 12:14

        В книге "Верховный алгоритм" Педро Домингос как раз описывает будущее, в котором нейросеть работодателя собеседует нейросети кандидатов и по результатам сразу приглашает работников. Сети, естественно, не универсальные (как ChatGPT), а уникальные, обученные на конкретных персонажах, так что они точно "знают" их возможности и предпочтения. В итоге все счастливы: никому никуда не надо ходить, всё происходит быстро и "автоматически".


  1. EvilSpirits
    21.05.2024 12:14

    Надо попролбовать реальный кейс, с реальным интервью.

    Т.е. попробовать устроиться в реальную компанию (лучше в несколько), тогда будет интереснее.

    Ну и интервьюерам, надо начинать задавать пару-тройку очень сложных и не очень релевантных вопросов, если кандидат легко выдал ответ на них, то за ним сиди чатгпт помошник.


  1. megamrmax
    21.05.2024 12:14
    +2

    на самом деле ваш пример говорит о том, что вместо индусотестеров или джунов можно уже использовать ChatGPT По сути своими вопросами (за исключением первых "стандартноидиотских" типа вспомни самый смешной) которые скорее всего и покрывают 75% задач вы показали, что из трех сотрудников компании можно легко оставить одного :-)


    1. Ratenti
      21.05.2024 12:14

      Разве сейчас уже так не делают?


      1. kysplz
        21.05.2024 12:14

        Я знаю одну девушку тестировщика , которая еле соображает ,но до сих пор там работает , и это отдел тестирования продуктов Совкомбанка


  1. Kahelman
    21.05.2024 12:14
    +1

    « В задаче сказано, что это поисковая выдача вакансий, значит, скорее всего, она состоит из одинаковых по коду элементов, по умолчанию имеющих одинаковый идентификатор, что приведет к ошибке автотеста, либо к проверке не того элемента. Так же совершенно неправильно явно указывать количество скроллов, так как 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…


    1. olgamsk4
      21.05.2024 12:14
      +2

      Мы задаем примерно такой вопрос на собеседованиях мобильных автоматизаторов только для тех, у кого есть реальный опыт автоматизации. 

      Во-первых, для QA, у которых реально есть опыт автоматизации мобилок, сразу понимают суть вопроса и в чем его прикол. Это показательно.

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

      Ну и в третьих, мы не оцениваем ответы на собеседованиях, как правильные/неправильные. Мы обращаем внимание на то, как рассуждал, какие вопросы задавал, какие решения предлагал. Да и на крайний случай, как себя повел, когда пришла "непонятная" задача, если она для него стала таковой.

      Если кандидат отвечает на поставленную задачу прямо, можем сами донакинуть "а если так", "а при обновлении симуляторов что произойдет с этим тестом? А как тогда написать сразу более стабильный" и тп.

      По итогу, если бы мы составляли ТЗ или задачу для тестового задания, на которое нам нужно было сразу выдать готовое правильное решение - вы правы. Но для собеседований я считаю задачу корректной и полезной.


      1. Kahelman
        21.05.2024 12:14

        Чем же «мобильный QA” от не «мобильного» отличается? Тем более что дальше вы говорите:

        « и тест упадёт хотя функционал работает» исходя из этой фразы можно предположить что функционал должен работать и в мобильной и в десктопный версии.

        Мне кажется что ваша позиция обусловлена тем, что вы и заказчик и исполнитель в одном лице. Все меняется если разработка отдана на аутсорс одной компании а QA тестирование делается своими силами или силами другой компании. Тогда у разработчика нет возможности сказать «это не баг -это фича» поскольку QA проверяют то что написано в тесте а не то что разработчик/ аналитик подумал. Когда у вас за Х*1000 тестов, ваши подходы не сработают. Тест должен один в один совпадать со спецификацией.

        Иначе будет такой треш, что сам черт ногу сломит.

        P.S. В рамках собеседования я ответил на ваш вопрос? :)


        1. olgamsk4
          21.05.2024 12:14
          +1

          В данном вопросе мобильный от немобильного может отличаться ограниченным количеством разрешений экрана, например. Если спуститься в вообще конкретный кейс, в например натив на iOS, - симулятор для тестирования обновляется раз в год с обновлением XCode (ну как минимум). Хороший тест для нас это такой, который не упадет из-за того, что ранее он гонялся на более маленьком экране старого айфона. Это как один из примеров специфики, которые мобильные автоматизаторы знают, если с этим работали.

          Сюда же, к примеру, если в элемент выдачи добавилась какая-то новая надпись, ячейки стали шире > на экран симулятора стало помещаться меньше ячеек. Функциональный автотест, который проверяет что-то вообще другое в этом списке не должен упасть из-за этого. И тд и тп.

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

          P.S.: пф, в рамках собеседования вы однозначно ответили на вопрос!))) Мы бы может и продолжили копать эту тему дополнительными нюансами и реальными кейсами, но в целом, профессиональный зачёт, так как было интересно ;)


  1. yanpurvenes
    21.05.2024 12:14

    На рынке есть же продукт, который можно подключить к собесу и он будет исходя из вопрос, сразу представлять ответы от АИ.

    А вообще заданные вопросы сложно отнести к вопрос техническим


  1. Fexele
    21.05.2024 12:14

    Расскажи о своем самом смешном баге в продакшене, который ты пропустил.

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

    Мне кажется, вот правильный ответ на этот вопрос.

    А так тут мало действительно хороших вопросов на критическое мышление и анализ. Я недавно проходил тестовое задание для Амазона, там основное задание - тебе дают разные рабочие ситуации, потом задают по каждой ситуации серию вопросов, тебе просто нужно оценить от 1 до 5 (с разной шкалой оценки) правильное решение в данной ситуации. И таких сценариев десятки и по каждому 5-6 вопросов. Я пробовал скормить это ChatGPT, он не справился с этим. В 9/10 случаев его оценка не совпадала с моей, и, когда я просил его объяснить позицию, я видел, что он очень поверхностно подходит и не может мыслить за гранью сути вопроса.

    То есть дать ответ на конкретные (так ещё и на изъезженные вопросы как в этой статье) он может без труда. А вот правильно анализировать сценарий, где уже надо критически мыслить и иметь понимание всей ситуации, ещё и на основе опыта других ответов - вот тут он теряется. К слову, тестовое я успешно прошёл.


    1. olgamsk4
      21.05.2024 12:14
      +2

      Это очень круто, я вас от души поздравляю) Пройти собеседование в Амазон - звучит мощно!)

      Что касается вопросов. На такие вопросы нет правильных или неправильных ответов. Ваш ответ в том числе является "правильным", если их так категоризировать. 

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

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

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


      1. Fexele
        21.05.2024 12:14

        Не, я прошел только тестовое для Амазона, потом мне назначили техническое интервью через две недели, а за пару дней до него закрыли много позиций QA, в том числе и ту, на которую я собеседовался. А потом ещё небольшая волна сокращений у них была, я уже решил пока с ними не общаться)

        А в остальном, спасибо за разъяснения, мне стало понятнее, почему такой подход к вопросам, это имеет смысл.


  1. Fexele
    21.05.2024 12:14
    +1

    Задайте вопрос ChatGPT: "Ты приходишь на работу, у тебя в рабочем чате пришло сообщение, что тебе надо протестировать страницу про розовых котиков. Твои действия?"

    Он даст развернутый ответ про изучение требований, документацию, сам процесс тестирования. Отличный обширный ответ. Также он скажет, что сразу же приступит к ней. И все это без попытки задуматься, а с чего это он должен делать эту задачу именно сейчас, не уточнит приоритеты и сроки. Не уточнит стадию готовности фичи. Не уточнит степень автоматизации.

    ChatGPT отлично понимает суть вопроса, но не может критически мыслить за его гранью.


    1. Ratenti
      21.05.2024 12:14

      Так это задача руководителя ставить задачи


      1. Fexele
        21.05.2024 12:14
        +3

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