Now that I have your attention... 

When I hear XP I typically think Windows XP, and then there is also Extreme Programming. But I never knew that XP means "Christ Savior". According to Grammar Girl's quick and dirty tips:

Retailers have long been accused of secularizing Christmas by using "Xmas" in signs and advertisements; therefore, I suspect many of you will be surprised to learn that "Xmas" has a religious origin.

In Greek, the letter "chi" is written as an X, and chi is the first letter of the Greek word for "Christ." Greeks sometimes abbreviated "Christ" as "X." For example, they abbreviated "Christ savior" as "XP." ("P" is the symbol for the Greek letter "rho," which is the first letter of the word "savior" in Greek.) The Oxford English Dictionary shows the first known English use of "Xmas" in 1551.
As for appropriateness, "Xmas" may have a religious origin and fit better on signs, but many people -- both those who use "Xmas" and those who complain about its use -- are unaware of the religious origin. If you choose you use "Xmas," you should know that some people will be infuriated.

Wow, now that's really got me thinking... Generation X = The generation of Christ? Whoa! Deep. Now I'm sorry I talked so much smack about 'em. :)

Improve your grammar and learn little bits of info like this from Grammar Girl yourself, sign up for the Tip of the day here.

December is here and so is the snow!

Yes, snow in the desert valley!  Well not yet... but on Christmas Eve there will be. Guaranteed!

On December 24th, Superstition Springs Community Church (SSCC) would like to celebrate Christmas Eve with you and that celebration will include snow, SLEDDING, hot cocoa, wagon train rides, LIVE MUSIC,  Bethlehem Village, and a petting zoo. I'm thinking this Christmas Eve service is going to be a BLAST. So, mark your calendar and get more details about it here. See you there!

That's still 23 days away though.. the reason I'm bringing this up so early is because it's also December which makes it officially time to enjoy some new Christmas music right?  I also wanted to point you to the FREE downloadable Christmas album recorded by the SSCC Worship Band. Good stuff, these guys and gals are really good. I can honestly say that I look forward to hearing them every Sunday.

Whether you are near to Gilbert or far, SSCC offers a lot. The prior two things I mention are the tip of the iceberg. SSCC's community and WORLD involvement is admirable, I'm 5 weeks new to SSCC, and let me tell you I'm excited about the impact this church is making in the world. Check out what SSCC is doing on their "All In" blog.

(Gilbert covered in snow...Cows? Yeah...our infamous, stinky dairy)

I know this post isn't QA oriented, I'd like to remind you that you can refine you RSS feed to QA posts only by subscribing to the "Quality Assurance" category. Anything that has to do with SQA will always have that category assigned to it.

The last few months we've heard sooo much about the declining economy... On the flip side, I'm really liking the plummeting gas prices! Aren't you? I paid $1.88 a gallon today! It's been years since I've seen prices like this.

When gas was over $3.00 the complaints were loud and often. Between the people that surround me (don't get me wrong, me too) and the media, it was obvious that we were not happy. Now that gas prices are down, the complaints stop but we don't seem to be talking too much about how happy we are about it. Even worse on NPR, yesterday, they were talking about the negative impact of it.

That's sad.

Join me in the positive celebration of cheap gas!

This Thanksgiving I'm thankful for cheap gas (and a WHOLE LOT more, but I won't get into that here).

 

I noticed today that C# 4.0 will offer dynamic typing (no, your keyboard will not type magically for you...the other typing). Why mention it here? Well, if I understand the new feature right, this will fix a fairly large unit testing and automation roadblock caused by static types. For example, when writing tests in .NET and trying to consume/use a method on a .NET API or Web Service your tests are constrained to the method's inputs static types at compile time. In other words, in the old C# world, if you had a method that looked like this:

public void testMe(int foo){ }

and you wrote a test that called the method like this:

testMe( "poofoo" );

the test would fail at compile time due to static typing (because the method's input parameter type is an int, but we're trying to pass a string)

Thus the roadblock I was describing... There are a lot of tests, poor error handling, AND hidden defects when you try to pass invalid types into inputs in a service. So, about now you are saying..."Who gives a crap Brent, if my service's consumers use .NET they'll compile, get the error and never even get a chance to send a string in where an int should be". There was a day when I thought the same thing (a long time ago), until I consumed a Web Service using a Java application. For example, say you've exposed a .NET Web Service for the world to use... and I come along and consume it with Java, by doing that I can ignore your static/strong typing and send in that string that you weren't prepared for. Strings don't work so well as ints (especially when it's "poofoo", or even better "2147483648"). Most of the time the errors are just plain ugly, making the API or Web Service really hard to work with when trying to do good error handling management (imagine getting "you failed, line 67", but then a code change occurs and now it's line 68), but sometimes things fail on a larger scale and make some really cool defects.

Back to the point...

I'm thinking the new dynamic type in C# 4.0 will allow you to avoid that compile error if you're writing your tests using C#/.NET. Thus, I could send in that string as an int and then see what happens at runtime. That test would look something like this:

dynamic poo = "poofoo" ;
testMe(poo);

Neither confirmed or denied at this point, but if true, I'M REALLY EXCITED. This will fix a major issue that I've had with testing .NET services using .NET.

It's interesting the conversations that are spawned from the issues that come out sending invalid types...

Brent: The error message... "You failed, line 67" is poor and confusing, what did I do wrong?

Developer: It choked when you sent in the wrong type. Don't do that.

Brent: That sucks...so when our customers do the same thing and then call in for help we'll just tell them that?

Developer: Well, uh..no. Okay, I'll put in a little error handling and a descriptive error message.

Brent: Sweet!

Brent: (Evil laugh in head) Hey... Will we support that error message as part of the API? Because, if you make it a message that I, a consumer can rely on, that means my code will depend on it, meaning that changes to the error are breaking changes. Breaking changes must be tracked and documented.

Developer: (Slowly backing away) I CANT HEAR YOU!!!

Interesting... Google Maps has  open sourced their Selenium Test Suite and less than humbly asks you to add to it!

Not only do we test Google's Beta applications...NOW, we can help them automate their applications!

BRILLIANT. Damn these guys are good.

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

There is another software testing magazine available for professional testers!...

test experience, boasting 80,000 users (approximately 2 million readers less than QAInsight.net)

Subscribe here: http://www.testingexperience.com/subscribe.php

Read back issues in PDF format here: http://www.testingexperience.com/thanks.php

 

Don't quit your day job...

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.

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):

Litmus
"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
"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.