In the slim and clean Google Chrome (beta) interface JavaScript issues are not easily detectable unless your page or site is visually broken. Much like FireFox and Safari, a tester must open the "JavaScript console" and keep it in visible view while they test in order to catch JavaScript errors. Chrome's Javascript console is a lot like Safari's, but is a tad worse (see the gotchas at the bottom of this post).

My fellow testers, here is how to get to that JavaScript console and monitor for JavaScript errors while you test:
 

Click the page icon to the right of the URL bar. Select "Developer" and then "JavaScript console" from the menu:

In the top of the JavaScript console window click the "Resources" button:

Start testing. When an error occurs you'll see a red icon with a number in it next to the page that the error occurs:

You'll also see a log of the error in the bottom of the JavaScript console window, if you click the provided link it will take you to the line of code where the error occurs:

Also, if you click the page in the "Resources" section the offending line of JavaScript and the error will be displayed:

As of now, I see two gotchas in Google Chrome Beta when attempting to detect/find JavaScript errors:

1. The "JavaScript Console" reports more than JavaScript issues which makes sorting/distinguishing JavaScript errors from other reported HTML style of formatting errors tough. A cheesy visual helper is to also open up the "Debug JavaScript" window (found in the same Page > Developer menu to the right of the URL bar) and watch for new line items to show up in the log. Those line entries are associated with JavaScript errors, unless..
2. You changes sites/domain, in this case the previously opened JavaScript windows won't display data for the new site. You have to close those instances and re-open them to monitor the new site.  You know that the monitoring has stopped when you see in the "Debug JavaScript" window the following log entry: "lost connection to tab"

Just when you thought you had a handle on your browser compatibility testing, Google gives us Chrome.  What does that mean for you, the infamous browser compatibility tester? Just another browser to test? Yes and no...

Have you seen my previous screencast on Browser Compatibility Testing Risk Analysis? If not, its a worthy watch if you want to get a feel for how the browser generally works and how to trim that browser test list based on a little bit of data and risk analysis. Once that's under your belt, continue on my friend...

Let's dive into the details of Chrome to get a quick grasp on where some new browser compatibility defects for your site may be lurking:

The Layout Engine
What does Google Chrome use for a layout engine? WebKit. The same layout engine that Safari uses. Will it render exactly like Safari? Well, it depends on which version of WebKit that  your installations of Chrome and Safari use. You can determine this quickly by looking at the user-agent string. A quick way to do this is to go to BrowserHawk.com, click "more" in the top right menu, scroll to the bottom of the new page and look for the text "User agent". Here is the Google Chrome user-agent:

Mozilla/5.0+(Windows;+U;+Windows+NT+6.0;+en-US)+AppleWebKit/525.13+(KHTML,+like+Gecko)+Chrome/0.2.149.27+Safari/525.13

As you can see we have a WebKit version of 525.13. Chances are that the latest version of Safari runs WebKit 525 also (again do this by looking at the user-agent of the latest version of Safari). Ignoring the minor version number and focusing on the major version number, if they are the same we can feel comfortable that Chrome and Safari will display layout the same...Meaning they will align objects on the page the same. If you've already tested Safari, chances are you aren't going to find any unique layout defects in Chrome.

The JavaScript Engine
This is where things start to get different. In Google Chrome we have a brand new engine and way of doing JavaScript. Google calls their new engine V8. Safari's engine is JavaScriptCore. Night and day...expect to see differences and potential issues here. When testing make sure to look for JavaScript errors and possible issues with sites that us AJAX (in my next post I'll talk about how to view JavaScript errors in Chrome) .

The Shell
What stands out the most to me in Chrome's "shell" is the fact that tabs, plug-ins, and JavaScript run under there own process. On the surface this looks like an ideal way to manage security and to keep memory in-check, but I would keep an eye on functionality of pop-ups and session management between windows (as in, losing reference where there needs to be reference). Also, notice the clean-cut/different "shell" that Chrome has... This "shell" could also yield potential defects related to printing, or any other page related features that you may find in the various menu bars/icons or "Options" menu.

