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.

For those of you in need of doing SQL load testing from Visual Studio 2005 or 2008 there is a new open source project at CodePlex called SQL Load Test. How does SQL Load Test work?

"This tool takes a SQL Profiler trace file and generates a unit test that replays the same sequence of database calls found in the trace file. The unit test is designed to be used in a Visual Studio Load Test. The code generated is easily modifiable so that data variation can be introduced for the purpose of doing performance testing."

Get more info and download SQL Load Test here.

Things have been a bit quite here at QAInsight for the last few months wouldn't you agree? As always the days and nights are never quite long enough to get all those things I want done.

I have one excuse though.

Actually I have more than one but I'm only going to share one with you:

I've been working undercover with the FBI and Viacom to help parse Google/YouTube logs to obtain logons which relate to IPs, which point to people who are uploading copyrighted content. A mass effort to prepare for the largest bust in digital history.

No... Just kidding.

Really, I'm kidding don't start with that death threat stuff. I've already had three this week.

Apparently the insightful QA advice found on said Software QA blog has increased defect finding and input by QA Engineers across the globe  and developers are angry. Go figure, they want to eliminate me because apparently I'm the ring-leader that has slowed down their development process and release to production.

It's just a blog. I set forth ideas, I didn't do the defect finding. Please spare my life. Please? I have kids.

In fear of my life I'm going to lie low a while.

In the meantime, take some more QA advice from me and go check out Go Daddy's new QA blog BugCrushers.com. They have a QA army of 50 talented individuals. I expect to see some good stuff come from these peeps.

Oh... By the way, if you're a developer and you see posts on BugCrushers.com where the author is "Brent Strange"...

IT'S NOT ME. It's another Brent Strange. Ironically this one does QA too. Go figure.

The alpha version of IETester was recently released and "IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE8 beta 1, IE7 IE 6 and IE5.5 on Vista and XP" on the same machine.

To good to be true? No, not if you take that sentence literally. These kinds of tools can indeed help you test for "rendering/layout" and "JavaScript" issues, but tend to quickly fall apart when it comes to integration with the OS shell (plug-ins, caching, cookies, modal dialogues, printing etc). IETester is much like MultipleIEs, these types of tools can help when you're in a bind and want to validate something simple that is script or layout related. But to use these tools to conduct all your browser testing versus your dedicated IE systems or VMs will likely bite you in the long run when the issues go beyond layout or JavaScript. IMHO these tools are best left in the hands of the developers to quickly validate layout issues and then QA can follow up with the real thing. It's a good tool to have around but don't bank on it! :)

Download IETester here.

Get a better feel for for how the browser works with my recent screencast: Browser Compatibility Testing Risk Analysis

I just listened to a podcast where Željko Filipin talks with Bret Pettichord about Watir. This is an easy to listen to and informative podcast about Watir. I really admire and appreciate Bret's openness about Watir as he talks about both the good and the bad. If you have 23 minutes give it a listen.

Pex

What is Pex?

"Pex (Program EXploration) is a white-box test generation tool. Given a hand-written parameterized unit test, Pex analyzes the code to determine relevant test inputs fully automatically. The result is a traditional unit test suite with high code coverage. In addition, Pex suggests to the programmer how to fix bugs."

I haven't had a chance to dive in but I'm pretty excited to see how this can speed up production of writing white box tests and/or increase the code coverage on QA's side.

At the end of the day it'd be nice to see this in the developers' hands and not mine. Baby steps though...

Read more about Pex here.

Get an ear full of Pex with a great Hanselminutes Podcast entitled "Pex with Jonathan 'Peli' de Halleux and Nikolai Tillmann".

I hate it.

Unit test this. Unit test that.

Let's put "unit" in our testing framework so we can test "units" cuz that's all ANYBODY is EVER going to test.

Testing outside of the "unit" is forsaken. Thou shalt never test more than a unit. Test more than a unit and ye shall be pelted with stones and crucified.

Let's see... What do we have here for unit test frameworks:

