Как стать автором
Обновить

Комментарии 28

выходит сопоставимо со всеми затратами на одного тестировщика (учитывая прямые и косвенные)

Цена зависит от нагрузки (количества тестов, запускаемых в сутки) или пока не насоздают ощутимую кучу, будут платить за пустоту по цене одного тестировщика?

Не совсем понял о какой именно цене идет речь, но предполагаю, что о цене на лицензию решения с одним роботом. Стоимость лицензии никак не зависит от того, как вы ее используете, она дает вам право использовать робота как вы захотите 24х7, а дальше уже ваше дело: загружаете ли вы робота по полной или он выполняет одну задачку за 1 час в сутки.

В статье сравнивались затраты на 1 полностью загруженного тестировщика (8 часов в день) и 1 робота, который может работать 24 часа в сутки. То есть, если переложить восьмичасовую работу одного сотрудника на робота, даже не принимая во внимание тот факт, что он справится с делом быстрее - он будет способен дать вам еще 16 часов работы (отсюда в тексте есть упоминание, что 1 робот может заменить 3 тестировщиков).

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

Стоимость автотестов надо считать как TCO и они окупаются не за 5 минут. Соответственно да, сначала вы будете инвестировать, а ROI будет совсем не сразу

Два простых вопроса:


  1. Как обеспечивается версионирование тестов и поддержание согласованности версии тестов и версии тестируемой системы?
  2. Как воспроизвести конкретный упавший тест на компьютере разработчика?
  1. Версионирование тестов осуществляется штатными средствами платформы, перед тем как запускать тесты на роботах - их нужно опубликовать на сервере (в оркестраторе), при публикации создается пакет с новым номером версии.
    Согласованность с версиями стороннего ПО можно организовать на уровне ALM вашего ПО, либо непосредственно в UIPath Test Manager, если вы осуществляете тестирование стороннего ПО (например, которое вам делают подрядчики или публичные облачные службы).

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

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

Версионирование тестов осуществляется штатными средствами платформы

Я не знаю, что такое "штатные средства платформы". Можете пояснить?


Согласованность с версиями стороннего ПО можно организовать на уровне ALM вашего ПО

Можете пояснить?


Соответственно, разработчик может взять нужную версию и прогнать упавшие варианты, которые в нем доступны

Прогнать локально? Что для этого нужно?


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

Мне не настолько интересно пока, чтобы тратить время на пробную версию. А что касается документации — я даже прайсинг не смог найти за пять минут, только Contact Sales.

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

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

Ну то есть вы написали откровенно рекламную статью — заметим, не в корпоративном блоге — и даже не готовы отвечать на вопросы по рекламируемому продукту?

С таким подходом как у вас, можно назвать рекламными все статьи, которые посвящены применению Microsoft Visual Studio, InelliJ IDEA и прочим средам разработки. UiPath - это тоже среда разработки, которую использует очень много компаний по всему миру. А дальше лишь вопрос как эту среду разработки применять, об одном из способов применения я рассказал в этой статье.

Может быть вы поищете десяток статей про тестирование на MS VS, IDEA, PyCharm и тоже напишете в комментариях, что те статьи являются рекламными, если вам не ответят на вопросы, ответы на которые вы можете найти в документации? Или "это другое"?

Возможно, вам в принципе противно любое упоминание RPA, и я вас прекрасно понимаю. Еще года три назад я сам плевался ядом на любое упоминание такого подхода. Так что позволю себе роскошь и не буду в дальнейшем отвечать на ваши комментарии, которые полностью противоречат Хабраэтикету из официальных правил сайта: https://habr.com/ru/docs/help/rules/

Но я буду всегда рад увидеть вас в будущем в рядах интересующихся перспективными технологиями.

С таким подходом как у вас, можно назвать рекламными все статьи, которые посвящены применению Microsoft Visual Studio, InelliJ IDEA и прочим средам разработки

Только разница в том, что Microsoft и Jetbrains в своих блогах нормально отвечают на все вопросы о продуктах без выкриков рода "Иди читай документацию и пробуй пробную версию сам"

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

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