In summary, if you are asked to test both Safari and Chrome the layout is going to be the same (if the WebKit versions are the same). However JavaScript and the Shell could yield some unique defects.

The IE team announced what the user agent string for IE 8 will be:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)

This particular one is for Vista. They've decided not to use the 'b' in 'MSIE 8.0b' for the beta version this time due to issues they've encountered in the past with that approach. I've updated my User Agent Switcher import file to contain the string for Internet Explorer 8 on Vista and XP. As always you can get to that file from the right menu under the "My Testing Tools" section: User-Agent Information and Tools. Load up the new file and go see if your browser detection script will work with IE's new string.

I also updated it with FireFox 2.0.12 for Vista.

I did my first presentation for the Phoenix Software Quality Association (PSQA) yesterday evening on "Browser Compatibility Testing Risk Analysis". Those who attended learned:

"The art of trimming browsers from a browser compatibility test list by knowing your users, understanding how the browser works, OS & browser facts versus misconceptions, and grouping browsers by common component versions to remove redundancy."

For those that attended I promised to post my presentation and handouts here on my blog. So here they are:

Packaged Download
Browser Compat Presentation.zip (1.62 MB)

Individual Downloads
Browser Compatibility Testing.pptx (1.65 MB)
Browser Facts Misconceptions and Experience.docx (29.24 KB)
BrowserCompatCheatSheet.xlsx (14.89 KB)
Setting Browser Compatibility Testing Expectations.docx (13.87 KB)

If you don't have Office 2007 you can get the Office 2007 viewers here for free.

I'm thinking about screencasting this while it's fresh in my mind. If I do, it will be posted here within the next few weeks.

PSQA is always looking for presenters or a place to meet. If you can offer up either, the organization would greatly appreciate it (contact info@psqa.org). If you're in the valley, have anything to do with QA, and are not already a PSQA member, go sign up. It's free!

After the IE Team posted their intent and work on compliance to standards the debates have begun. Revelations have shown that the standards compliance is really an an option that would be invoked by a developer with a META tag or header using the value of  'X-UA-Compatible'. Now, IE 8 will have 3 modes:

1. “Quirks mode” remains the same, and compatible with current content.
2. “Standards mode” remains the same as IE7, and compatible with current content.
3. If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple <meta> element. Aaron gives more details on this in his article.

There is much debate on how this will impact the Web, user experience, as well as how developers will program. There are interesting thoughts around all of them. What is most intriguing to me is that IE 8 is going to be standards compatible. With news like this, I can now test that a Web application conforms to a standard. The standard is now my guideline for my set of test cases. But really will it be a "set of test cases"? Quite possibly it could be only one: Load the page and validate that the page is rendered using "Best standards mode". But hopefully the test wouldn't even be of my concern, with the right Content Management System, the code will be compiled by a developer and the check will be done by the CMS before release to QA. Either way, conforming to standard lowers the risk of a browser compatibility dramatically.

Another interesting feature in IE 8 is the idea of "Version Targeting". In other words: 

"The idea is that when IE10 loads up my IE7 page, it rewinds itself to act like IE7 did, all those years ago—no matter what changed in the meantime."

What will "Version Targeting", do to my browser compatibility testing list when IE 8 is released? My first impression is that it won't slim my test list at all. For example, if you have a page that is coded for IE 8 and X-UA-Compatible, it doesn't necessarily mean that it will look good in IE 7 or in IE 6 since the code is targeted for IE 8. Using that same Web page (IE 8 and X-UA-Compatible), will the testing list shrink with the release of IE 9? It depends... Will the standards and the compliance to those standards change between IE 8 & 9? How many compliance to standard defects were in IE 8 and fixed in IE 9. If their were few defects and the standards didn't change then the risk is low and you probably wouldn't need to test both IE 8 and 9, just 9.