brentUnit (even Brent Strange can have a unit testing framework)
JUnit (notice the word unit)
nUnit (look at me, I test units)
mbUnit (I'm a follower, I can't think outside of the box. Uhm...let's test units.)
csUnit (CHEESE & RICE, this is INSANE)
...

OH HELL...Just go here for the gi-hugey list:

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

You back? See what I mean? There's like one-cajillion testing frameworks that are for "Unit Testing".

Unit, unit, unit. It's freakin' beyond dumb.

Tell me...What happens once this developer phase of "Oh, I gotta go write some unit tests, with my unit test framework so my code is better" evolves to tests beyond "unit"? You know, like writing some tests that are "integration" or "functional? It'll happen people.

IT'S HAPPENING PEOPLE.

I, and others have been using "unit testing" frameworks as an automation test harness for years now. All kinds of tests.. Tests that aren't "unit".

Yeah, insane. Unheard of I know. What? You going to crucify me now?

Drop the unit. Get over it. These are "Testing frameworks".

P.S.
Microsoft, nice namespace: Microsoft.VisualStudio.TestTools.UnitTesting

P.P.S
Don't give me any crap about how "unit testing frameworks" are for developers. Good one rocket scientist...Let's create separate frameworks to basically do the same thing. One for Dev, one for QA. Brilliant...

I remember the 1st time I tried to kick-off a "unit test" from Visual Studio 2005. I had to defer to the Web, I couldn't figure it out. A year later and through everyday use of VS 2005 and VS 2008 I've slowly discovered various ways to get those tests rolling. Here are 6 different ways to start a test in Visual Studio 2008:

"Test Tools" Toolbar

Context Menu

Keyboard Shortcuts
Ctrl+R, Ctrl+T: Execute tests in current context
Ctrl+R, Ctrl+C: Execute tests in current test class
Ctrl+R, Ctrl+N: Execute tests in current namespace
Ctrl+R, Ctrl+A: Execute all tests in solution
Ctrl+R, Ctrl+D: Execute the tests in the last test run
Ctrl+R, Ctrl+F: Execute the failed tests of the last test run

Test List Editor

Test Results Pane

"Test" Menu

The votes are in and it's official. Brent Strange has been crowned "The Best Software Tester In the World". Over the course of  the 27 day voting period the software testing world was quite a buzz. Articles, blog posts, forums, and clubs have been consumed with facts, opinions and skeletons for the 7 candidates over the last 4 weeks. QA hubs such as StickyMinds, TestReflections, SQAForums, and SoftwareTestingClub were overtaken with this "best in the world" shakedown as QA professionals and interested developers voiced their opinions. Oddly enough, the recent and parallel presidential campaign even took notice.

An interview in the to be published June edition edition of Better Software Magazine  between Vimh and Brent bring to light why the community's decision on this heralding QA Engineer was not just Internet viral:

Vimh: So Brent, how does it feel being declared the "Best Software Tester In the World"?

Brent: I'm speechless Vimh. I don't deserve this. I test. I do my job. There is no Best Tester In the World. We all bring Quality Assurance to the table in our own unique ways. Honestly, this award should go to the entire Software Quality Assurance community.

Vimh: The people have spoken Brent. You are the "Best Software Tester In the World". How do you think the community came to that decision?

Brent: I'm not sure. I'm guessing that those that I've worked with past and present voted for me, others I assume were followers of my small footprint in the QA community with my blog QAInsight.net. If not acquaintances or followers I suppose it was just viral. 

Vimh: Is it true that you once found and reported 70 defects in one day?

Brent: [Laughing] No... it was 59 defects, but technically 14 of those were enhancement requests.

Vimh: That's a sign of somebody thinking outside of the box I suppose.

Brent: Inside and outside. You've got to be both places at once in this business.

Vimh: Where do you see yourself in 5 years?

Brent: Testing. Writing software to making testing easier and faster.

Vimh: How about 10 years?

Brent: White sand beach with Corona in hand.

Vimh: [Laughing] Sounds like a great goal!

Brent: It's not a goal Vimh. It's destiny. The Internet is gold mine my friend.

Vimh: Agreed. If all goes well I'll see you on that beach with my trophy wife.

Brent: See you there Vimh. I'll see you there...

Vimh: So now that you are empowered with the title "Best Software Tester In the World" do you picture yourself strutting into a developer's cube and saying "listen to be me beeeaaaatch, it's not "function as designed", it's a freakin' defect and you're gonna fix it".

Brent: Uhmm...No.

Vimh: How about: "Hey dumb-ass, you ever heard of unit test?"

Brent: Dude, not funny. We're all on the same team. [Pretty pissed off sounding] Listen, turn this interview around or I'm going to have hang-up.

Vimh: Okay, I apologize....Brent, you've had a few "skeletons in the closet" exposed during the last month.

Brent: Yes, 2 of them to be exact. I have the "never went to college" and "has no testing credentials" monkeys on my back.

Vimh: Do you think that hurt or helped your campaign? 

Brent: [Laughing] Call me a "Rocket Scientist", my "un-educated" guess says "help".

Vimh: Why do you think that is?

Brent: The reality of it is that a QA Engineer's greatest skill is the openness and ability to lean quickly and then apply it towards quality initiatives. You don't need a degree or certificate to do that. Matter of fact, I don't even know of an entity that teaches that skill. I think the SQA community recognizes that. James Bach has brought that to light for us.

Vimh: Interesting. So you're saying that anybody can be a good tester?

Brent: Not "anybody" but "anybody that is open to learn anything, has the ability to lean quickly, and then apply it toward a given task". Software is "anything", it changes daily. SQA Engineers have to stay on their toes and be able to use anything to help prove something.

Vimh: I never thought about it like that. Wow, "anything" is a lot to learn! That's respectful. It's known that you don't care to manage QA. Why?

Brent: I'm a tester AND teacher at heart. Historically a QA manager relentlessly fights the quality assurance battle all day and often times compromises due to budget, schedule and company ignorance. His/her persistence typically pays off in the long run (several years sometimes) though. But...Have you ever taught a fellow QA Engineer something they didn't know and then see that twinkle in their eye when they envision using that lesson in their testing tasks? It's awesome! To me, that's finding more defects by teaching other people to find defects. We BOTH just made software better...together. [Loudly] AT THE END OF THE DAY!

Vimh: Sounds like a pyramid scheme!

Brent: You said it! I'm a walking "QA Amway" and "QA Mary Kay"!

Vimh: [Laughing] Is it true you once said you knew the LDAP protocol to gain a Development team's confidence and respect for testing, but you really didn't know anything about it?

Brent: ONCE? [Chuckling] QA is often looked down upon because they are the 2nd tier information receivers and are expected to magically know everything right off the bat, which is near impossible. A developer can sit, stew, learn, and write code for a new technology for days, weeks, or months and then simply hand it off to QA expecting them to know the same AND know how to test it. To ensure quality and gain respect of that developer I need to  be "open to learn anything, have the ability to lean quickly, and then apply it toward the given task". The Internet is my best friend. So, yes. Quite often "I am clueless, I make sure I project confidence, I go learn the subject after the fact, and then complete the task". There is no harm in that is there?

Vimh: No, I guess not. Especially when you hammer a project with 70 defects in a day.

Brent: [Laughing] Yes, especially when you hammer a project with 59 defects...

Over the last month I've been looking at Zephyr, a test management system that touts itself as "Next Generation". What exactly is Zephyr and what does it have to offer to the testing community?

"Taking a completely realistic approach to how Test Teams work, collaborate and interact with each other in their department and the rest of their world, Zephyr brings together a comprehensive set of features, a really slick UI and Web 2.0 features at a price point that makes it very affordable for all team sizes.

Zephyr is based around the concept of Desktops & Dashboards. Every role in a Test Department has a customized Testing Desktop with relevant applications that allow them to do their jobs faster and better, as they all share data from a centralized repository and communicate via a collaborative backbone. Dashboards are automated and live, keeping the whole company updated on every aspect of testing and product quality."

At a high level Zephyr offers:

• Testing Desktop
• Dashboards
• Metrics & Reporting
• Test Case Repository
• Resource Management
• Project Management
• Release Management
• Test Case Creation
• Test Execution Planning
• Test Execution
• Document Management
• Defect Tracking
• Collaboration
• Import and Export
• User Interface
• Integration

The 20,00 foot view of Zephyr is this (see the related "How Zephyr works" video here):

Now, I've been managing test cases in a Excel spreadsheet for years, a fairly advanced one at that. It utilizes Visual Basic for Applications (VBA) and gets the job done very well for me, several other QA Engineers, and a few managers. So, having to consider a test management system that costs $$ it a hard to swallow...If it's not broke, don't fix it right? With that eating at me, when looking at Zephyr I decided to compare it to what I have and currently use. Let me tell you what my KISS test management system consists of:

• Quick and easy test case writing
• Consistent test plan and case format
• Reusable test case library that contains commonly used test cases
• Brief but technical test case writing format
• Test case state statistics by section and total
• Testing summary for all testing sections/worksheets
• Test case trends via charts
• Automated coloring of test case status for quick visual reference
• Automated test case to build mapping
• Test case to defect mapping
• Simultaneously sharing between multiple testers
• Tester assignment by section/worksheet

Granted, it's not perfect, but again it works very well and people really like it. With my testing world as the level set, let's jump into the good, the bad, and the things to think about if your considering Zephyr:

Tester Assignment
You can specify users to run specific test cases or whole sections. Very nice!

Copying
I can drag and drop individual cases from one folder to another, but I can't figure out for the life of me how to drag sub-folders of test cases into another folder (they move not copy). I also was unable to successfully import a previous export. If indeed this is possible it's not easy or intuitive (drag and drop or export/import). This sucks, compared to me simply selecting one or several rows in Excel by hitting CTRL+C and then CTRL+V. Simple copying of test cases is extremely important to me.

Test States

1. Zephyr uses the states of Pass, Failure, Unexecuted, WiP, and Blocked. These are good test states, but it lacks the two states that are geared a bit for the Test Lead: Duplicate (DUP), and Not-Applicable (NA). These are important states to me, primarily because a test case written by a test lead should never be deleted but sometimes they can be redundant across sections of test cases (needing DUP) or not-applicable because the requirements have changed, or the requirement needs to be assessed no matter what (needing NA). I don't see a good way to manage these scenarios in Zephyr with the states provided.
2. I'm a big fan of usability, and colors help with that a lot. I don't like the fact that Zephyr doesn't color their test case state (e.g. pass=green, fail=red).

Test Case Library and Templating
The nearest thing I could find to be "Test Case Library like"  is their import/export from file feature. I found that using it was truly cumbersome since I'm used to copying and pasting sets of test cases from one place to another within seconds. If you have or want the ability to hold a library of test cases, or better yet a library of templated test cases then you're going to have to get really crafty with their app infrastructure (e.g. create a project and consider that your library).

Desktop client
In Zephyr, there is a lot of data in a lot of different screens and for the most part that is a very good thing. This was confusing at first, but the more I used and learned the app the more it made sense. The client is the browser with a Flash app running inside it. Working in a Flash app didn't make usability or intuitiveness any easier though. The learning curve for me was a bit steep due to fumbling around with right click context menus in some places and not others to find features (if it didn't exist I'd get the "Flash Settings" context). This is a huge pet peeve of mine and reminded me of working in a poorly written Java GUI.

Metrics
A++. Love them. They're informational and visually appealing!

Requirements
Zephyr requirements traceability is lacking. You can attach a requirement document to a test case but can't point to a specific requirement within that document. I suppose a guy could hijack an existing text input field to create a requirement number or reference in the attached doc (unless you're okay with embedding it within the test case description). This is discouraging if you're looking to tie a test case to a a specific requirement number.

