Все верно, у нас два приложения - 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 и 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-а.