Monday, June 22, 2009

Pull Up

Back when I was first working in automation, my AUT was a java based course player. Users could learn about how to be a good manager, how to shake hands in Australia, and a myriad of other soft skill topics. At the end of each learning session, the user would be given a 10 question multiple choice quiz on what they learned.

My job was to have my automation tool launch courses, answer questions, and confirm that the scoring mechanism in the app was behaving properly.

What made this particularly challenging to automate was that the questions were displayed in random order, and there were anywhere from 30 - 50 potential questions per quiz. So you never knew which questions were coming, or what order they were coming in.

I voiced my concern to my team lead, and she said that I should maintain a list of every question that could be listed in the course, and the answers to those questions. Now, that might have been ok if I were only dealing with one course, but there were dozens of courses I had to work with to ensure the app was behaving properly.

One of the things I learned early on was to "pull up," which is my way of saying take a breath, step back, and look at the whole picture. Is there a better way to handle this? What I realized was that somehow, the AUT knew what the right answer to any question was. If Choice C was right, then the AUT knew that. It was so blindingly obvious that I was ticked at myself for not seeing it sooner.

I went over to one of my developers and spent the next 10 minutes discussing my situation, my intended solution, and what was required to implement it. By the end of that afternoon, I had a method in place that would call out to the AUT and tell me which answer was correct for any given question.

It was a heck of a lot cleaner than maintaining a question/answer list, and it made for good "press" internally with automation. It also raised my developer street-cred, because folks saw that test automation was a lot more than just point&click record and playback.

So when you face a challenge in your automation, remember to pull up and make sure that you're not missing something obvious.

Thursday, June 11, 2009

The Kindle

My family bought me a Kindle 2 for my birthday a couple months ago, and I am totally enamored with the device. I really do forget that I'm not reading a physical book. The electronic ink the Kindle uses is crisp, and very easy on the eyes. The only downside is how easy it's become to drop a ton of money at Amazon.

Here's a brief sampling of some of the titles I've picked up so far:

The Prince. This book should be in everyone's library. Machiavelli has a bad rep, but this book is extremely insightful. I have a paperback copy, but it's getting pretty tattered.

UR. I'm a big Stephen King fan, and this novella is a story about the Kindle. He ties it in nicely with the Dark Tower and From a Buick 8.

Agile Testing - A Practical Guide For Testers and Agile Teams. This is a great overview of agile testing, and what a tester's role is in an agile environment.

The Little Red Book of Selling - It's marketed as a sales book, but this little gem can be applied to achieving pretty much any goal you may have.

Goblin Hero - If you've ever read epic or heroic fantasy, you owe it to yourself to pick up the Goblin books by Jim C Hines. They give you a look at what it's like from the Goblin's point of view, and they're really funny.

I'll post more in-depth reviews as time goes on. What are you reading these days?

Wednesday, June 3, 2009

State

One thing to remember with UI automation is that your application needs to be in the same state each time the test starts. You need to be on the right screen, with the right options enabled, and your test goes from there. This makes perfect sense to me, but I'm amazed at the people who get frustrated with that. They say "The tool should just know."

Now I agree that it's good to build logic into your tests that can get you onto the right screen if you aren't there already. It's also good to build recovery scenarios into your tests so you can get back to a good state if something goes wrong. However, to assume that the tool is just going to know what to do is ludicrous. The computer is a stupid box. You are the one with the brains. You tell the box what to do and it does it.

Come on, do you really want Skynet running your test efforts?