QS-Richtlinien

Alle Partneraktivitäten, die auf Go! veröffentlicht werden sollen UiPath-Marktplatz muss Sicherheits- und Funktionstests bestehen. Um den QS-Testprozess für Ihre benutzerdefinierten Aktivitäten zu unterstützen und zu beschleunigen, werden die folgenden Richtlinien empfohlen.

Voraussetzungen

• Die Benutzerdokumentation und Hilfe (falls zutreffend) müssen vollständig sein und zum Zeitpunkt der Veröffentlichung bereitgestellt werden.
• Die Dokumentation sollte kontextabhängig sein und erklären, wie häufige Aufgaben gelöst werden.
• Sowohl das NuGet-Paket als auch die Quellcodelösung müssen bei der Veröffentlichung bereitgestellt werden, um die rechtliche und Sicherheitsüberprüfung abzuschließen.
• Wenn Software von Drittanbietern verwendet wird (Integration), sollte eine Sandbox-Umgebung bereitgestellt werden.
• Prüfnachweise müssen vom Technologiepartner bereitgestellt werden.

Pakete

• Paketbeschreibungen müssen vorhanden sein und den Zweck des Pakets erklären.
• Externe Bibliotheken sollten nicht gebaut, sondern referenziert werden.
• Alle Abhängigkeiten müssen richtig im NuGet-Paket aufgeführt werden.
• Lizenzen müssen in der Paketbeschreibung vorhanden sein.
• Kompatibilität: Pakete können auf allen unterstützten Versionen unseres Systems installiert und ordnungsgemäß ausgeführt werden.
• Aktivitäten müssen sowohl über Studio als auch Orchestrator ausgeführt werden können.

Aktivitätsseite

• Aktivitäten, die nicht von UiPath erstellt werden, dürfen den UiPath-Namensraum nicht nutzen.
• Der Namensraum muss die Richtlinien respektieren.
• Alle Aktivitäten müssen eine Beschreibung ihrer Funktion anzeigen, wenn man mit der Maus darüber fährt**.
• Die Namen der Aktivitäten müssen richtig angezeigt werden**.

Designerseite

• Wenn Aktivitäten in einem Scope verwendet werden sollen, dies aber nicht passiert, müssen sie eine Bestätigungsmeldung auslösen**.
• Pflichtfelder müssen eine Bestätigungsmeldung auslösen, wenn sie nicht oder falsch verwendet werden**.
• Alle Bestätigungsmeldungen müssen informativ und benutzerfreundlich sein.
• Anzeigenamen dürfen niemals abgeschnitten sein**.
• Symbole für Aktivitäten müssen die gleichen wie auf der Aktivitätsseite sein.
• Sofern zutreffend dürfen die Namen der Eigenschaften nicht abgeschnitten sein**-
• Wenn Assistenten verwendet werden, darf die Funktion niemals in der Lage sein, ein ungültiges Ergebnis auszugeben.
• Wenn die Aktivität die „Verkleinern“-Schaltfläche anzeigt, sollte sie diese Funktion erfüllen können.
• Wenn die Aktivität hervorgehoben wird, muss die F1-Taste Sie zur entsprechenden Hilfe-Seite bringen.

Eigenschaften

• Wie auf der Designerseite, sofern zutreffend.
• Alle Eigenschaften (außer ältere WWF) müssen Beim Mouse-Over Beschreibungen anzeigen**.
• Eigenschaften müssen in den entsprechenden Kategorien organisiert werden.

Allgemein

• Konsistent bleiben! Konsistenz ist wichtig für die Qualität!
• Wenn benutzerdefinierte Klassen verwendet werden, achten Sie darauf, die öffentlichen Methoden und Eigenschaften zu dokumentieren.
• Setzen Sie niemals voraus, dass der Endnutzer das gleiche Wissen über Ihr Zielsystem hat. Erstellen Sie die Aktivitäten also benutzerfreundlich und intuitiv!
• Stellen Sie sicher, dass es keine Inkonsistenzen zwischen dem Aktivitätspaket, das Sie veröffentlichen möchten, und der dafür bereitgestellten Dokumentation gibt.

** Die Bedingungen sollten in allen Sprachen erfüllt sein, wenn die Lokalisierung implementiert ist.