Training Test Automation Scripts for Dynamic Combat: Self Defense

[article]
Part III
Summary:
Dion Johnson use the martial arts metaphor four common issues with automated tests and how test automation specialiasts can "train" their scripts to identify, capture, and handle these problems. In this week's column, Dion talks about how to make develop test automation scripts that defend themselves from problems and failures.

My pupils, you have all done well thus far as we've trained in the automation martial arts known as "Taekwondo-mation." You have grown stronger and more centered, but you are still not yet ready to be called "master."

As you are now aware, Taekwondo-mation places a focus on four key principles:

  1. Flexibility--Dynamic inputting data
  2. Balance--Inputting dynamic data
  3. Self-defense--Exception handling
  4. Strikes--Dynamic-path handling

Through the first two installments of this series, you have become versed in the first two principles. Put your combat robes back on, young Grasshopper (a Kung Fu reference my mother told me about), you are now ready to embark on the third principle--self-defense.

Make no bones about it, software applications and systems that are being automated don't go down without a fight, particularly those involving Graphical User Interfaces (GUIs). The minute an automated script gets near them, they start fighting. And without a good defense, automated scripts will lose the fight. Implementation of automated tests with effective exception handling involves:

  • An understanding of the typical types of attacks that applications wage on automated tests
  • Helping automated tests recognize when an attack is occurring
  • Training automated tests to counter application attacks

Effective handling of error conditions that occur during automated test execution relies heavily on an automator's ability to predict the types of errors that the automated tests may encounter. This becomes exceedingly easier once it becomes clear that most errors fall into the following categories:

  • Abrupt Application Termination
  • Popup Dialogs
  • Object/Data Failures
  • Test Verification Failures

Abrupt Application Termination --Also known as a "crash," this type of error is a condition where the AUT unexpectedly suspends functionality and stops responding to both external and internal system stimulus.

Popup Dialogs --Popup dialogs are windows that are smaller than standard windows and come without a lot of the features that may be common to other windows in the AUT. The unexpected appearance of popup dialogs is troublesome for automated tests mainly because the dialogs tend to suspend all application activity until the appropriate dialog button has been clicked.

Object/Data Failures --Failure to find a desired object or object data is probably the most common of all failures experienced by automated test runs.

Test Verification Failures --Test verification points are typically a good way to address issues before they become problematic for the entire test run. These failures may be anticipated, and the automated test may therefore be set up to handle errors at this point.

Once potential errors have been identified, the next step in the exception-handling development process is to define a means of capturing the error. Error capture involves identifying an error occurrence, determining the type of error, and passing it off to the exception-handling routine. This is often done via the concept of an exception. When encountering error conditions, automated scripts may trigger what is called an exception in the form of an error code. Exceptions provide automated tests with the ability to pass control of the script to a handler routine that will effectively handle the error conditions that caused the exception to occur. Some exceptions are generated automatically by the automated test tool when an error occurs, but automators may also write code that triggers an exception in specific circumstances. The automator then creates and/or customizes an exception-handling routine that handles the error in such a way that automated tests may continue or end in a smooth manner.

Exception handling may be localized or may be established in a separate utility that runs once an error is triggered. Localized exception handling may be implemented as detailed in figure 1.

1

Input "John" into Username textbox

2

About the author

Dion Johnson's picture Dion Johnson

As a senior test consultant and managing partner for DiJohn IC, Inc. and advisor to the Automated Testing Institute, Dion Johnson provides IT consulting services that focus on the overall system development lifecycle, with particular focus on the quality assurance, quality control, requirements analysis, and automated testing. He has presented at numerous SQE conferences and contributed to StickyMinds.com and Better Software magazine. In addition he is an editor for the Automated Software Testing magazine. Email Dion at dionjohnson@dijohn-ic.com or dionjohnson@automatedtestinginstitute.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Apr 29
Apr 29
May 04
Jun 01