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.

A couple years ago my grandpa Alfred Olsen passed away and I wrote the following eulogy entitled "Follow the Leader" that was read at his funeral. He was a truly remarkable man, I miss him a lot, and the man he was, is what I strive to be. I was perusing the hard drive this evening looking for something QA related and rediscovered this. I thought I'd share since some of these lessons are applicable in the business world too:

 
Follow the Leader

Written by Brent Strange in memory of Grandpa Olsen

It’s funny, I always have fleeting thoughts of how I appreciate the little things about a person or the different things I love about them but I’m always hard pressed to put it into words or too chicken to tell that person about those things. “I Love You” says a lot, but doesn’t say much for why. Putting the “Why” behind “I Love You” is something I’ve thought about for a long time with my Grandpa Olsen but I never did sit down to tell him. Now it’s too late to tell him in person, so here I am settling down and am writing it out. I hope and pray that he is listening now…

My Grandpa is the most respectable person I’ve ever met. Let’s cut to the chase: Grandpa was honorable, funny, kind, loving, giving, non-judgmental, and a man of God. He is everything I want to and struggle to be. Over the years Grandpa has been a silent leader for me. Follow the leader!

Follow the leader: give somebody some “bugs”!
My first memories of Grandpa date back to when I was less than two years old. Back then Grandpa preached at the Assembly of God in Naselle where he and Grandma lived in the connecting house. I remember in the evenings we would sit in his vinyl, burnt-orange chair together. Grandpa would bounce me on his knee helping me pretend I was a cowboy riding his horse. The orange chair was where I first remember getting “bugs”. Yeah bugs…Grandpa’s way of tickling was giving you little tickling pinches under your legs and arms saying “You got bugs, BUGS, BUGS!” each bug bite made you squirm and laugh trying to wriggle out of his reach to get rid of those darn bugs. When the horse rides and bug bites died down I would sit on his lap, leaning against him listening to him talk to others in the room. His voice was comforting to me.

Follow the leader: sit on the edge!
Grandpa and I did a lot of fishing. My first remembered fishing trip was frightening! Grandpa took me to the dock at the Chinook cannery where we sat on the edge to fish for Perch. I remember sitting on that edge, feet hanging over, and looking down at the water below scared to death since it was so far down (seemed to be about 20 feet down to this day, probably was 10…). Grandpa didn’t seem too concerned and my fear soon went away after we caught the first Perch.

Follow the leader: cast through the brush, the fish are just past it!
Summer visits to Grandpa and Grandma always meant a trip Martin Wirkkalla’s place to fish in his private lakes. I remember walking behind Grandpa as he led me through the trees and brush to find those hidden lakes. Fishing would usually start out with me casting into the weeds and trees but after a couple hours of untangling weeds from lures, and carefully finessing lures from tree branches Grandpa and I came back with a few nice trout. Those times were always special to me because we were fishing in lakes that nobody else could, and we ALWAYS caught fish!

Follow the leader: take time out of your busy day for your loved ones!
The last time I fished with Grandpa was on his 62^nd birthday. I remember the day pretty well. Grandpa was pretty busy for some reason but we headed to the Naselle River off of South Valley Road to get a few quick casts in. What I remember most about that day was walking down to the river with him and asking him how old he was. He told me he was 62 and I remember thinking that 62 was REALLY OLD and that he would die soon. My eyes welled up with tears with the thought. I managed to get the tears dried up before they fell so he didn’t see. I spent the rest of that fishing trip appreciating EVERY little thing about him (by the way, this was the ONLY trip together that we didn’t catch anything).

Follow the leader: make people laugh!
Grandpa was a prankster. If you didn’t know this, you didn’t know Grandpa! Every time I visited he had a new trick up his sleeve. Even in his 80’s! The last prank he played on me was his exploding pen cap. I think over the course of 2 years I actually fell for that prank twice.

Follow the leader: confirm those answers?
When Grandpa would ask a question and someone would reply he would always follow up a reply with a “Huh?” I thought that was pretty funny because I knew he heard the reply but he still always said “Huh?”. I remember listening to Grandma replying to Grandpa, Grandpa then saying “Huh?” and then Grandma replying louder, firmer and a bit annoyed. I always smiled to myself when I heard that word “Huh?”, it was a funny habit of his.

Follow the leader: Give!
Grandpa was so giving. With every visit I ended up with some sort of odd, hand-me-down gift that meant a lot. Grandpa had a way of showing you all his cool things throughout the house and shop and waiting for your eyes to sparkle about one of those things. That THING usually was gifted to you by the end of your visit. Over the years I obtained some pretty special gifts: stuffed baby alligator, pocket electronic golf game, Skil-Saw, fishing lures, wood pens.

Thank you for your love and leadership Grandpa. I respect and honor your life and am committed to providing the leadership to my family and friends as you have done for yours.

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.

I've been using to last.fm recently and last night had good luck tapping into some great 80's songs by creating a station by using artist: "Kiss". Oddly enough over the course of two hours I didn't hear any Kiss songs but I did venture into a few solo albums from various members of the group. As I was coding away on a personal project, and slightly paying attention to the music, I was brought to full attention when I heard a pretty, Disney, girly, kids' song. What the... When I brought the last.fm window up I was greeted with the meta of the song "A Dream Is a Wish Your Hear Makes" from the "Ultimate Disney Princess"...here's the kicker/defect:

Sang by Cinderella...the late 80's early 90's glam metal band. Hehe, too funny.

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.

Zeph