So if you follow testing at all you will have noticed that Google recently announced their 2nd annual Test Automation Conferece. Currently they are accpeting proposals for presentations. So after thinking it over for a while I decided to go ahead and submit a proposal to try and take AFTER in front of a larger audience and get more people excited about it. Here is the proposal that I submitted:

My proposal for the conference is about something that I feel is severely lacking in the automated testing arena, user interface functional testing. I feel that this is largely attributed to the fact that there are so many hurdles to this form of testing. Because of these hurdles we see so many duplicated efforts. Consider some of the hurdles listed below: 

1. Cost
   This really has two drawbacks to it. First it usually reserves the tool to only large corporations that can afford the licenses. Secondly, though, it hinders community support since there are only a handful of users. Probably the widely known tool for this arena has been Winrunner but at thousands of dollars for a license it has been reserved for only large corporations.

2. Ease of Use and Maintainability:
   Often times with most tools for testing the tests are written in some form of a scripting language which means that any time some one wants to update or create a new script they have to develop knowledge of the scripting language.

3. Reusable:
   The problem here is that with existing frameworks for automated testing you have to write one script for each environment.  This really can tie back to our second issue as well. Having a different test scripts for each environment makes it nearly impossible to maintain well. Let alone keep up to date.

The Solution - AFTER (Automated Functional Testing Engine in Ruby)

AFTER was created to address the problems stated above. The goal was an engine that would run test scripts and return results that could be consumed by continuous integration systems. This has been accomplished by a couple ways. First AFTER makes use of such great libraries such as, WATiR, AutoIt and FireWATiR, to drive the interaction with the application. Secondly, consider below how AFTER has been able to address problems stated above:

1. Cost:
   Making the AFTER Open Source not only allowed for it to be used by everyone, but it also allows for better community support with the underlying engine code itself.

2. Ease of Use and Maintainability:
   XML scripts made the scripts easy to write and maintain. Not only if we are using a UI but also if we had to open a script and make a change manually. Secondly, we decided that this should be configurable so AFTER does allow for scripts to be written in any form desired so long as there is an associated script reader to understand the script.

3. Reusable:
   The goal was one script, all environments. This is done by providing a pluggable architecture. So when AFTER is started up to run a test script it is told which environment it should target (IE, FF, Windows, Java, etc…) and where it can find the libraries needed to handle the interaction, thus reusing one test script for every environment.

In short I think that AFTER solves a major deficiency in the automated functional testing arena and am very excited to share this solution with others.