Resource Management
You can assign and schedule test resources to your projects. This is really nice! Currently people/resources can be input into and then managed through Zephyr. I didn't find an evidence of integration Active Directory or LDAP though. This could be a pain if you have many people on the QA team.

Defect Tracking
Zephyr integrates with Bugzilla. Good choice Zephyr! However, if you've customized your Bugzilla interface this feature won't work for you (yet) since the default Bugzilla interface is duplicated inside of Zephyr.

Sharing
Zephyr allows sharing, It even manages test roles: Manager, lead, tester. Roles would be nice in large QA departments. Again this might be a bit more convenient to manage with Active Directory or LDAP integration.

Price
I'm a little discouraged by the price, mostly because they touted it as inexpensive during beta. After release the license model and cost is: "a simple yet flexible licensing model based on monthly subscriptions. Each user license is a low $65/user/month". Let me help you with a few prices for a ONE year subscription: 10 users = $7,800, 100 users = $78,000. That's not quite "almost giving it away!" as they state on their front page.

In a nutshell, I think Zephyr has done a great job with sharing the tester and test lead world with each other and management. However from a test lead perspective I'm a bit disappointed: The way test cases are written, managed, and copied needs to be improved vastly.  Writing test cases in Zephyr is not any easier or better than Mercury Quality Center (which frankly sucks in my opinion). That's a serious problem when 1/4 of a test lead's life is spent writing test cases. Zephyr is new though, give it some time and I think it will shine. In all fairness, Zephyr does a WHOLE lot more than what my spreadsheet is capable of, but I don't think I need that whole lot more, especially when I lose my test case writing convenience.

