4 ms·
Think about it as a programming language but with integrated support for automating user interfaces. Typical workflow for an "unattended" automation (which run
by isp 6y ago
Think about it as a programming language but with integrated support for automating user interfaces.
Typical workflow for an "unattended" automation (which runs on a headless VM in a data centre somewhere) would be:
- Run "Developer Studio" on a dev machine
- Write "code" (in a visual programming language) to tell the software how to interact with other user interfaces (there are various different methods for this: via browser plugin to interact with the DOM in a web browser, or using screenreader APIs for native Windows applications, or even via OCR-like methods if all else fails)
- Save the automation "source code" (it's a visual programming language, based on VB.NET/C#, and the underlying source code is XAML files), ideally add to version control
- "Publish" the new automation to a central "Orchestrator" server - which is responsible for pushing the new automation code to other headless VMs, and coordinating execution
- ethbr0 6y agoTo add one addition piece: selectors / match rules. The key to getting automation reliable is being able to reliably identify target objects (e.g. button, grid cell, etc). ... reliably identify it, regardless of what screwed up, unsupported, what-were-these-devs-thinking underlying code. I once had to automate a webpage that was dynamically built, at user runtime, from a mainframe screen. Of course without any classes or id tags anywhere. So if the tool doesn't give you a toolbox big enough to handle pathological cases, it's not really fit for purpose.