Introduction

This project is an idea that emerge from the first Automated Functional Testing Workshop initiated by the Agile Alliance and held in Portland, Oregon - in October 2007. The main motivation behind this project is to provide a framework to the community that will accelerate innovation in this field of our industry. It is an initiative that take place in the larger goal of Advancing Agile Through Eclipse Coopetition

Mission

• The mission of the project is to provide a framework for Automated Functional Test, especially when those are used as a driver for a software development process. Used for this purpose, sometimes these artifacts are called Executable Specification.

• Because we envision great potential in this technique, the ultimate intend is that this framework will foster innovation in the area of Automated Functional Test and will accelerate both acceptance and recognition of this practice, for the sake of customers and other development team members in a software projects.

• To be an advancement accelerator is really the main goal of this initiative, to the extend that even if the framework happens not to be a technical breakthrough but on the other side turn to be a significant catalyst of the field of Automated Functional Test, we will consider this project to be a success that we have to be proud of.

Rationale

According to experience of proposers, it has been demonstrated that building such an automated functional test tooling or platform required a substantial development effort even to provide the minimal 'wiring' to allow the related components to work fluently together. According to this, it makes a lot of sense for different vendors and project initiators to collaborate to create a single framework and share this cost that is a requirement to craft new solution but that, in itself, bring little value to potential user and little return to respective project initiator.

By using this framework, the promise is that vendors and project initiators will be able to spend early on things that bring real value to development teams.

Related Components

As agreed at the first Agile Automated Functional Test workshop, an effective automated functional testing ecosystem should contain the following very high level components. These kinds of components can be view as applications served by the expected framework:

Editor: Test, specifications or examples editors

Repository: Repository where test and related data are stored

Runners: Processing engine that can parse and understand a specific test created with a supported Editor and executes corresponding actions onto the SUD

SUD: System under development onto which the test are conduct

Involve API and Standard

• Test & components API
  • It has been identified by many people in the field that defining and API for Test can be a very harmful initiative for the advancement of functional testing. Main reason is that once this hypothetical API define what a single test contains, following it restrict innovation to this way of structuring test. On the other side, to build inter operable component that exchange test, a minimum is required. As a result the expected framework will follow a very generic API for Test, even if generic also has its drawbacks.

• Test Dialects
  • Test dialect is simply a way to define a specific layout or way to express a test.

Expected dynamic

Users propose dialect, team decide if yes or not the implement it into their component

Interested Parties

• Frank Mauser
• Bob Cotton
• Antony Marcano
• Andre Brissette
• Stephen Michaud
• Gerard Meszaros
• John Dunham
• Stein
• Christian Schwarz
• Agile Alliance

Code Contributions

Tentative Plan