ATS is used as an automated test managment system. It can automate tests written for any of the Symbian test execution harnesses (STIF, TEF and EUNIT) as well as other harnesses commonly used by Symbian developers. Note: At the time of writing, Symbian test operations are embryonic. The only fully automated tests are the smoketests run on the daily platform builds to test the most basic level of device usability, and those are run on emulators only. ATS deployment is limited by the immature state of testing operations and will evolve together with the testing operations.

Installation instructions for ATS are included in the product's documentation. An ATS network is a distributed system comprising a number of machines. One machine is the ATS server and the rest are ATS workers. Server installation and worker installation are supported by the same ATS package: either can be chosen at installation time.

The ATS server receives and despatches requests for tests to be run on devices. An ATS worker controls one or more testable devices that are attached to or resident on the worker machine.

A device is a set of hardware and/or software resources, such as an emulator, a reference board or a phone, capable of executing tests belonging to one or more of the test harnesses that ATS supports. A device must be registered with the ATS server. Device registration involves uploading to the server a device registration file which specifies the properties of the device and associates that device with one of the ATS workers. Whenever that worker is available, the server will assume that any devices associated with it are also available.

Each time a worker is started, it notifies the server of its availability and details of the devices it controls.

The ATS worker responds to requests from the server by running tests on the devices that it controls and communicating results back to the server. The server can select a worker to execute a test request based upon the test harness specified by the test request and the choice of available workers that have devices supporting the specified harness. A test request can also specify the particular device that the server must use. Test requests are queued by the server until they can be despatched.

The ATS server provides a web interface though which adminstration and user operations can be performed, and through which the status and progress of operations, and the record of past operations, can be viewed.

Test requests can be entered manually via the server's web interface, or they can be sent remotely to the server by posting an action URL to its http address. Automated test operations are supported in this way.

A test request directs the server to read and execute a testdrop whose location is given in the test request. This location must be a network location that is readable by the server. A testdrop is a zip archive that contains

• An XML recipe for preparing and performing the required test
• A (possibly empty) set of files for deployment to the device in preparation for the test. The deployment of these files, if any, is specified by the XML.

When the server has despatched a test request and it has been executed by a worker, a test execution log and a report of the results are retrieved by the server. The log and report can be viewed via the server's web interface, linked to a graphical entry that records the test run. The detailed output of the test harness is also stored by the server on its local filesystem in a directory created for the test run.