It's too early to speculate and come up with concrete answers. The IE Team is still working through this stuff with themselves and the active community. But I'm happy to see their attention on the matter.

I swear I put all my browser archive links into one blog post before, but a search tonight proved me wrong. So here they are... These are the sites I've used for years to download old browsers:

FireFox (official)
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/

Netscape (official)
http://http.netscape.com.edgesuite.net/pub/

Internet Explorer and MANY others (unofficial)
http://browsers.evolt.org/

Last month the IE team mentioned that their latest Internet Explorer code (to be IE 8 sometime in the future) renders the "Acid2 Face" tests correctly. This is a large achievement for the team and developers around the world. Browser compatibility testing is going to get easier for us testers (once developers shake their old habits of coding workarounds for browser quirks)! Read the post here.

I've decided to dedicate a spot on the blog for the user-agent information I've been providing over the last few years. From now on you can reference this post from the right navigation under the tools section.

Here are four very good lists and classifications of user-agents:

1. http://www.user-agents.org/index.shtml
2. http://www.botsvsbrowsers.com/
3. http://www.tnl.net/ua
4. http://www.pgts.com.au/pgtsj/pgtsj0212d.html

Here is my huge user-agent XML import file for use with the User Agent Switcher Firefox add-on: AgentStrings20080223.xml (19.67 KB). Read here how you can use this tool for testing. The current file contains the following user-agents for your browser spoofing pleasure:

Internet Explorer
MSIE 8 (Win Vista)
MSIE 8 (Win XP)
MSIE 7 (Win Vista)
MSIE 7 (Win XP)
MSIE 7 (Win Storage Server)
MSIE 6 (Win XP)
MSIE 5.5 (Win 2000)
MSIE 5.5 (Win ME)
MSIE 5.0 (Win 95)
MSIE 4.01 (Win 95)
MSIE 4.0 (Win NT)

FireFox
FireFox 2.0.12 (Win Vista)
FireFox 2.0 (Win XP)
FireFox 1.5.0.6 (Fedora Core 5/Linux)
FireFox 1.5.0.4 (Debian Linux)
FireFox 1.5.0.3 (Mac OSX)
FireFox 1.5.0.1 (Win Vista)
FireFox 1.5 (Win XP)
FireFox 1.4 (Win XP)
FireFox 1.0.7 (Win XP)
FireFox 1.0.6 (Win XP)
FireFox 1.0.5 (SlackWare/Linux)
FireFox 1.0.4 (FreeBSD)
FireFox 1.0 (Win XP)
FireFox 0.9.3 (Win XP)

Opera
Opera 9.1 (Win XP)
Opera 8.0 (Win 2000)
Opera 7.6 (Server 2003)
Opera 7.51 (Win XP)
Opera 7.5 (Win XP)
Opera 7.5 (Win ME)
Opera 4
Opera 3
Opera 2
Opera 1

Netscape
Netscape 8.1(Win XP)
Netscape 8.0.1 (Win XP)
Netscape 7.2 (Win 2000)
Netscape 7.1 (Win 98)
Netscape 4.8 (Win XP)
Netscape 4.76 (Win 98)
Netscape 4.5 (Win 98)
Netscape 4.05 (Win 95)
Netscape 3.01 gold (Win 95)
Netscape 2.02 (Win 95)

Safari
Safari 3.0 (v521)
Safari 2.0 (v418.9.1)
Safari 2.0 (v412)
Safari 2.0 (v401)
Safari 1.3 (v162)
Safari 1.3 (v158)
Safari 1.3 (v146)
Safari 1.2(v125.8; OSX 10.3.4)
Safari 1.1 (v100.1; OSX 10.3.2)
Safari 1.0 (v85)
Safari 1.0 (v74 beta 2)
Safari 1.0 (v73 beta 2)
Safari 1.0 (v64 beta)
Safari 1.0 (v51 update 1.0 beta)
Safari 1.0(v48 public beta)

