Automation Under Special Conditions (Missing Peripherals)

Basic product orientation

Silk Test Workbench is a GUI testing product that tries to act like a human user in order to achieve meaningful test results under automation conditions. A test performed by Silk Test Workbench should be as valuable as a test performed by a human user while executing much faster. This means that Silk Test Workbench requires a testing environment that is as similar as possible to the testing environment that a human user would require in order to perform the same test.

Physical peripherals

Manually testing the UI of a real application requires physical input and output devices like a keyboard, a mouse, and a display. Silk Test Workbench does not necessarily require physical input devices during test replay. What Silk Test Workbench requires is the ability of the operating system to perform keystrokes and mouse clicks. The Silk Test Workbench replay usually works as expected without any input devices connected. However, some device drivers might block the Silk Test Workbench replay mechanisms if the physical input device is not available.

The same applies to physical output devices. A physical display does not necessarily need to be connected, but a working video device driver must be installed and the operating system must be in a condition to render things to the screen. For example, rendering is not possible in screen saver mode or if a session is locked. If rendering is not possible, low-level replay will not work and high-level replay might also not work as expected, depend on the technology that is used in the application under test (AUT).

Virtual machines

Silk Test Workbench does not directly support virtualization vendors, but can operate with any type of virtualization solution as long as the virtual guest machine behaves like a physical machine. Standard peripherals are usually provided as virtual devices, regardless of which physical devices are used with the machine that runs the virtual machine.

Cloud instances

From an automation point of view, a cloud instance is not different to a virtual machine. However, a cloud instance might run some special video rendering optimization, which might lead to situations where screen rendering is temporarily turned off to save hardware resources. This might happen when the cloud instance detects that no client is actively viewing the display. In such a case, you could open a VNC window as a workaround.

Special cases

Application launched without any window (headless)
Such an application cannot be tested with Silk Test Workbench. Silk Test Workbench needs to hook to a target application process in order to interact with it. Hooking is not possible for processes that do not have a visible window. In such a case you can only run system commands.
Remote desktops, terminal services, and remote applications (all vendors)
If Silk Test Workbench resides and operates within a remote desktop session, it will fully operate as expected.
Note: You require a full user session and the remote viewing window needs to be maximized. If the remote viewing window is not displayed for some reason, for example network issues, Silk Test Workbench will continue to replay but might produce unexpected results, depending on what remote viewing technology is used. For example, a lost remote desktop session will negatively impact video rendering, whereas other remote viewing solutions might show no impact at all once the viewing window was lost.

If Silk Test Workbench is used to interact with the remote desktop, remote view, or remote app window, only low-level techniques can be used, because Silk Test Workbench sees only a screenshot of the remote machine. For some remote viewing solutions even low-level operations may not be possible because of security restrictions. For example, it might not be possible to send keystrokes to a remote application window.

Known automation obstacles

Silk Test Workbench requires an interactively-logged-on full-user session. Disable anything that could lock the session, for example screen savers, hibernation, or sleep mode. If this is not possible because of organizational policies you could workaround such issues by adding keep alive actions, for example moving the mouse, in regular intervals or at the end of each test case.

Note: Depending on the configuration of the actual testing environment and the technologies that are used for the AUT, the virtualization, and the terminal services, you may face additional challenges and limitations during the test automation process.