CAPTCHA is an acronym that stands for “Completely Automated Public Turing test to tell Computers and Humans Apart.” There are a variety of ways to implement CAPTCHA, but the goals of using it are the same: to halt people from trying to get access to unauthorized sites, post comments, upload files, send emails or scrape information from a site. By design, it’s meant to weed out scripts and confirm that actual people are using a site and making requests.

One thing I want to make clear from the start is that this article will not talk about automating a CAPTCHA solver. That gets into implementing AI and hacking methods. Instead, this article is about how to successfully enable CAPTCHA using automation.

Common Automation Tricks

The first step is to see where CAPTCHA can be enabled in the system. Common places include:

• Login/Forgot Password
• Submitting forms
• Posting comments
• Sending email

Each of these areas will have a configuration file that can be edited to allow the CAPTCHA option to be displayed. There are a variety of methods to implement CAPTCHA, but most of them involve displaying an image or series of images that require a person to respond to what the image shows.

If I want to test CAPTCHA as implemented in a product, I am less focused on solving the CAPTCHA than I am on ensuring that it acts as a barrier or extra security. Tests will be negative tests, meaning that I confirm that I can see and interact with the CAPTCHA elements and that I do not get to complete the workflow (logging in, posting a comment, uploading a file, etc.) without completing the CAPTCHA puzzle.

• For example, if I am testing a login page that shows a CAPTCHA, I will ask myself:
• Can I see the elements?
• Can I enter values into the text field and submit the results?
• Will I get an error message if I didn’t solve the puzzle?
• Does my not solving the puzzle result in my not being able to complete the expected workflow?

Things That Are Hard to Automate

Configuration Files vs. Applications Control Panel

Depending on the number of ways the CAPTCHA can be configured, it may be as simple as using a configuration file and changing key values through a regular expression in a script. The more places that CAPTCHA can appear, the more items I might have to change in the configuration file.

If a configuration file is not an option, then I may need to get into an applications control panel and select or deselect values. To help limit these interactions, it may make sense to group areas together and make several tests that look at specific areas, both with CAPTCHA turned on and with CAPTCHA turned off.

Can I Go a Different Route?

The goal of having CAPTCHA enabled is to enhance security or limit interactions to scripts. To that end, we want to make sure that we are not making end runs around the workflow.

For example, a login page could have username, password and CAPTCHA fields and a Submit button, as well as a “Forgot Password” link. If I click on that link and then provide my email address, I will receive a message with a link to reset my password. By clicking on that link, I want to ensure that the CAPTCHA still appears and is operating correctly.

Where Can I Make CAPTCHA Appear?

This is going to vary based on implementation, but if there is a place that a CAPTCHA can appear, I need to make sure that I can turn it on and make it appear in the designated locations. One downside is that, if I can make a CAPTCHA appear everywhere, there is a possibility at each of those points to submit information or post an action. I will need to confirm that the CAPTCHA cannot be compromised from any of those locations.

Common Themes

In this series, there are going to be some familiar patterns and areas that need to be considered for effective testing. Several of these are areas that could be combined into modules, considering I will likely use them frequently.

Cross-Browser Tests

Because different browsers have different ways of displaying elements such as text boxes, drop-down boxes, checkboxes, etc., I will have to compare and contrast these interactions with a variety of browsers.

Download your risk-free, full-featured version of Ranorex Studio now to experience the power of test automation.

Michael Larsen has, for the better part of his 20+ year career, found himself in the role of being the “Army of One” or “The Lone Tester” more times than not. He has worked for with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. Michael currently works with Socialtext in Palo Alto, CA.