В данном вопросе мобильный от немобильного может отличаться ограниченным количеством разрешений экрана, например. Если спуститься в вообще конкретный кейс, в например натив на iOS, - симулятор для тестирования обновляется раз в год с обновлением XCode (ну как минимум). Хороший тест для нас это такой, который не упадет из-за того, что ранее он гонялся на более маленьком экране старого айфона. Это как один из примеров специфики, которые мобильные автоматизаторы знают, если с этим работали.
Сюда же, к примеру, если в элемент выдачи добавилась какая-то новая надпись, ячейки стали шире > на экран симулятора стало помещаться меньше ячеек. Функциональный автотест, который проверяет что-то вообще другое в этом списке не должен упасть из-за этого. И тд и тп.
Вообще судя по тому, что мы обсуждаем этот кейс, он все-таки интересный. И на собеседовании его было бы так же приятно и полезно обсудить)
P.S.: пф, в рамках собеседования вы однозначно ответили на вопрос!))) Мы бы может и продолжили копать эту тему дополнительными нюансами и реальными кейсами, но в целом, профессиональный зачёт, так как было интересно ;)
Это очень круто, я вас от души поздравляю) Пройти собеседование в Амазон - звучит мощно!)
Что касается вопросов. На такие вопросы нет правильных или неправильных ответов. Ваш ответ в том числе является "правильным", если их так категоризировать.
Такой вопрос для некоторых кандидатов может являться "расслабляющим". Просто в начале вспомнить какой-нибудь забавный рабочий случай. Если вспомнил - здорово. Дальше мы бы пошли по ветви более серьезных вопросов формата "что сделал, чтобы такого больше не допустить". Если не вспомнил и растерялся - звоночек для собеседующего, что кандидат, возможно, сильно нервничает, нужно еще немного поговорить о чем-то или пойти дальше. Если ответил, как вы, вопрос скорее всего будет переформулирован в "самый запомнившийся баг" и какими способами можно было его не допустить.
К тому же, не все вопросы из статьи взяты конкретно из собеседований в нашу компанию. Некоторые вопросы взяты из распространенных, которые подходили для нашей цели - чат хорошо справляется с такими вопросами, это мы и проверяли.
И последнее - каждая компания (а скорее даже каждая команда внутри компании) подбирает вопросы для своих собеседований специально под себя. Вопросы должны раскрывать софт-скиллы кандидата, которые потом будут оцениваться как подходящие или неподходящие для комфортной работы в команде. Задачи подбираются под реальные потребности команды. В каких-то командах есть упор на софт-скиллы, на бизнес ориентированность, в то время как другим может быть нужен жесткий технарь и софт-скиллы отойдут на второй план. В зависимости от этого разные вопросы, разные собеседования.
Мы задаем примерно такой вопрос на собеседованиях мобильных автоматизаторов только для тех, у кого есть реальный опыт автоматизации.
Во-первых, для QA, у которых реально есть опыт автоматизации мобилок, сразу понимают суть вопроса и в чем его прикол. Это показательно.
Во-вторых, стараемся задавать открытые вопросы. Все вопросы разговорные, "не жесткие" задачи, поэтому на мой взгляд НЕ задать сразу все условия и озвучить все нюансы для задачи на собеседовании - это нормально. Кандидат может задать сколько угодно уточняющих вопросов - на все получит ответы.
Ну и в третьих, мы не оцениваем ответы на собеседованиях, как правильные/неправильные. Мы обращаем внимание на то, как рассуждал, какие вопросы задавал, какие решения предлагал. Да и на крайний случай, как себя повел, когда пришла "непонятная" задача, если она для него стала таковой.
Если кандидат отвечает на поставленную задачу прямо, можем сами донакинуть "а если так", "а при обновлении симуляторов что произойдет с этим тестом? А как тогда написать сразу более стабильный" и тп.
По итогу, если бы мы составляли ТЗ или задачу для тестового задания, на которое нам нужно было сразу выдать готовое правильное решение - вы правы. Но для собеседований я считаю задачу корректной и полезной.
Со стороны интервьюеров, кстати, тоже можно использовать чат для оценки вопросов, согласна)
Если хочешь проверить вопрос/задачу на неочевидность и что нужно хорошо подумать - можно задать вопрос чату. Соответственно, если его ответ неправильный или неполный, значит вопрос хороший :D (ну или вопрос неправильный, но это на совести собеседующего).
Но все равно на собеседованиях часто есть вопросы для проверки общих знаний. Если чат на них отвечает хорошо, не значит, что вопросы не стоит задавать совсем. Главное, чтобы собес не состоял только из таких очевидных вопросов "по учебнику".
Все верно, у нас два приложения - iOS и Android. И да, на них пишутся плюс-минус одинаковые автотесты.
Править автотесты действительно приходится и там, и там в случае каких-то изменений. Но так как у нас автотесты нативные, их могут поправить сами разработчики после своих задач. У нас они не только «могут поправить», но и делают это. То есть все небольшие правки-изменения не блокируются загрузкой тестировщика, а могут быть сделаны кем угодно в команде. Наше дело в таких случаях - обязательное ревью. Плюс тут хочется добавить, что если автотесты правильно спроектированы, то править их не сложно и быстро.
По поводу тестовых данных. Автотесты гоняются на тестовых стендах - копия прода без продовой базы данных. Для создания тестовых данных у нас есть фикстуры - апи для создания тестовых данных на стенде. Для каждого автотеста создаются уникальные тестовые данные. Одни и те же созданные данные не могут использоваться в двух и более тестах, так что никаких пересечений нет.
Вот тут кстати можно посмотреть, как у нас выглядят и создаются тестовые данные - https://habr.com/ru/company/hh/blog/455042/
Именно end-to-end UI автотестов, которые пишут тестировщики, у нас в данный момент на Android - 363, на iOS - 440. Тестировщиков 5. В остальном, как мы занимаемся поддержкой и кто за что отвечает, уже рассказала в статье.
Поддержкой и настройкой тестовых сред у нас занимается отдельная команда. Это команда девопсов, состоящая из 5 человек, которая занимается всем тестовым бэкендом компании, железом и администрированием CI-сервера.
По факту из этой команды нам обычно помогает один человек, и в основном это настройки железа. Но это не совсем частые задачи, так что в целом времени на это у команды инфраструктуры уходит не много.
Всей мобильной спецификой инфраструктуры занимаемся мы сами. И тестировщики, и разработчики. На нас такие задачи, как настройка CI, скрипты и автоматизации под мобилки. В основном такие задачу попадают на платформенные кор-команды (2 разработчика с каждой платформы, но это, конечно, не единственное, чем они занимаются).
Ручные тестировщики, которые у нас постепенно превращаются в автоматизаторов, наравне с разработчиками берут задачи, связанные с инфраструктурой. Это одно из направлений развития.
Нас было 4 тестировщика на 4 мобильных приложения (по 2 приложения на 2 платформы) - 2 тестировщика уже умели автоматизировать, 2 пришли учиться автоматизировать с нуля. При этом уровень мануального тестирования у всех был мидл+.
Релизы были примерно раз в две недели (выпускали приложения попарно: первую неделю первое на обе платформы, вторую неделю - второе). Тогда, два года назад, релиз-трейн у нас был только в планах и еще не встал на рельсы. Но это скорее даже минус, так как многие задачи приходилось тестировать обязательно и срочно, чтобы выпустить релиз.
Разработчиков на 4 тестировщика было примерно человек 15, задач было достаточно много, и были все шансы закопаться в них на 100%, но мы сделали именно так, как я пишу в статье - для каждого тестировщика один день в неделю ставили автоматизацию первым приоритетом.
Ну и не знаю, насколько корректно писать об этом здесь же, но когда участвуешь в автоматизации регресса с самого начала, у тебя есть особый азарт и интерес этим заниматься, поэтому время на первые автотесты находилось очень часто у тестировщиков и в самые загруженные дни по остаточному принципу.
Стоит так же отметить, что да, какое-то продолжительное время покрываться автотестами будет именно регресс - устоявшийся, редко меняющийся, стабильный функционал. До покрытия автотестами нового функционала мы вот пришли только спустя полтора года.
На счет качества получаемых таким образом автотестов. Да, по началу они могут быть написаны кривовато и флаковать, но со временем тестировщик будет лучше понимать как всё работает, как написать лучше, как сделать так, чтобы меньше флаковало и работало стабильнее. То есть чем дальше, тем тесты будут лучше и качественнее. Плюс, автотесты должны проходить ревью от кого-нибудь, кто в этом разбирается. Тогда в код не будет просачиваться совсем уж что-то на джунском)
Мое мнение на счет 1 тестировщика на 7 разработчиков - тут всё реально, если разработчики помогут своему тестировщику с первыми автотестами и настройкой всего для автоматизации. Дальше тесты уже пишутся очень просто и быстро. Самое сложное всегда это начать. В нашем случае было просто во-первых потому что разработчики нам помогали, а во-вторых, что нас было 2-4, а не 1. Всегда была возможность договориться между собой, что один возьмет на себя чуть больше ручного, чтобы освободить время другому не отвлекаться и довести автотесты до пул реквеста.
Для таких быстрых проверок существует статический анализ, который для своего проекта можно настроить максимально комфортно, и все подобные «опечатки» будут выявляться сразу. (У нас максимально быстро приходит сообщение об ошибках такого рода).
Так же для быстрой проверки, что ветка ничего не сломала есть юнит-тесты, которые мы запускаем на PR-ах. Это тоже достаточно быстрый способ узнать, что все ок и получить уже более существенные ошибки.
Разработчики, разумеется, гоняют юнит-тесты и стат. анализ локально.
UI-тесты это уже полная проверка всего приложения. Их не имеет смысла запускать на каждом коммите, это верно (по крайней мере полный набор). Но перед каждым мержем в девелоп уже стоит. Тут стоит еще сказать, что у нас не trunk-base.
Плюс то, что все эти тесты будут запускаться на CI не исключает возможности запустить эти же тесты локально. Все или какие-то отдельные, связанные с вашим функционалом. Это уже по желанию самих разработчиков.
Также для отладки мы сделали специальные планы на CI, в которых можно запустить не все тесты, а только помеченные аннотацией. Их часто используют для отладки
Стоит уточнить, что по большей части я тут говорю про UI-тесты.
В настоящее время достаточно много проектов (особенно в мобильной разработке), которые выпускаются/разрабатываются без тестов. Не без тестирования, а именно без тестов. Такие проекты просто тестируются силами ручных тестировщиков.
Почему говорю, что тесты должны запускаться на CI.
Запускать тесты локально - не стабильно, можно пропустить этот момент, забить на какие-то фэйлы или пропустить их.
По расписанию - уже ближе к истине, но между двумя запусками могут случиться «множественные» мержи и потом нужно будет дольше разбираться, чьи изменения повлияли.
В примере с цепочкой вызовов методов у меня именно так и написано. За исключением, что в вашем примере нужно еще дополнительно создать объект экрана mainScreen, то есть
let mainScreen = pageObjectFactory.makeMainScreenPageObject()
Ну или если у вас нет дополнительных параметров при инициаилизации PO-в и вы не выносите их в фабрику, то
let mainScreen = MainScreenPageObject()
openProfileTab() у нас так же возвращает ProfileScreen().
Если вопрос про описанные сложности с таббаром, то тут суть, что openProfileTab() должен быть доступен не только с MainScreen, но и с почти любого другого PO-а.
В данном вопросе мобильный от немобильного может отличаться ограниченным количеством разрешений экрана, например. Если спуститься в вообще конкретный кейс, в например натив на iOS, - симулятор для тестирования обновляется раз в год с обновлением XCode (ну как минимум). Хороший тест для нас это такой, который не упадет из-за того, что ранее он гонялся на более маленьком экране старого айфона. Это как один из примеров специфики, которые мобильные автоматизаторы знают, если с этим работали.
Сюда же, к примеру, если в элемент выдачи добавилась какая-то новая надпись, ячейки стали шире > на экран симулятора стало помещаться меньше ячеек. Функциональный автотест, который проверяет что-то вообще другое в этом списке не должен упасть из-за этого. И тд и тп.
Вообще судя по тому, что мы обсуждаем этот кейс, он все-таки интересный. И на собеседовании его было бы так же приятно и полезно обсудить)
P.S.: пф, в рамках собеседования вы однозначно ответили на вопрос!))) Мы бы может и продолжили копать эту тему дополнительными нюансами и реальными кейсами, но в целом, профессиональный зачёт, так как было интересно ;)
Это очень круто, я вас от души поздравляю) Пройти собеседование в Амазон - звучит мощно!)
Что касается вопросов. На такие вопросы нет правильных или неправильных ответов. Ваш ответ в том числе является "правильным", если их так категоризировать.
Такой вопрос для некоторых кандидатов может являться "расслабляющим". Просто в начале вспомнить какой-нибудь забавный рабочий случай. Если вспомнил - здорово. Дальше мы бы пошли по ветви более серьезных вопросов формата "что сделал, чтобы такого больше не допустить". Если не вспомнил и растерялся - звоночек для собеседующего, что кандидат, возможно, сильно нервничает, нужно еще немного поговорить о чем-то или пойти дальше. Если ответил, как вы, вопрос скорее всего будет переформулирован в "самый запомнившийся баг" и какими способами можно было его не допустить.
К тому же, не все вопросы из статьи взяты конкретно из собеседований в нашу компанию. Некоторые вопросы взяты из распространенных, которые подходили для нашей цели - чат хорошо справляется с такими вопросами, это мы и проверяли.
И последнее - каждая компания (а скорее даже каждая команда внутри компании) подбирает вопросы для своих собеседований специально под себя. Вопросы должны раскрывать софт-скиллы кандидата, которые потом будут оцениваться как подходящие или неподходящие для комфортной работы в команде. Задачи подбираются под реальные потребности команды. В каких-то командах есть упор на софт-скиллы, на бизнес ориентированность, в то время как другим может быть нужен жесткий технарь и софт-скиллы отойдут на второй план. В зависимости от этого разные вопросы, разные собеседования.
Мы задаем примерно такой вопрос на собеседованиях мобильных автоматизаторов только для тех, у кого есть реальный опыт автоматизации.
Во-первых, для QA, у которых реально есть опыт автоматизации мобилок, сразу понимают суть вопроса и в чем его прикол. Это показательно.
Во-вторых, стараемся задавать открытые вопросы. Все вопросы разговорные, "не жесткие" задачи, поэтому на мой взгляд НЕ задать сразу все условия и озвучить все нюансы для задачи на собеседовании - это нормально. Кандидат может задать сколько угодно уточняющих вопросов - на все получит ответы.
Ну и в третьих, мы не оцениваем ответы на собеседованиях, как правильные/неправильные. Мы обращаем внимание на то, как рассуждал, какие вопросы задавал, какие решения предлагал. Да и на крайний случай, как себя повел, когда пришла "непонятная" задача, если она для него стала таковой.
Если кандидат отвечает на поставленную задачу прямо, можем сами донакинуть "а если так", "а при обновлении симуляторов что произойдет с этим тестом? А как тогда написать сразу более стабильный" и тп.
По итогу, если бы мы составляли ТЗ или задачу для тестового задания, на которое нам нужно было сразу выдать готовое правильное решение - вы правы. Но для собеседований я считаю задачу корректной и полезной.
Со стороны интервьюеров, кстати, тоже можно использовать чат для оценки вопросов, согласна)
Если хочешь проверить вопрос/задачу на неочевидность и что нужно хорошо подумать - можно задать вопрос чату. Соответственно, если его ответ неправильный или неполный, значит вопрос хороший :D (ну или вопрос неправильный, но это на совести собеседующего).
Но все равно на собеседованиях часто есть вопросы для проверки общих знаний. Если чат на них отвечает хорошо, не значит, что вопросы не стоит задавать совсем. Главное, чтобы собес не состоял только из таких очевидных вопросов "по учебнику".
Все верно, у нас два приложения - iOS и Android. И да, на них пишутся плюс-минус одинаковые автотесты.
Править автотесты действительно приходится и там, и там в случае каких-то изменений. Но так как у нас автотесты нативные, их могут поправить сами разработчики после своих задач. У нас они не только «могут поправить», но и делают это. То есть все небольшие правки-изменения не блокируются загрузкой тестировщика, а могут быть сделаны кем угодно в команде. Наше дело в таких случаях - обязательное ревью. Плюс тут хочется добавить, что если автотесты правильно спроектированы, то править их не сложно и быстро.
По поводу тестовых данных. Автотесты гоняются на тестовых стендах - копия прода без продовой базы данных. Для создания тестовых данных у нас есть фикстуры - апи для создания тестовых данных на стенде. Для каждого автотеста создаются уникальные тестовые данные. Одни и те же созданные данные не могут использоваться в двух и более тестах, так что никаких пересечений нет.
Вот тут кстати можно посмотреть, как у нас выглядят и создаются тестовые данные - https://habr.com/ru/company/hh/blog/455042/
Именно end-to-end UI автотестов, которые пишут тестировщики, у нас в данный момент на Android - 363, на iOS - 440. Тестировщиков 5. В остальном, как мы занимаемся поддержкой и кто за что отвечает, уже рассказала в статье.
Поддержкой и настройкой тестовых сред у нас занимается отдельная команда. Это команда девопсов, состоящая из 5 человек, которая занимается всем тестовым бэкендом компании, железом и администрированием CI-сервера.
По факту из этой команды нам обычно помогает один человек, и в основном это настройки железа. Но это не совсем частые задачи, так что в целом времени на это у команды инфраструктуры уходит не много.
Всей мобильной спецификой инфраструктуры занимаемся мы сами. И тестировщики, и разработчики. На нас такие задачи, как настройка CI, скрипты и автоматизации под мобилки. В основном такие задачу попадают на платформенные кор-команды (2 разработчика с каждой платформы, но это, конечно, не единственное, чем они занимаются).
Ручные тестировщики, которые у нас постепенно превращаются в автоматизаторов, наравне с разработчиками берут задачи, связанные с инфраструктурой. Это одно из направлений развития.
Предусловия у нас были такие:
Нас было 4 тестировщика на 4 мобильных приложения (по 2 приложения на 2 платформы) - 2 тестировщика уже умели автоматизировать, 2 пришли учиться автоматизировать с нуля. При этом уровень мануального тестирования у всех был мидл+.
Релизы были примерно раз в две недели (выпускали приложения попарно: первую неделю первое на обе платформы, вторую неделю - второе). Тогда, два года назад, релиз-трейн у нас был только в планах и еще не встал на рельсы. Но это скорее даже минус, так как многие задачи приходилось тестировать обязательно и срочно, чтобы выпустить релиз.
Разработчиков на 4 тестировщика было примерно человек 15, задач было достаточно много, и были все шансы закопаться в них на 100%, но мы сделали именно так, как я пишу в статье - для каждого тестировщика один день в неделю ставили автоматизацию первым приоритетом.
Ну и не знаю, насколько корректно писать об этом здесь же, но когда участвуешь в автоматизации регресса с самого начала, у тебя есть особый азарт и интерес этим заниматься, поэтому время на первые автотесты находилось очень часто у тестировщиков и в самые загруженные дни по остаточному принципу.
Стоит так же отметить, что да, какое-то продолжительное время покрываться автотестами будет именно регресс - устоявшийся, редко меняющийся, стабильный функционал. До покрытия автотестами нового функционала мы вот пришли только спустя полтора года.
На счет качества получаемых таким образом автотестов. Да, по началу они могут быть написаны кривовато и флаковать, но со временем тестировщик будет лучше понимать как всё работает, как написать лучше, как сделать так, чтобы меньше флаковало и работало стабильнее. То есть чем дальше, тем тесты будут лучше и качественнее. Плюс, автотесты должны проходить ревью от кого-нибудь, кто в этом разбирается. Тогда в код не будет просачиваться совсем уж что-то на джунском)
Мое мнение на счет 1 тестировщика на 7 разработчиков - тут всё реально, если разработчики помогут своему тестировщику с первыми автотестами и настройкой всего для автоматизации. Дальше тесты уже пишутся очень просто и быстро. Самое сложное всегда это начать. В нашем случае было просто во-первых потому что разработчики нам помогали, а во-вторых, что нас было 2-4, а не 1. Всегда была возможность договориться между собой, что один возьмет на себя чуть больше ручного, чтобы освободить время другому не отвлекаться и довести автотесты до пул реквеста.
Для таких быстрых проверок существует статический анализ, который для своего проекта можно настроить максимально комфортно, и все подобные «опечатки» будут выявляться сразу. (У нас максимально быстро приходит сообщение об ошибках такого рода).
Так же для быстрой проверки, что ветка ничего не сломала есть юнит-тесты, которые мы запускаем на PR-ах. Это тоже достаточно быстрый способ узнать, что все ок и получить уже более существенные ошибки.
Разработчики, разумеется, гоняют юнит-тесты и стат. анализ локально.
UI-тесты это уже полная проверка всего приложения. Их не имеет смысла запускать на каждом коммите, это верно (по крайней мере полный набор). Но перед каждым мержем в девелоп уже стоит. Тут стоит еще сказать, что у нас не trunk-base.
Плюс то, что все эти тесты будут запускаться на CI не исключает возможности запустить эти же тесты локально. Все или какие-то отдельные, связанные с вашим функционалом. Это уже по желанию самих разработчиков.
Также для отладки мы сделали специальные планы на CI, в которых можно запустить не все тесты, а только помеченные аннотацией. Их часто используют для отладки
Стоит уточнить, что по большей части я тут говорю про UI-тесты.
В настоящее время достаточно много проектов (особенно в мобильной разработке), которые выпускаются/разрабатываются без тестов. Не без тестирования, а именно без тестов. Такие проекты просто тестируются силами ручных тестировщиков.
Почему говорю, что тесты должны запускаться на CI.
Запускать тесты локально - не стабильно, можно пропустить этот момент, забить на какие-то фэйлы или пропустить их.
По расписанию - уже ближе к истине, но между двумя запусками могут случиться «множественные» мержи и потом нужно будет дольше разбираться, чьи изменения повлияли.
Ну или если у вас нет дополнительных параметров при инициаилизации PO-в и вы не выносите их в фабрику, то
openProfileTab() у нас так же возвращает ProfileScreen().
Если вопрос про описанные сложности с таббаром, то тут суть, что openProfileTab() должен быть доступен не только с MainScreen, но и с почти любого другого PO-а.