Archive for September, 2008

Our son: ‘); DROP TABLE Students;–


This has been around a while but…


I’ll give $20 bucks to the brave QA Engineer who names their son or daughter one of the following:

  • <script>alert(‘xss’)</script>
  • &lt;script&gt;alert(‘xss’)&lt;/script&gt;
  • %3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%27% 78%73%73%27%29%3C%2F%73%63%72%69%70%74%3E
  • PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4

…poor kid

How to View JavaScript Errors in Google Chrome


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”

Google Gives Us Another Browser to Test: Chrome


image 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, 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:


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.

Automated Web-Site Layout Testing


image Web-site layout, one of the many things that can keep a tester busy. Uhm…overwhelmed? So many browsers so little time… Wouldn’t it be nice if you, the mighty tester, could just review a butt-load of screen-shots of your Web application in multiple browsers on multiple platforms to make sure there are no layout issues?  Wouldn’t that be quick and efficient?

I’ve got 2 semi-solutions for you (keep in mind I’ve done little with both, so forgive an misinformation):

“We’ve felt the pain of getting website designs to work correctly across different browsers. Not to mention designing email newsletters that work on all email clients. Litmus makes compatibility testing easier. Litmus is lightning-fast, reliable and affordable. It’s relied upon by thousands of smart freelancers and switched-on agencies; as well as big companies like Yahoo!, Facebook and eBay.

The FREE part of Litmus: Screen-shots of your site in IE 7 and FireFox 2.

The $ part of Litmus: Pay $24 a month to get 23 browsers and 14 email clients.

Browsershots makes screenshots of your web design in different browsers. It is a free open-source online service created by Johann C. Rocholl. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to the central server here.”

The FREE part of BrowserShots: 70 browsers on various platforms! Submissions get dumped to a queue for processing.

The $ part of BrowserShots: Pay $15 a month to get priority processing.

Both of these appear to be good services that can provide quick insight to layout problems in your site. However, as far as I can tell the two big limitations are:

  • You are limited to pages that you can navigate to via URL, which rips the grandiose dream of having a screen-shot for every page in your website (pages that require form post or special conditions to get to are not going to happen). However, Litmus does provide a step in the right direction with it’s functionality for authentication.
  • Your site must be exposed to the Web, doing little for internal Dev and QA project cycles.

I have a dream…

  • I want to screen-shot any page in my website (requires a decent engine that will allow me to get to the various pages in my site).
  • I want to screen-shot my site that is not yet published for the world (requires the service to exist within my local network).
  • Once I’ve approved an ideal layout screen-shot I want the software to determine and tell me if the other screenshots are worth looking at (by doing a statistical image comparison with a predefined pass/fail threshold).
  • I want to provide basic wire-frame definitions and have software determine if my screen-shots are within reason (by analyzing elements in the DOM and browser dimensions)
  • Get rid of screen-shots and do DOM to DOM element width and height comparisons between browsers (Come on, it’s a dream, standards compliance for all browsers (another dream) might make it possible?)

Honestly, I think the dream is doable… So many dreams/ideas, so little time.

Post navigation