Возможно. Из статьи и комментов возникло ощущение некой аффилированности. Опровержения или подтверждения этому в профиле я не увидел.


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

Работаю вместе с автором, статья не закащная (потому что мы ее не заказывали, у мы нас есть отдельное PR агентство), но правдивая.

Не очень понятно, почему мы не можем использовать тот инструмент, который наша компания разрабатывает и рассказать об опыте его применения? Или вы считаете, что человек, использующий в работе платное ПО автоматически пишет заказу? Я например, обожаю продукты JetBrains, активно их использую, при этом никак с ними не аффилирован. Моя статья о том, что бесплатный Codelite мешает, а PhpStorm помогает разрабатывать, тоже вызовет ваш гнев?

  1. Версионирование - git + nuget server

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

Моки есть:) mocks

то целый блок появляется на несвойственной ему странице

Тестируется ли такое? А то протестировать что есть легко, а вот как протестировать то чего быть не должно.

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

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

Проверяется методом поиска такого элемента на странице (в вышеупомянутом UiPath это делается методом Check App State). Если он найден тогда, когда не должен выводится - считаем, что ошибка.

Я как тест с time.sleep увидел - понял что ничего хорошего от поста ждать не приходится...

Серьезно в 2022 году автоматизировать веб с помощью робота мышки и записи сценариев аля selenium IDE ?

В чем плюс этого инструмента? В универсальности?

Нет смысла смешивать разные виды тестирования в одном инструменте..

Опять же - ладно выбрали новый крутой(нет) инструмент, но поддержка, решение проблем и коммьюнити?

В общем к посту больше вопросов, чем ответов.

В чем плюс этого инструмента? В универсальности?

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

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

Конечно, если у вас только web, который вы пишете сами - использовать указанный в статье инструмент может быть слегка Overkill. Но здесь статья скорее обращена к тем, кто:

1) Помимо Web делает Windows-приложения (вы будете удивлены, но таких еще очень много)

2) Не обладают компетенциями в selenium и подобных средствах

Нет смысла смешивать разные виды тестирования в одном инструменте..

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

 но поддержка, решение проблем и коммьюнити?

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

Как обстоят дела у UiPath с основным бичом автоматизации — надежностью тестов?
Каков примерный процент тестов, которые «упали» без весомой причины, или выдали false positive/negative result?
Судя по time.sleep для элементарных операций, надежность не на высоте…

time.sleep - это из примера Selenium, к дальнейшему рассказу про UiPath никакого отношения он не имеет. Там есть свои методы ожидания реакции, не требующие настройки таймеров. Что касается Selenium - даже если вы знаете как обходиться без time.sleep там, вы большой молодец, что не отменяет проблемы с удобством восприятия кода, где идет указание на элементы, с которыми идет работа в стиле div>div>div>div

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

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

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

В прочем, если вы получите в отчете о тестировании результат "Ошибка, нет доступа к ресурсу" - это тоже тот случай, когда нужно обратить внимание на тестируемый ресурс. А если вы понимаете "ну да, пропадал Интернет" - просто перезапускаете тесты (можно сделать выборку по проваленным и запустить только их).

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

С селекторами ещё плюс минус понятно, но как дела обстоят с cookie. Или это чисто визуальные проверки?

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

допустим нужно подложить куки авторизованного пользователя, что бы сразу запустить проверку личного кабинета, можно ли сделать это с UiPath?

Можно, через передачу информации по сессии. Точнее схема такая:

1) Делаем авторизацию через скоуп подключения к браузеру

2) Через параметр SessionData получаем информацию о сессии, эта информация передается в виде строки, ее можно сохранить в хранилище, чтобы использовать в последующих тестах

3) В тесте, где нужно использовать эту сессию - загружаем параметр SessionData

Более подробно про методы получения и загрузки данных о сессии можно прочесть в документации:

https://docs.uipath.com/activities/docs/n-get-browser-data

https://docs.uipath.com/activities/docs/n-set-browser-data

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории