ATS: the open-source language for functional test automation
ATS, short for ActionTestScript, is an open-source language designed to describe, structure, and execute functional automated tests in a way that remains readable for humans, maintainable over time, and usable across technologies.
It is the execution language behind Agilitest, but it is also a technology in its own right: open, robust, and built to make functional test automation easier to understand, easier to maintain, and easier to integrate into modern software delivery processes.
In a context where Agile practices, continuous delivery, and DevOps pipelines have become standard, ATS provides a stable and structured foundation for industrializing test automation without locking teams into opaque or fragile test assets.
A functional language designed for test automation
ATS was designed with a simple objective: allow test designers to focus on what the application should do, rather than on the technical complexity of how automation engines interact with underlying interfaces.
Instead of requiring users to build low-level automation code by hand, ATS expresses test scenarios as a sequence of explicit and understandable actions. This makes test assets easier to read, review, debug, and evolve, even when applications change over time.
ATS is particularly well suited to organizations that want to make test automation more accessible across teams, including testers, business experts, QA analysts, and technical contributors. It creates a shared language that helps bridge the gap between functional expectations and technical execution.
Open source by design
ATS is distributed as open-source software under the Apache 2.0 license.
This is a key part of its philosophy. Automated tests should not become inaccessible or unusable because of a proprietary authoring tool. By relying on an open language, teams retain control over their test assets and can continue to use, version, review, and execute them over time.
This openness also makes ATS a durable choice for organizations seeking transparency, interoperability, and long-term ownership of their automated testing strategy.
Human-readable, structured, and AI-friendly
ATS was designed to be both:
- human-readable, so that test scenarios can be understood and reviewed easily;
- structured and rigorous, so that they can be executed reliably;
- editable by AI systems, thanks to a syntax that expresses functional intent clearly instead of mixing business meaning with technical noise.
This makes ATS especially relevant in modern workflows where humans and AI collaborate. AI can help generate or update tests, but the resulting scripts remain understandable, reviewable, and controlled by humans.
Multi-technology test automation
ATS can be used to automate functional tests across multiple technology layers and environments, including:
- Web applications running in major browsers;
- Desktop applications;
- Mobile applications on Android and iOS;
- Web services and APIs.
- SAP technologies (SAPGui in particular)
This multi-technology approach allows teams to adopt a common functional language across heterogeneous application landscapes, instead of multiplying frameworks and scripting styles depending on the target platform.
How ATS works
ATS scripts describe the actions to perform and the validations to execute during a test scenario. These scripts are then transformed and executed through the appropriate runtime components depending on the target technology.
For web automation, ATS relies on established execution technologies such as browser automation frameworks. For desktop, mobile, and web services, dedicated software layers provide the corresponding execution capabilities.
The objective is not to expose this technical complexity to the test designer, but to encapsulate it behind a functional and durable language.
In practice, this means test authors can concentrate on the sequence of business actions and expected results, while ATS handles the technical orchestration required for execution.
Reliable execution and industrial use
ATS was designed not only for test authoring, but also for repeatable execution in industrial environments.
It is compatible with TestNG execution formats and can be integrated into modern continuous integration and continuous delivery pipelines. This makes it suitable both for local test design and for large-scale automated execution in build servers, validation environments, and release workflows.
ATS therefore supports a wide range of uses, from exploratory automation and regression coverage to fully integrated enterprise test campaigns.
Reporting and execution evidence
ATS can produce several types of reports to support test analysis, validation, traceability, and communication across teams.
These outputs can include:
- Execution reports, for an overall view of campaign results;
- Detailed execution reports, with or without screenshots, to analyze failures and understand what happened step by step;
- Summary reports in PDF format, for consolidated reporting;
- ATSV reports, which compile execution images into a video-like playback format using the ATSV player;
- Validation reports, intended for documentation and archival of executed test sessions.
These reporting capabilities help transform automated execution into actionable feedback for both technical and non-technical stakeholders.
ATS and Agilitest
ATS and Agilitest are closely related, but they are not the same thing.
ATS is the open-source functional test language and execution foundation.
Agilitest is the graphical environment built to design, organize, and work with ATS scripts more easily.
Agilitest acts as an editor and orchestration layer around ATS, leveraging years of experience in functional test automation. It allows users to produce ATS scripts while benefiting from features such as structured design, step-by-step replay, robustness, and improved usability.
In other words, Agilitest is built on top of ATS, and ATS provides the technical and philosophical foundation that makes Agilitest durable and transparent.
Why ATS matters
ATS addresses several recurring problems in test automation:
Traditional automation assets often become difficult to maintain because they are too technical, too tightly coupled to a given framework, or too far removed from the functional intent of the test.
ATS takes a different approach. It aims to keep automated tests:
- understandable by humans;
- robust in execution;
- maintainable over time;
- portable across contexts;
- compatible with industrial DevOps practices;
- open to collaboration between human experts and AI systems.
This makes ATS more than just a scripting format. It is a way to treat automated tests as long-term, reusable, and reviewable assets.
Prerequisites and execution environment
To use ATS and Agilitest effectively, some technical prerequisites are required depending on the target platforms and execution contexts.
These prerequisites may include software dependencies, runtime components, browser or mobile automation drivers, and system requirements. For full details, you should refer to the relevant installation and hardware/software requirement documentation.
Important note
Agilitest is an editor for ATS code, but ATS remains a language that can also be viewed, handled, and maintained outside the editor environment.
This separation is intentional: it reinforces openness, transparency, and long-term ownership of test assets.
Governance and project information
ATS is maintained by Pierre Huber, founder of CAIPTURE, the company behind Agilitest.
For more information about the ATS project, its philosophy, and related technical resources, you can visit:
