How ASTA Works

ASTA explores and tests your web applications using configurable rules to verify functionality, accessibility, and performance. It eliminates the need for manual scripting for many test cases and enables testers to shift their efforts to more value-added activities.

ASTA consists of three high-level components. The agent directs all testing on behalf of the tester. The companion provides a user interface to control the agent and to view/manage information in the repository. And the repository stores all ASTA data including test assets and artifacts. ASTA also contains an embedded web browser, which it uses to interact with the application under test.

Companion <--> Agent <--> Browser <--> Application
			|
------- Repository ----------------------------------------------
Work Queue	| Model		| Log
Rules		| Flows		| Data		| Form Specs	| Config Data

During a test run, the agent identifies application components needed for navigation or testing and places them on the work queue and into the application model for future use. The work queue contains a list of the application components that have been selected for testing or navigation and not yet processed during a test run. The application model contains a linked list of application components representing the application structure. The application model may be generated and updated by the agent prior to testing or concurrent with testing according to user preferences. Users may also place items on the work queue for directed testing, but this is not required.

The agent selects items from the work queue for testing based on desirable testing outcomes (such as defect discovery) and constraints (such as the amount of time available to perform testing). The agent uses a variety of criteria and information at its disposal in making a selection, such as the current application state, the application structure as expressed in the model, the navigation distance to a component, the goals of the test run (e.g., the relative priority of testing new functionality versus existing functionality), and the estimated value of testing a component based on probability of finding defects. The agent then performs one of the allowable actions on a component (such as “click” or “submit”), retrieves applicable rules from a list of verification rules, and applies them to the application response. The verification rules describe the expected behavior of the application. Rules are written using generalized representations of application components and actions, which can be applied to different application pages, different releases, and even entirely different applications. The agent records the actions performed, the rules applied, and rule results in the run log, along with other diagnostic information.

The agent uses internal algorithms to dynamically generate test data, construct flows (sequences of actions), and infer specifications for forms and their associated fields. The agent may also use pre-defined test data, flows, and form specifications to perform testing if so desired. Agent behavior can be tailored using parameters stored in the configuration data.