Busy

I'm a person who loves the technical side of testing. When allowed, I like to get under the cover and look at the code I'm testing. Not that I can always understand it, but the code may trigger new testing ideas to investigate.

On a similar vein, I enjoy using test automation, I particularly like to write code for automation. In my current post, I've been given the opportunity to learn Selenium, an open source web based test automation tool, I'm using C sharp and nUnit to drive the testing. It's been fantastic! I love it! It gives me great pleasure to see lots of checks flying through the web app under test. I say 'checks' because that's what they are, lots of checks. If I code a check for the title of the web browser, it will check the title of the web browser, not anything less nor anything more.

You may already know that test automation would never replace the testing capabilities of a human being, especially a human being who knows how to test. This is something I need to be reminded of on a regular basis. Since I love test automation, I could spend days writing code for a sharp looking automated regression test and forget to spend a reasonable amount of time testing new functionality, highly used features, critical areas of the software.

As a tester, it's important I continually assess the benefit of the work I'm doing. Is what I'm doing the best thing or should I be doing something else right now? A problem with automation is it can provide a false sense of achievement. Like I said, it's just checking, and often doesn't find as many defects compared to manual testing (the last sentence was an understatement). Michael Bolton was the first person to highlight and describe the differences between checks and tests. You can read more about the differences on his blog posts.