AOL
AOL 9.0/MSIE 6.0 (Win XP)
AOL 8.0/MSIE 6.0 (Win XP)
AOL 7.0/MSIE 5.5 (Win 98)
AOL 6.0/MSIE 5.5 (Win 98)
AOL 5.0/MSIE 5.0 (Win 98)
AOL 5.0 (OS X)
AOL 5.0 (Mac PPC)
AOL 4.0/MSIE 3.02 (Win 95)
AOL 4.0/MSIE 4.01 (Win 95)
AOL 4.0 (Mac PPC)
AOL 4.0 (Mac 68k)
AOL 4.0/MSIE 3.0(Win 3.1)
AOL 3.0/MSIE 3.02 (Win 95)
AOL 3.0/MSIE 4.01 (Win 95)

Mozilla
Mozilla 1.7.8 (Linux)

Spiders/Bots
Googlebot 2.1 (New version)
Msnbot 1.0
Msnbot 1.0 Beta (v0.11)
Yahoo Slurp
Ask Jeeves/Teoma

RSS Readers
NewsGator 2.5 (Win XP)
Feed Demon 1.6 (Win XP)
Bloglines 2.1
SharpReader 0.9.6.0 (Win XP)

WAP Devices
Nokia 6630
Nokia 6100
BlackBerry 8703
iPhone (3.0 Mobile)

Toolbars
Google Toolbar 4.0
Hotbar 4.4.2
AskBar 3.0

Other
iTunes 4.2 (OS X 10.2)
iTunes 4.7 (OS X 10.2)
iTunes 7.1.1 (Mac PPC)
Zune 2.0
Facebook

Sweet! Take another browser off the browser compatibility testing list.

Read more here...

Want to download a few keepsakes or take a walk down memory lane? Check out Netscape's Product Archive FTP.

I found two more lists of user-agents for browsers, spiders, bots, RSS readers, devices, etc. If you're looking to track down who/what a specific user-agent is or are looking to spoof a user-agent using the User Agent Switcher extension then these four lists should be helpful (newly discovered are on the top):

1. http://www.user-agents.org/index.shtml
2. http://www.botsvsbrowsers.com/
3. http://www.tnl.net/ua
4. http://www.pgts.com.au/pgtsj/pgtsj0212d.html

I've also updated my User-Agent list xml import file for User Agent Switcher to include a few WAP devices and toolbars.

*WAP*     
Nokia 6630
Nokia 6100
BlackBerry 8703 
*Toolbars*     
Google Toolbar 4.0
Hotbar 4.4.2   
AskBar 3.0      

Download it here: AgentStrings20070517.xml (18.07 KB)

Update 05/17/2007: The list has been updated and can be found here.

Somebody asked for an update to my outdated XML import file for User Agent Switcher. Honoring that request, I have added the latest user agent strings for each browser. Updated or added strings are marked with green below. I also added a new section for RSS reader user agent strings. Download the User Agent List import file here: AgentStrings20070304.xml (16.51 KB).

Internet Explorer
MSIE 7 (Win Vista)
MSIE 7 (Win XP)
MSIE 7 (Win Storage Server)
MSIE 6 (Win XP)
MSIE 5.5 (Win 2000)
MSIE 5.5 (Win ME)
MSIE 5.0 (Win 95)
MSIE 4.01 (Win 95)
MSIE 4.0 (Win NT)

FireFox
FireFox 2.0 (Win XP)
FireFox 1.5.0.6 (Fedora Core 5/Linux)
FireFox 1.5.0.4 (Debian Linux)
FireFox 1.5.0.3 (Mac OSX)
FireFox 1.5.0.1 (Win Vista)
FireFox 1.5 (Win XP)
FireFox 1.4 (Win XP)
FireFox 1.0.7 (Win XP)
FireFox 1.0.6 (Win XP)
FireFox 1.0.5 (SlackWare/Linux)
FireFox 1.0.4 (FreeBSD)
FireFox 1.0 (Win XP)
FireFox 0.9.3 (Win XP)