Everybody's needs, situation, and environment are different though, so go "kick the tires" yourself at:  http://demo.yourzephyr.com

ArtOfTest, creators of the browser automation framework WebAii, released a record/playback tool that works from within Visual Studio 2008! The beta release of "Design Canvas 1.0" fills a huge gap in the ArtofTest automation solution. Not only has ArtOfTest provided this great functionality, but this functionality looks really, REALLY cool. See for yourself with their 30 second QuickStart videos. I haven't had time to dig into it myself yet but I'm really excited to do so. From an automation engineer that spends much of his day writing tests in Visual Studio, watching these videos made my mouth water. I'm thinking that ArtOfTest is going to take a lion's share in the automation space in the next few years. They've chosen a great platform (.NET), a great IDE (VS 2008), and are working toward providing test and automation solutions for new technologies such as SilverLight.

Hehe...Funny...'null' is null

James Bach. Man, that guy...

He's my QA hero.

Seriously.

It's not a man-crush though, so don't get all freaked out.

That guy...is able to eloquently match words to the things we struggle with in and as QA. He writes and speaks things that I've struggled to put to words for years.

Recently the TestCrew interviewed James and he spoke of things that I tried to describe recently:

TestCrew: We understand that you're working on a new book about self-education and you will be sharing some ideas on this topic during the June CAST conference. What is the most important