Page 4

20 Reasons to use VSTS 2008 as your Automation Framework


DuctTapeBailingWire A question from Tobbe Ryber has inspired me to jot down a few things I’ve been meaning to do in a more extensive blog post for a long time. But since it hasn’t happened yet, I figure it probably never will, so you’ll have to settle for my abbreviated, half-ass version.

Twenty reasons to use Visual Studio Team System 2008 Test Edition for your software testing automation framework, ESPECIALLY if your development team is using .NET and Visual Studio:

  1. You are using the .NET platform which is a set of stable and robust libraries that allow you to do just about anything. Make HTTP requests, make Web Service requests, use COM, make database queries, the list goes on and on. Basically anything your .NET developer is doing you’re going to be able to tap into using the same context. Easily.
  2. You have the ability to easily make calls into several layers of the application under test using a few lines or code, without duct taping and bailing wiring a bunch of libraries or technologies together. Imagine automating something in the browser, making a call to a Web service and then calling the database to validate your results…All in a few lines of code.
  3. There are awesome tools and libraries that are built on .NET that allow you to automate browsers, such as SWEA, WatiN, and HTTPWatch.
  4. There is a great library and Visual Studio add-on that allows you to automate multiple browsers (IE 7, 8, FireFox. Safari and Chrome any day now), as well as Silverlight. Best yet, the recorder integrates with the IDE: ArtofTest’s WebAii and Design Canvas.
  5. Your ‘test harness’ is built into the IDE, and your tests can also be ran from the command line.
  6. The IDE is top notch when it comes to development and debugging (and test development and debugging). I’ve been using VS for automation since VS 2005, and when I’ve had to automate in other worlds (e.g. Linux, PHP, and Perl) I honestly feel like I’m working with tools that equate to a chisel and stone tablet.
  7. Auto-complete in the IDE is a huge timesaver. Your time spent searching the internet or referring to a library’s specifications is far less with auto-complete.
  8. Syntax issues with scripting languages (JavaScript, Ruby, etc.) can be a huge waste of time at runtime. If you write a test that runs for minutes, hours, or days it could fail halfway through due to syntax. A compiled language is not going to do this.
  9. The Microsoft.VisualStudio.TestTools.UnitTesting namespace is not just for unit testing, it works great for test automation. It feels a lot like nUnit to me.
  10. Integrating your tests with development builds is cakewalk. Using the mstest command line, it’s easy to have your tests run with a build in TFS or CruiseControl.
  11. You have the ability to easily move some of your tests up the chain to run along side of developers’ unit tests. By doing this you now have automated acceptance tests, so that releases to QA have higher quality.
  12. You are using the same environment/language as your developers. By doing this, you gain:
  13. A. The ability to have developers help you with getting over the .NET language or VS IDE learning curve.
  14. B. Knowledge and use of the same language and libraries used for development, thus having a greater technical understanding of what you’re testing.
  15. C. Easily share and discuss your tests with developers because they are familiar with the language you are using.
  16. Test results are in an XML format which means that if you want to use something other than VSTS to view results you can easily manage it.
  17. The .NET community is huge. Help, technical examples, and issue-workarounds are an Internet search away.
  18. Examples are SUPER helpful through MSDN. Training video series such as How Do I and VSTS Learn are a great alternative.
  19. VSTS also does load testing.
  20. .NET, C#, VB.NET, and Visual Studio experience on your resume are technology skills and buzzwords that lure recruiters.

7 Ways to Test Browser Compatibility


Seven ways to test browser compatibility, without having to manage your own testing lab:

Browser compatibility testing solutions have made some progress in the last year but it’s still far from ideal. A while back, I had a dream

  • I want to screen-shot any page in my website (requires a decent, free, scripting engine that will allow me to get to the various pages in my site that can’t be accessed via a specific URL (Watir?) ).
  • I want to screen-shot my site that is not yet published for the world (requires the service to exist within my internal network).
  • Once I’ve approved an ideal layout screen-shot I want the software to determine and tell me if the other screen-shots are worth looking at (by doing a statistical image comparison with a predefined pass/fail threshold).  Maybe MeerMeer is on the right road to doing this?
  • 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?)

Do Loop Until 0, a New Software Quality Assurance Comic


Do Loop Until 0 introduction 

I’ve been using Adobe Photoshop since version 3.0.  Back in the day I had to to insert MANY 3.5″ floppy disks to install it on my PC (20 or more I think). Oh, the good old days… Fast forward to 2009. I use Photoshop a LOT. For all kinds of things. Web design, logo design, photography touch up, creative drawing, etc. I LOVE graphic design.

I also love software quality assurance. I’ve had a desire for nearly two years to express my quality assurance thoughts via a comic. Over those years I’ve toyed with some ideas, created a few proto-types that included monkeys as testers, and received some great “How-To” advice from Brad Fitzpatrick. Inspired by Brad Fitzpatrick, IKEA assembly instructions, Shadow Culture’s Bug Bash, and a TDD poster I think I’ve come up with something. I’m not sure that we’re dealing with a “comic”  because it’s not necessarily funny (at least not my first two strips). It’s more of an illustration of simple things that occur between a Quality Assurance Engineer and a Software Developer, and yet more complex thoughts or methodologies occurring in the industry. I suppose that it could be more of a graphic storytelling that reveals a sick truth, simple lesson, or moral? I’m a very visual person. Images stick with me better than words. I know I’m not the only one. Through these images and subtle text hints I hope to tease the QA and developer mind and invoke some QA thought.

My new comic is entitled “DO LOOP UNTIL 0”, a name that is a software defect itself… In the BASIC language, “DO LOOP UNTIL 0” causes an infinite loop. Infinite loops are just plain bad when it comes to software. 🙂

For now I’ll host it here on, you can also get to it via and Once it becomes wildly successful and crashes the server in my office closet I’ll think about giving it a real dedicated home. Until then, let me know how I’m doing. Your comments are inspiring, good or bad.

Oh, the comic… I’ll post the first in the next few days. I’m still tweaking a few brush strokes… err… pixels.

Defect of the Day: Every site on the Internet may harm your computer


I noticed this on Google this morning at 7:50 AM (GMT 7:00 Arizona):


No matter what I searched for, all results returned returned “This site may harm your computer”. Attempting to get to the site through the safe browsing feature resulted in:


I bet the phones were ringing off the hook over at Google about then. All is well now.

Post navigation