Комментарии 7
Так у вас получается 2 проекта тестирования, которые надо как то синхронизовать. Писать одинаковые тесты с проверками. Писать одни и теже шаги. Править при изменении оба проекта...
Но самое главное ведь в крупных проектах это создание тестовых данных. Как вы это делаете имея 2 различных по коду проекта?
Интересно сколько у вас тестов в каждом проекте и сколько автотестеров их поддерживает?
Все верно, у нас два приложения - iOS и Android. И да, на них пишутся плюс-минус одинаковые автотесты.
Править автотесты действительно приходится и там, и там в случае каких-то изменений. Но так как у нас автотесты нативные, их могут поправить сами разработчики после своих задач. У нас они не только «могут поправить», но и делают это. То есть все небольшие правки-изменения не блокируются загрузкой тестировщика, а могут быть сделаны кем угодно в команде. Наше дело в таких случаях - обязательное ревью. Плюс тут хочется добавить, что если автотесты правильно спроектированы, то править их не сложно и быстро.
По поводу тестовых данных. Автотесты гоняются на тестовых стендах - копия прода без продовой базы данных. Для создания тестовых данных у нас есть фикстуры - апи для создания тестовых данных на стенде. Для каждого автотеста создаются уникальные тестовые данные. Одни и те же созданные данные не могут использоваться в двух и более тестах, так что никаких пересечений нет.
Вот тут кстати можно посмотреть, как у нас выглядят и создаются тестовые данные - https://habr.com/ru/company/hh/blog/455042/
Именно end-to-end UI автотестов, которые пишут тестировщики, у нас в данный момент на Android - 363, на iOS - 440. Тестировщиков 5. В остальном, как мы занимаемся поддержкой и кто за что отвечает, уже рассказала в статье.
Да интересно. Но все-таки 2 проекта по мне накладных расходов больше. Переключения Kotlin/XCUItest/Api.
У нас сейчас 822 E2E теста. Для Android и iOS. Java. На Java написаны E2E и API тесты и все создание тестовых данных. Т.к. сервер на яве тоже, то девы иногда помогают или чинят когда автоматчики в отпуске.
Автоматчиков 2 на все E2E и API (WEB есть тоже, но там мало. Простой он у нас. 50 тестов).
Да кроссплатфома Appium + Java + testNG + maven + allureReport + TestRail (для релизов). Один повтор если тест упал по hard Assertu.
Идшки в iOS начинали сами проставлять. Потом девы помогли сделали генерацию на лету для тест билдов. Теперь лезу туда реже в основном для динамических компонентов.
В Андроиде тоже не без подачи автоматчиков навели порядок. Опять только динамические элементы больше проблема.
Но самое интересное т.к. тесты стали использовать или просить по фунционалу запускать девелоперы сами, то теперь сами стали заботится об этих идшках, если переписывают компоненты.
Флаки только серверные. У нас много third-party компонентов на серваке, а моки не пишут. В результате иногда не пашет. Плюс есть стабильные баги, которые жить не мешают, а тесты по ним сделаны. Наверно это как у всех - всегда есть проблемы по мелочи.
Пример. Ночные у нас бегают по 500 на каждой платформе. Среднее колво падений около 20-25 на платфому. Из них известные проблемы обычно около 15-18. А остальные как раз проблемы third-party сервисов, которые иногда (раз в 2 недели точно) могут и вырасти до 100 если упало совсем чтото. Тогда ругаемся и чинят сервер.
Все падения сверху это или изменения в клиентах или на сервере (скажем поменяли API).
Все ручные тестеры кто хочет автоматизировать пытаемся обучить. Но выхлоп пока мал.
Все тесты у нас с видео. Ошибки человеческие (типа нет кнопки Логин. Экран Info не появился). Это все привело к тому, что проверять результаты тестов стали ручники и девелоперы сами.
... ой не туда отправил...
ТОП-5 вопросов технического директора про автоматизацию