Forcing an Error Pileup-A Fun Tester Trick
Long time, no blog. The holidays were brilliant, but now I'm back in action, being as testy as ever, so I want to share with you one of my favorite ways to test for errors.

Automation is a great way to "force errors", however, almost always it is one at a time. Causing error message stacking is a great way to test for race conditions, find crashes, and get into those states where you can't access a modal dialog, so you are stuck until you force quit.

Here is my big secret: I have no patience. I will not wait for an error to appear before moving on, nor will your users. They are clicky clicky mouse movers in many causes. They will refresh like mad, move on while one process is running.

So, my testing tip of the day is, don't wait for the program to finish. If you know of error conditions, in addition to trying to cause the same one to fire two at a time, try mixing them up today. The first time you find that state where you have an error dialog without focus and you have to force quit, come comment in my blog and it will make my day.

Automation and Those Darn Robots
Hope that the '08 is off to a good start. My resolution this year is to work "with those crazy robots".

Industry wide, it is time for the investment in automation to stand proud and be trusted. For those humans still testing to compliment the robots and let them be judged on their own merits. Those robots with value will prove what they are worth. Those with lower value must be allowed to come to light to improve. Improvement and not just change. I love that idea. I mean, do I really ever want to manually smoketest an installer in every language on 4 platforms again? Of course not. What a waste of testing time, experience and money. If any monkey could do it, why isn't it automated? If we paid to automate it and are still testing it manually, we are stealing our own money by not trusting our automation.  I spent part of today trying to convince someone on my team of this. They looked a bit nauseated and doubtful. I hope they will be afraid and do it anyways. I really really hope so. It's past time.

I had a discussion today with an ex-tester who is now a tech writter. I was explaining to him that what it really takes to get a testing job right now is a whole lot of coding skills, well, at least the ability to talk like you have lots of coding skills. Notice, I didn't say you need talent, experience making anything useful, creativity, or good testing methodology. You don't even have to be great at working with a team. You don't need to have any talent for finding bugs. You just have to fit the checklist of one of the Software Developer in Test jobs that is posted a million times all over the internet. There is nothing that can be done about this trend other than making sure you fit the description, or making sure you can work with the robots.

I tried making myself fit that description. I know that while I can force it, that is not my area of talent and passion. Thus working with the robots is my current plan. Keeping them shiny. Doing what I can that they can not. I have low desire to code and high desire to test. My love of the products I work on, my understanding of users, my testing experience may not be as in demand as more coding skills, but I KNOW they make a difference. I can prove what I've done is useful and is contributing. As well as having the facts to prove it, I know it in my gut when I am making the maximum contribution. I'll never be content to work in an area that I don't have talent because I know I can do so much more.

That's my other goal this year. To get one chance to show what I can do. To "Do so much more". I hope to take so many risks that I learn more than ever before. Coming soon is a long blog on "User Focus" and what it means.