I use to run GUI-level automated test suites with thousands of tests in them. I've run web service tests with tens of thousands of tests. Early on, I was using tools like IBM Rational Robot. In traditional vendor tools (like Robot) test suites like this were painful because you could only run one test at a time per machine. That means if you wanted to run your suite faster, you'd either have to add more machines, or make your existing machines faster.

Bah on that...

One of the reasons I was so quick to switch to Watir when it came out was that it allowed me to run multiple tests at the same time. Because I could run multithreaded (and because the tool leverages the DOM instead of the Windows API), I could run in a fraction of the time (a fifth or a tenth). And all that with no additional resources.

Depending on what you're testing, this may or may not be an option. But if you're doing automation at all, my tip for the day is to look at multithreaded execution.

I was talking a look at Google product search and wanted to think of the simplest test I could that might reveal a lot of information. After the page loads, if you simply hit the refresh button in your browser repeatedly, you'll be able to notice the following behaviors:

• query response times change each time


• some sponsors change each time, while others don't


• column width (between product description and price) changes based on sponsor size

This gives me several ideas for testing and learning about the product. First, I feel like I could quickly program a script to track sponsor results and performance over time time. If I varied the search criteria for similar products, this could quickly be used to start to verify the accuracy of  adds and the rules for displaying them. This could also become a good no-load baseline for the performance of whatever environment you're testing in.

Understanding the relationship between sponsor text (number of characters) and column widths would be worth looking into. Might be an issue, might not (likely not and issue). But it's also something that can be verified quickly and repeatedly with the script that's pulled together.

Here's a useful blog post http://blog.browsermob.com/2008/12/using-firebug-for-load-testing/, with a video (in English) with some useful tips on how to use Firebug and the Selenium IDE with the Mozilla Firefox web browser.

There are a number of tools out there for various browsers that provide similar features, but when I'm working in FireFox I use Firebug. Firebug integrates with Firefox and provides a number of tools for editing, debugging, and monitoring CSS, HTML, and JavaScript. Tools like this are particularly helpful when doing website scripting, basic web testing, or security testing.

This tip is stolen from Adam Goucher. Adam has a script which can be tailored to your developer’s style to find possible issues. By default it just looks for FIXME and TODO but he once worked with a programmer who was fond of ‘Danger Wil Robinson!’ which quickly got added to the script.