Je suis ingénieur en automatisation de tests et j'ai récemment eu l'opportunité d'explorer le blueprism de l'outil RPA. Après avoir exploré, je l'ai trouvé similaire aux outils d'automatisation de l'interface utilisateur prenant en charge diverses technologies. Quelqu'un peut-il me dire quelle valeur ajoute la RPA par rapport aux outils traditionnels. J'étais intéressé de voir comment il peut utiliser «l'intelligence», mais je n'ai trouvé aucune fonctionnalité.
Un expert de ce forum peut-il m'aider à comprendre ce que RPA peut faire quel outil traditionnel ne peut pas faire?
Je vois des questions similaires mais elles ne donnent aucune réponse que je recherche.
Merci, Nilesh
6 Réponses :
Les défis technologiques de la RPA et des outils d'automatisation sont assez similaires. Les produits RPA et de test diffèrent par leur expérience utilisateur et leurs rapports. Alors que les outils de test offrent souvent des fonctionnalités pour évaluer les risques ou créer des données de test, les outils RPA se concentrent davantage sur la création de robots et le stockage des données utilisateur.
Vous pouvez dire qu'il existe des similitudes par le fait que Tricentis, la société à l'origine de la solution de test Tosca, développe également un produit RPA ( Tricentis RPA ).
Salut Martin. Ce que vous dites n'est pas faux mais, à mon avis, ce n'est pas le point principal. La principale différence entre les deux techniques est l'objectif: l'automatisation des tests concerne le test d'application, c'est-à-dire le contrôle de la qualité, généralement exécuté sur un environnement de test. La RPA est destinée à la mise en œuvre d'un véritable processus métier s'exécutant dans un environnement productif. Je rentre plus en détail dans mon post ci-dessous. PS: Tricentis développe des RPA probablement parce qu'ils réutilisent la partie de la source système qui est responsable du pilotage des applications.
Les plates-formes RPA vous offrent un endroit unique où différents types d'applications peuvent être automatisés.
Ces plates-formes essaieront fondamentalement de consolider et de formaliser l'effort d'automatisation dans une entreprise. et ici le mot «entreprise» est la clé.
pour les petites entreprises où elles souhaitent automatiser certaines tâches, le stagiaire peut être invité à créer rapidement quelque chose. personne ne se soucie de la technologie ou des outils utilisés. peut-être qu'il aime python, et quelqu'un d'autre aime VBA. une seule tâche peut donc être automatisée à l'aide de plusieurs technologies différentes. personne ne s'en soucie tant que cela fonctionne. le stagiaire part et le prochain stagiaire trouve quelque chose de nouveau ...
Les plates-formes RPA, en revanche, représentent un effort «formel» plus important qui tentera d'automatiser des tâches qui, autrement, nécessitent beaucoup d'ETP (employés à temps plein) pour être accomplies. Les cas d'utilisation typiques de la RPA sont des tâches répétitives que les humains font toute la journée sans utiliser beaucoup de cerveau. Pensez à extraire chaque ligne d'un bon de commande (bon de commande) et à le mettre dans une feuille de calcul Excel, puis à le publier sur une application interne. Maintenant, imaginez un seul gars faire cela peut-être pour des centaines de bons de commande par jour.
Vous ne pouvez pas imaginer à quel point le paysage informatique est inégal dans la plupart des entreprises. les anciennes applications qui ont été construites en interne il y a longtemps ou les versions qui ne sont plus mises à jour par le fournisseur. le plus gros problème est lorsque ces applications n'ont pas de points d'intégration, donc ces plates-formes RPA fournissent le bail invasif (modifications des anciennes applications ou même mise à niveau)
Je peux continuer toute la journée sur la RPA, faites-moi savoir si vous avez des questions de suivi. Je travaille pour l'une de ces plates-formes RPA, je pourrai peut-être vous aider.
Pouvez-vous être précis. Je veux dire quelles sont les fonctionnalités de RPA dont l'outil traditionnel n'a pas. Dites lire PO et entrer dans l'écran de l'interface utilisateur, peut également être fait par des outils d'automatisation de test. J'essaye de comprendre le facteur différentiel entre deux. Veuillez être précis car je sais qu'il prend en charge plusieurs technologies, etc., mais d'autres outils d'automatisation le font également (TOSCA)
Salut Nilesh, une chose que les outils RPA ont définitivement mais que les outils d'automatisation n'ont pas nécessairement est la journalisation de toutes les actions par défaut: vous devez être capable de suivre ce qu'un robot a fait à tout moment: il fonctionne dans un environnement productif, avec des données réelles. Par conséquent, les outils de robotique enregistrent par défaut toutes les actions qu'ils exécutent, avec quelles entrées et avec quelles sorties. Ce n'est pas toujours le cas pour les outils d'automatisation: vous pouvez (dans certains cas, vous devez) implémenter vous-même la journalisation.
Sur une note moins officielle et moins sérieuse, RPA est un terme marketing pour un robot d'automatisation de test doté d'une sorte d'éditeur de flux de travail et de technologies à distance
Nous utilisions des robots d'automatisation de test standard (UFT, Selenium, etc.) pour faire de la RPA avec le contrecoup que le flux de travail automatisé était plutôt codé que visualisé et nous avons dû investir des efforts dans l'infrastructure pour prendre en charge la mise à l'échelle. (les lancer en masse et automatiquement)
Qu'est-ce que cela résout? - Comme mentionné ci-dessus, visualisation des worfklows et mise à l'échelle - bien qu'ici cela ait des limites
Quels sont les points faibles?
Entièrement d'accord. Cela a l'air bien sur papier, mais en ce qui concerne le développement réel, vous finissez toujours par avoir besoin de quelqu'un qui peut réellement écrire du code décent, sinon vous obtiendrez un désordre qui ne fonctionnera guère. Et quand cela se produit, vous pouvez vraiment laisser ce programmeur l'écrire en pur C # / python / peu importe, peut-être en utilisant des trucs comme le sélénium. D'un autre côté, si tout ce dont vous avez besoin est un petit script pour jouer avec vos fichiers Excel - vous pouvez le faire avec autoit / autohotkey. Le seul réel avantage des outils RPA est qu'il est plus facile de les vendre à votre direction, malgré le prix ... l'ironie.
Vous n'avez probablement pas eu de chance sur votre plateforme RPA. WF ou BP sont similaires à ce que vous décrivez, mais il existe d'autres plates-formes accessibles aux utilisateurs professionnels. Regardez quelques-unes des vidéos UiPath ou allez à l'Académie et essayez-le vous-même. Aucune compétence de codage requise pour la plupart des tâches
Un robot d'automatisation de test n'est qu'une API pour le bureau, c'est-à-dire qu'il vous donne des moyens simples de travailler avec le désordre que nous appelons Desktop. Ils sont tous livrés avec des méthodologies de création de tests Record and Replay et Drag and Drop (marketing), mais ils deviennent très vite inutiles - ou en d'autres termes - leur pouvoir d'expression est très limité. Cette industrie est encore dans son enfance et peut-être qu'il n'y en a pas vraiment besoin - du tout - ou à l'inverse, les systèmes deviennent si complexes que vous ne pourrez pas tester / automatiser / intégrer (RPA) à des niveaux inférieurs, mais uniquement via l'interface utilisateur. P.S: Pas de mauvaises expériences ici :)
Je pense que la différence est la même chose que d'avoir un ensemble d'outils contre un sac complet avec des outils. Vous pouvez utiliser les deux pour atteindre votre objectif. Pour moi, il est plus facile d'utiliser une plate-forme RPA standard et oui, il contient des activités de sélénium, des activités de cloud, des activités OCR, etc. et oui, le même résultat pourrait être atteint sans plate-forme RPA, mais ce serait beaucoup plus de temps et d'efforts fastidieux.
@BelaTamasJozsa: Pour votre premier et deuxième point, je vous recommande de jeter un œil à UiPath . Sur le troisième point, je voudrais souligner que, d'une part, les intégrations système sont bien sûr meilleures que les robots. Il peut néanmoins y avoir des raisons de ne pas tendre vers l'intégration: le système est trop critique (ne jamais changer un système en cours d'exécution), le paysage système doit rester inchangé, le code source est perdu, le constructeur veut une somme effroyable pour l'intégration ... veulent «optimiser» les processus grâce à l'automatisation. Par conséquent, nous traiterons des robots logiciels pendant un certain temps.
Il existe de nombreuses variantes de RPA. Blueprism n'est pas un exemple idéal de ce à quoi devrait ressembler la RPA moderne, pensez à consulter Automation Anywhere ou UiPath (les deux proposent l'édition communautaire que vous pouvez télécharger et essayer gratuitement). Bien que les différences technologiques ne soient pas si vastes (et que les fournisseurs de RPA envisagent désormais l'automatisation des tests comme un marché pour leurs produits), les plus grandes différences résident dans la manière dont les plates-formes sont conçues, pour n'en nommer que quelques-unes:
La simplicité d'utilisation ne doit pas être supprimée: Avec RPA, c'est un travail d'une demi-heure pour recevoir une demande par courrier, prendre des données de SAP, créer un pivot dans Excel et télécharger sur un site Web au format JSON. Pourriez-vous faire cela dans d'autres outils? Sûr! Est-ce aussi simple? Généralement non. Donc, vous pourriez faire de la RPA pauvre avec Selenium ou AutoIT ou bash ou PowerShell, ce ne sera tout simplement pas aussi facile et fournira moins de capacités tout en exigeant plus d'efforts à chaque étape. Et si vous le faites correctement, vous finirez par répliquer l'une des plates-formes RPA de toute façon.
Également dans RPA, il existe généralement mais pas toujours un mécanisme de coordination central (ala Selenium Grid) pour orchestrer plusieurs robots (jusqu'à 10k dans le cas d'UiPath) pour s'assurer qu'ils agissent de manière synchronisée, ont une sorte de file d'attente de travail, transfèrent leur charge de travail , déployez des processus sur eux, etc. Cela fait toute la différence pour les scénarios d'utilisation en entreprise.
La principale différence entre les deux techniques très similaires d'automatisation de test (processus) et d'automatisation robotique de processus est l'objectif . Presque tous les points contenus dans les articles précédents sont, à mon avis modeste, des conséquences de l'objectif des deux techniques:
J'espère, cette aide à clarifier.
PS: j'inclus le mot «Processus» dans le contexte des tests, car initialiser ou réinitialiser un environnement de test, fournir des données secondaires, démarrer un système en cours de test, exécuter un test, collecter les résultats, comparer les résultats réels avec les résultats attendus, créer les rapports pour la gestion des tests ou DevOps sont généralement un processus que vous automatisez à l'aide d'une sorte d '«automatisation des processus de test» et pas seulement de l'automatisation des tests.
Les outils RPA et UI Automation présentent des caractéristiques techniques qui se recoupent. Par exemple;
Comme vous le voyez, ces outils RPA et UI Automation partagent de nombreuses fonctionnalités. Mais, le concept principal n'est pas ici la technologie mais la méthodologie d'application. De ce point de vue, les outils RPA
En résumé, les outils RPA ont été développés pour implémenter facilement des tâches répétitives à volume élevé dans un environnement professionnel, mais l'automatisation de l'interface utilisateur a été développée pour tester l'interface utilisateur de l'application et vérifier les règles métier adaptées au paradigme de base.
Cette question est un peu large pour le format de questions-réponses de Stack Overflow, mais je vais essayer: le principal avantage de l'utilisation de la RPA par rapport à un autre outil / plate-forme est l'échelle à laquelle vous pouvez effectuer des processus automatisés. La mise à l'échelle d'une instance à 1 000 est triviale lorsque votre infrastructure est correctement définie.
Je vote pour clore la question car il s'agit essentiellement d'une demande de recommandation pour un outil particulier, ce qui est hors sujet pour SO.