Microsoft integrations for a Swiss administration

This article demonstrates how Step can automate Microsoft software for the purposes of testing and general usage.

Introduction

Despite alternative options appearing on the market over the last decade, Microsoft desktop software and, in particular, Win32 applications still play a big role in the IT landscape of most corporations. These applications are difficult to automate in an end-to-end method and in turn, most automation teams do not bother scripting user workflows involving these applications. Testing, measuring the performance of, or including these applications in RPA toolchains is typically a difficult process.

This case study will demonstrate how we have been able to automate software such as Outlook and other Win32 applications on the Windows platform. We will explain how one can leverage COM interfaces and Step’s .NET agent to build large scale Win32 automation projects. We will also demonstrate how to package AutoIt as a Keyword in Step in order to simulate keystrokes; This is particularly useful for automating Win32 applications which do not provide a COM-level API or for handling forms and popups.

Challenges

The Windows runtime is a necessity in IT; Win32 applications are omnipresent and are a part of nearly every IT ecosystem.

In most cases, these applications are directly managed by operations engineers, and basic single-user tests are deemed sufficient for them to ensure that your email works and that other proprietary desktop applications are rolled out properly. Additionally, people rely a lot on Microsoft’s own testing efforts and assume these IT components will always work once installed in their environment.

One could argue that end-to-end testing should be a mandatory Step before a roll-out, regardless of the type of application, but even if you’re taking a hands-off approach to desktop applications, once in a while, you’ll come across a critical application workflow that requires E2E automation and involves a Win32 desktop component. Should you just give up or try to broaden your skills and the scope of your toolkit?

Client Context

As part of this study, we will first examine a real-world scenario that one of our clients - a public Swiss administration - needed to automate. In a subsequent section, we will then examine the integrated stack that supports the implementation and execution of the scripts. We will demonstrate that our generic approach allows us to interact with just about any Windows program, and that several different strategies are at our disposal and can be utilized depending on context.

Note: At the time, our client was already using Step with Selenium Keywords in order to reuse E2E scripts provided by their third-party software vendor based in Austria. They were focused on two activities: massively concurrent regression testing and load testing (both against their new document management system). One day, this client identified a new critical workflow which would have to be tested.

This workflow involved: Microsoft Outlook; a custom add-in built into Outlook; a web application (the document management system) which they were already thoroughly testing using the Selenium Keywords; and a third-party Win32 client used as the interface between Outlook and the web app.

Here is an explanation of what this workflow means in terms of testing:

The user workflow

The primary target of automation was the document management system, a web application. The vendor had provided their own suite of page objects for integration with Step via Selenium Keywords; this was already a key component of their automation platform.

Subsequently, a new add-in for Outlook was released. This add-in would allow a user to import an email or an attachment directly into the central system by invoking a local custom process on the user’s desktop, which would in turn initiate a browser session in which the user was already logged based on their windows credentials. The user would enter the attachment’s metadata in the window of the Win32 process and would return to the web application (Internet Explorer) once the document’s import was successful. The virtual web folder in which the document had been imported would then be displayed to the user in their browser session.

The figure above summarizes the sequence of interactions required to upload the document into the DMS.

This scenario was difficult to automate due to the multiple types of technology involved and the multiple different automation approaches required. On top of that, coordination and synchronization needed to be achieved between the different processes to reenact the user’s workflow accurately. In other words, this is a highly hybridized scenario requiring a lot of flexibility and maturity from the automation platform, both to implement and run and to later scale up the executions.

Solutions

.NET integration

As explained in our series of .NET tutorials, we were able to automate the entirety of the application via the following methods:

leveraging vendor-provided DLL’s and the COM API to invoke functions specific to the application or
when no such API existed, using AutoIt to interact directly with the window via basic events such as key presses

Most of the tools developed on top of the Win32 platform provide DLLs in their installation folder; as our tutorial demonstrates, integrating these DLLs into a .NET project is simple and effective.

Note: AutoIt itself offers a DLL which exposes its functionality. For more information on AutoIT, visit its official webpage here.

We then deployed our project in Step, ran it and scaled up our executions using Step’s .NET agent. The figure above illustrates how Step leverages the .NET Framework to interact with Win32 applications via the COM interface. For more information regarding scalability concerns, review this section of our starter’s guide.

Using the .NET agent, testers can write scripts in C# against Win32 applications and register them in Step as Keywords to build complex scenarios and execute them on Step’s agent grid.

Conclusions

Our client was able to add this critical workflow to their test suite, allowing for a smooth roll-out of the functionality in production. With unique integration capability and new integrations coming out with almost every release, Step keeps on expanding the coverage of tested applicative workflows for its users.