Строго говоря, это вообще не относится к тестированию приложения (если бизнес-логика не размазана и на слой хранимок). Тут тестирование БД. А ее и не нужно тестировать — просто ищешь результаты таких тестов и помнишь про ограничения.
На сколько понял — самое слабое место, с точки зрения производительности, это получение тестовых данных из БД. Так может вообще отказаться от этого? Тем более рандомом нельзя гарантировать проверку всех кейсов. Лучше написать качественные дата-провайдеры, которые будут генерить необходимые данные для всех кейсов.
Вместо того, чтобы решать проблему (неумение тестировать не на копии прода), боремся со следствием…
P.S. еще мы теперь знаем, что весь IT-отдел имеет доступ к реальным данным клиентов Ренессанс Кредит.
UI Automator имеет больше возможностей взаимодействия с ОС, например, может включить wi-fi. Espresso взаимодействует только с одним приложением, но немного удобнее и проще. Прочитайте сравнения, их полно, и выбирайте из ваших потребностей.
В говорите, что товары, которые нужно положить в корзину, прописаны хардкодом в методе? Это по определению плохо. Вместо «добавь в корзину два предмета» нужно сделать «добавь в корзину предмет»(«название предмета»). И в тесте явно указывать название: myApp.addProductToCart("Яндекс.Станция");
Уровень с тестами был бы одинаковый, различия только в бизнес-логике (возможно, частично) и page object. Создаем свой класс для каждой платформы — TestApplicationAndroid и TestApplicationIOs, если есть общие методы, то выделяем их в родительский класс. Тесты запускаем с параметром (название платформы) и добавляем логику в setUp() — какой класс использовать для переменной myApp.
Благодарю)
На самом деле, хотел все реализовать на Appium, тогда тесты и часть бизнес-логики можно было бы переиспользовать для iOS. Но не получилось договорится со всеми заинтересованными сторонами… Решил пока попробовать так, это лучше, чем месяцами спорить про инструменты.
А когда дойдем до iOS, будем дальше думать.
А вот чего в нашем процессе тестирования нет, так это постоянной интеграции. Она нам не подходит, потому что есть накопленное «историческое наследие».
И на протяжении трех месяцев каждую ночь автоматически собирается и выкладывается новая сборка.… Если всё в порядке, запускаются все автотесты.
Ночные сборки с запуском тестов это и есть CI, на сколько могу судить.
Сейчас наш полный цикл ночных автотестов наконец-то стал укладываться в ночное время. Раньше он занимал около 32 часов.
Смок тест 32 часа? Да даже есть 8 (ночь) все равно как-то не тянет. Или какие тесты вы запускаете ночью? На картинке с видами тестирования у вас регресс в колонке с ручным. Наверное, только полный регресс может столько времени занимать
— «Что планируешь делать для достижения цели спринта?»
— «Ну, я для цели ничего не могу сделать, поэтому будут пилить эту штуку.»
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.
На самом деле было бы интересно послушать реальный пример решения подобной проблемы. Т.е. была такая ситуация, полгода делали такие-то упражнения, итог такой-то.
Про мою ситуацию — да все, вроде, было по гайду, но «механически», как вы выразились. И вот это все «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.» было, все соглашались и придумывали решения. Но потом ничего не делали и все возвращалось на круги своя. И я не знал как сделать так, чтобы они захотели сплотиться и сделать все красиво.
Единственным решением, мне виделось, это устраивать бесконечные ретро и индивидуальные разговоры. Помогать выбирать нужные для цели задачи. Водить за ручку на нужные встречи. И так далее. Может быть через какое-то время мы бы и взлетели. А может реально людям неинтересно это было и ничего бы не помогло… У всех так в начале или это запущенный случай? :)
А где самое главное? Как из группы людей сделать команду?
У меня был опыт когда практически все проблемы, описанные в статье, были решены. Но все равно командой разработчиков в том проекте нельзя было называть. Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец». А то, что цель не достигнута или инкремент не работает, это не их вина…
Что в таком случае делать? Разгонять всех и искать новых или надежда есть?
Я бы больше сказал: вам не нужны тестеры и автотестеры. Берите QA-специалистов. Да, они могут стоить как разработчики, но зато они сами прекрасно знают как обеспечить качество на проекте (даже если для этого потребуется заставить программистов заниматься ручным тестированием). Умение автоматизировать для них всего-лишь инструмент.
Не очень понятно, чем selenoid не подошел? Перед ним также можно поставить go grid router и балансер, проблем с масштабируемостью точно быть не должно. И оркестрация зачем вам? Обновлять образы контейнеров? У селеноид есть вроде менеджер конфигураций для этого.
А пулл реквестить селеноид и ggr не думали?
Перешел по ссылке с вехами где, даже не успев что-то прочитать, начал лицезреть появившейся на всю страницу баннер с предложением подписаться. Итог — закрыл конечно же страницу.
Может не в тему, но вы отслеживаете действия пользователей на сайте? Что такая тема работает? По своему опыту скажу, что я останусь на сайте с таким поведением только если мне ну оооочень нужно прочитать то, что там под баннером.
P.S. еще мы теперь знаем, что весь IT-отдел имеет доступ к реальным данным клиентов Ренессанс Кредит.
myApp.addProductToCart("Яндекс.Станция");TestApplicationAndroidиTestApplicationIOs, если есть общие методы, то выделяем их в родительский класс. Тесты запускаем с параметром (название платформы) и добавляем логику вsetUp()— какой класс использовать для переменнойmyApp.А как вы портировали тесты на iOS?
На самом деле, хотел все реализовать на Appium, тогда тесты и часть бизнес-логики можно было бы переиспользовать для iOS. Но не получилось договорится со всеми заинтересованными сторонами… Решил пока попробовать так, это лучше, чем месяцами спорить про инструменты.
А когда дойдем до iOS, будем дальше думать.
Ночные сборки с запуском тестов это и есть CI, на сколько могу судить.
Смок тест 32 часа? Да даже есть 8 (ночь) все равно как-то не тянет. Или какие тесты вы запускаете ночью? На картинке с видами тестирования у вас регресс в колонке с ручным. Наверное, только полный регресс может столько времени занимать
— «Ну, я для цели ничего не могу сделать, поэтому будут пилить эту штуку.»
А задачи для цели делают 2-3 человека (из 8) и в итоге не успевают. По идее, если не успевают, то вся команда должна навалиться и сделать, но сами они это делать не будут.
Про мою ситуацию — да все, вроде, было по гайду, но «механически», как вы выразились. И вот это все «Вы согласны что ситуация нехорошая? А давайте найдем способ, как избежать подобной ситуации в будущем.» было, все соглашались и придумывали решения. Но потом ничего не делали и все возвращалось на круги своя. И я не знал как сделать так, чтобы они захотели сплотиться и сделать все красиво.
Единственным решением, мне виделось, это устраивать бесконечные ретро и индивидуальные разговоры. Помогать выбирать нужные для цели задачи. Водить за ручку на нужные встречи. И так далее. Может быть через какое-то время мы бы и взлетели. А может реально людям неинтересно это было и ничего бы не помогло… У всех так в начале или это запущенный случай? :)
У меня был опыт когда практически все проблемы, описанные в статье, были решены. Но все равно командой разработчиков в том проекте нельзя было называть. Не было групповой ответственности, все продолжали жить в парадигме «я сделал свою задачу, я молодец». А то, что цель не достигнута или инкремент не работает, это не их вина…
Что в таком случае делать? Разгонять всех и искать новых или надежда есть?
А пулл реквестить селеноид и ggr не думали?
Может не в тему, но вы отслеживаете действия пользователей на сайте? Что такая тема работает? По своему опыту скажу, что я останусь на сайте с таким поведением только если мне ну оооочень нужно прочитать то, что там под баннером.