Opera
Opera 9.1 (Win XP)
Opera 8.0 (Win 2000)
Opera 7.6 (Server 2003)
Opera 7.51 (Win XP)
Opera 7.5 (Win XP)
Opera 7.5 (Win ME)
Opera 4
Opera 3
Opera 2
Opera 1

Netscape
Netscape 8.1 (Win XP)
Netscape 8.0.1 (Win XP)
Netscape 7.2 (Win 2000)
Netscape 7.1 (Win 98)
Netscape 4.8 (Win XP)
Netscape 4.76 (Win 98)
Netscape 4.5 (Win 98)
Netscape 4.05 (Win 95)
Netscape 3.01 gold (Win 95)
Netscape 2.02 (Win 95)

Safari
Safari 3.0 (v521)
Safari 2.0 (v418.9.1)
Safari 2.0 (v412)
Safari 2.0 (v401)
Safari 1.3 (v162)
Safari 1.3 (v158)
Safari 1.3 (v146)
Safari 1.2 (v125.8; OSX 10.3.4)
Safari 1.1 (v100.1; OSX 10.3.2)
Safari 1.0 (v85)
Safari 1.0 (v74 beta 2)
Safari 1.0 (v73 beta 2)
Safari 1.0 (v64 beta)
Safari 1.0 (v51 update 1.0 beta)
Safari 1.0 (v48 public beta)

AOL
AOL 9.0/MSIE 6.0 (Win XP)
AOL 8.0/MSIE 6.0 (Win XP)
AOL 7.0/MSIE 5.5 (Win 98)
AOL 6.0/MSIE 5.5 (Win 98)
AOL 5.0/MSIE 5.0 (Win 98)
AOL 5.0 (OS X)
AOL 5.0 (Mac PPC)
AOL 4.0/MSIE 3.02 (Win 95)
AOL 4.0/MSIE 4.01 (Win 95)
AOL 4.0 (Mac PPC)
AOL 4.0 (Mac 68k)
AOL 4.0/MSIE 3.0 (Win 3.1)
AOL 3.0/MSIE 3.02 (Win 95)
AOL 3.0/MSIE 4.01 (Win 95)

Mozilla
Mozilla 1.7.8 (Linux)

Spiders/Bots
Googlebot 2.1 (New version)
Msnbot 1.0
Msnbot 1.0 Beta (v0.11)
Yahoo Slurp
Ask Jeeves/Teoma

RSS Readers
NewsGator 2.5 (Win XP)
Feed Demon 1.6 (Win XP)
Bloglines 2.1
SharpReader 0.9.6.0 (Win XP)

User Agent Strings. Tons of 'em. Browser, bots, RSS readers. The list is ever growing and never ending. Did you know that "a new user agent string is born every 65 seconds"? *

Here are two extensive lists of user agent strings:

1. http://www.tnl.net/ua
2. http://www.pgts.com.au/pgtsj/pgtsj0212d.html

Very useful if you are spoofing user agents with a tool like the User Agent Switcher extension.

* 96.7% of Internet statistics are made up.

Blink, process it again, Microsoft FireFox 2007 Professional Edition, blink real slow this time, look again, Microsoft FireFox 2007 Professional Edition. HUH?

Check it out yourself, somebody put a great deal of work into this. Don't scan through, read the words. Too funny.

Another post yet again inspired by a Google search that lead to my site but I don't necessarily address directly: "What is the quickest way to refresh a Web Page?"

Answer: The F5 key

How to refresh a Web page without pulling it from the browser's cache? CTRL + F5

No such thing as a stupid question here at QAInsight.net\QABlog.net\QABlog.com! We all have to start somewhere eh?

