The right tools for your platform.

Platform choice changes the interface a tool can use and the evidence it can collect. The useful question is not simply which operating system is installed. Ask whether your task belongs to a browser page, a native application, a file operation, or a system facility.

Separate the host from the target

The host runs the automation process. The target is the browser, application, or device being controlled. They may be the same machine, but they do not have to be. Record both in a test plan so “works on my machine” can be translated into an actual reproducible environment.

Mobile platforms

For mobile app flows, account for the app’s state, device configuration, permissions, and whether the current surface is native or web content. Keep the business intent similar across platforms while allowing the implementation to reflect the actual device.

Desktop platforms

For Mac and Windows workflows, first look for a supported application interface that exposes the operation directly. If the task requires the user interface, plan for focus, application state, and the permissions needed by the chosen mechanism. Use browser tooling when the workflow actually lives in a browser.

Build a meaningful environment matrix

Choose environments because they answer a question. A release check might need a particular operating-system version and application build. A layout check may require a viewport and font environment. A device-specific flow may need hardware behavior that a simulated environment does not represent. Avoid treating a large matrix as a substitute for a clear reason to test.

Start with the mobile app guide or the desktop guide. Then read about tool runners and test flows to make the execution environment part of the workflow contract.