The IE team has released Beta 3 of the IE Developer toolbar. I played with it for a while and found that it's getting better. In prior versions I (and others I talked to) couldn't get the Outlining functionality to work. It appears to work now in Beta 3, but it's still a bit buggy. On a page off of Google news the toolbar was incapable of outlining all the images on the page. On a positive note, the new feature "Select Element by Click" is pretty dang slick and I could see it being really helpful in developer troubleshooting or testing investigation. The feature allows you to click any element in the Web page and that element's details and position in the DOM will be displayed in Developer Toolbar's DOM explorer. From there you can also view the source for that element too (with colored syntax).

If you haven't already, start warming up with the beta 3. Once complete, this tool will be a must have in your developer and testing tool toolbox.

Get update information and screenshots of changes at the IE Blog. Download IE Developer Toolbar Beta 3 here.

Internet Explorer 7 is out and as the world gradually upgrades, our web applications are slowly forced into compliance if we want to truly reach all of our audience. When it's been declared that your app will support both (at least for the time being) the testers are forced to conduct browser compatibility using both. Because of this, testers are now dealing with the problem: Knowing that IE6 and IE7 can't be installed at the same time on one machine, what is the most efficient way to test both IE6 and IE7? It sure would be nice if I you could test both from a single test machine right? Fact of the matter is, you CAN! You've got two options here, a Not so Guaranteed way, and a Guaranteed way.

Not So Guaranteed Way
Use MultipleIEs from TredoSoft,which allows you have multiple versions of IE (3.0, 4.01, 5.01, 5.5, 6.0) placed and semi-runnable on one test system. I've done a bit of playing around with this method and from experience it's pretty unstable. IE is built to tie into your OS, so being a unstable seems reasonable when you have hacked apart piles of assemblies that make up different versions of IE (as MultipleIEs has done). If you're fairly familiar with what different versions of IE look and feel like you'll get the same uncomfortable hunch that I get when I'm trying to convince myself that I'm truly experiencing the version of browser I opened. Goofy things make me suspicious, like running IE 5.5 and viewing the "About" window which tells me that I'm running IE 6. Attempted validation of components in these browsers using detection tools such as BrowserHawk.com still leave me scratching my head due to issues with tools themselves or the browser. Who knows? I don't know! It would take a lot of work to know. I would find great comfort in proof that the rending engine, JavaScript version, management of cookies and cache of that browser were truly being used. But I don't have time to do that. Will you test on a questionable browser/system and put your "tested" seal on the Web app when you don't have proof of the authenticity of that browser? Not me. Those are my feelings, the IE team backs them up with this post. However, I can confidently put my seal on the Guaranteed Way:

Guaranteed Way
1. Install IE7 on your test machine.
2. Download and install the free Microsoft Virtual PC 2004 and the free Windows XP SP2 IE6 VPC Image (no license required). Set you new environment up in 19 easy steps.

Do it the right way testers. Microsoft has made it easy and free for you.

FireFox 2 is released and can be downloaded at GetFireFox.com! What does this mean for us browser compatibility testers?

From experience, my compatibility testing woes that come with version changes are:

1. JavaScript version changes, causing JavaScript errors.
2. Rendering engine changes (especially CSS); causing display issues (e.g. object alignment, font changes/inconsistency).

So....as I peruse the FireFox 2 feature list I see an upgrade to JavaScript 1.7. Hmm, sounds historically defect prone...BUT, before I read the feature list I went and did my own homework of seeing if the JavaScript version changed. My homework unveiled that FireFox 2 was using JavaScript 1.5? WHAT THE? Am I looking at an issue caused by having multiple FireFox installations on a machine (I have 1.0.8, 1.5.4, and 2.0 installed). When you're running FireFox 2 what is your JavaScriptVer when you visit BrowserHawk.com? Leave your findings in the comments please!

Which is faster when using DHMTL? The innerHTML property or the HTML DOM? Gleb Lebedev over at gloo.ru did all the hard work for us and gives us an answer. In a nutshell: innerHTML wins in Opera 9.01, FireFox 1.5, IE 6.0 32-bit, and IE 6.0 64-bit. By far!

A new check in the performance code review? Your developers do that right? Right!?

Today Microsoft released Internet Explorer 7. When I got home from work today I installed it on my wife's laptop. Any minute I should see what the WAF is.

I noticed my 12 year old son was using it while doing some homework and I asked him what he thought, the conversation went something like this:

Me: What do you think about Internet Explorer 7?
Jake: The thingy with the gold ring?
Me: Yeah, the Web browser you are using right now (peering over the top of the laptop and noticing a Web page with pictures of Lysosomes)
Jake: Looks the same to me, I didn't notice.
Me: You don't see ANYTHING different?
Jake: I guess up here is kinda weird (as he points to the Yahoo toolbar at the top of the Web browser...which doesn't look any different than it did in IE6).
Me: Hmm...

I think his experience is a good thing? If you think about it, a twelve year old doesn't care about security, phishing, integrated search, and all the other new, key features of IE7. The fact that he opened IE7 up (with the new desktop icon), did a search on Google for Lysosomes, and printed a picture out for his storyboard/report tells me that Microsoft did a great job with revamping their browser but not confusing their customers.

Kudos to Microsoft.

Download IE7 here.

Don't download it here (IE7.com ...haha)

In the past I've written about my use and the value of the testing and development tool HTTPWatch. In the latest release of HTTPWatch (4.1) Simtec has added to its value by exposing an interface to be used for automation. My thoughts on the matter: "Whoa..that's freakin' cool, now I can automate some of the things I have to test manually for?"

The HTTPWatch automation interface as described by the folks at Simtec:

"HttpWatch has a comprehensive automation interface that can be used by most programming languages (e.g. C#, Javascript & Ruby). The interface can be used to control the HttpWatch plug-in for IE and access data in HttpWatch log files. If you are already running automated tests, you can integrate HttpWatch and record HTTP level information during your tests. The recorded data that then be checked for certain types of configuration and performance problems (e.g. HTTP compression is not enabled)."

I've played around with the new interface for a little more than a week now and the more I play the more I realize how valuable analyzing the HTTP traffic on the fly during an automated test could be. While exploring the interface, I put together a Visual Studio .NET 2003 project with some examples of the things that can be done:

• Check every request for 404. This isn't just page requests, this is all HTTP traffic that goes along with the page (e.g. catch broken images, missing .js files, etc.)
• Check every request for 500. Same as above except for 500s.
• For performance improvements, check to see if .jpg, .gif, .css, .js are found in cache instead of being downloaded with each page request.
• For performance improvements, check to see if .jpg or .gif files are greater than a designated byte size.
• Check that objects don't exceed a specified download time.

My demonstration project that uses the HTTPWatch interface, IE, C#, and NUnit can be downloaded here (thanks Matt for helping me refactor it). Compile it, point NUnit at HTTPWatch_NUnit_Demo.exe and run the 5 tests. The NUnit Test Suite will conduct the 5 tests noted above against Ebay.com which will work with HTTPWatch Basic Edition (their demo) and the Professional Edition.

The project is pretty simplistic due to it only validating one page, but hey it's a demo. Now that I better understand the interface, the BIG VISION for its use would to be to be open a browser, turn on HTTPWatch, log all the traffic for each page in my Website, and then conduct a battery of tests against the log, dumping the details to NUnit.

I've included the following IE 7 user-agent strings to my importable XML file for User Agent Switcher:

• MSIE 7 beta (Win XP SP2)
• MSIE 7 (Win XP SP2)
• MSIE 7 (Win 2003 Server)
• MSIE 7 (Win Vista)
• MSIE 7 (Windows-RSS 1.0)

Download it here.