Seven Steps to Test Automation Success

In starting a new test automation group at work, I started doing some industry research to get some do/don't ideas. I really, really dislike the idea of GUI x,y coordinate automation; other GUI object-aware automation tools seem to be pricey and still seem like tons of maintenance and really distanced from testing the real meat of most apps. Most info that I've found on the topic has either dealt with things at the GUI level (probably since that's "easiest" to implement, despite being difficult to maintain), or at the unit level--while these focuses certainly have their merits, I was looking for info on the level in between those things; Google calls this the "medium" level.

I found this article by Brett Pettichord called "Seven Steps to Test Automation Success", where he talks about the difficulties in automating tests, and I really think he hits a lot of nails on the head. He argues that in developing automate tests, you should really treat your work like that of software development, then discusses his seven steps:

1. Improve the Testing Process
   
2. Define Requirements
   
3. Prove the Concept
   
4. Champion Product Testability
   
5. Design for Sustainability
   
6. Plan for Deployment
   
7. Face the Challenges of Success
   

In each step, Brett focuses on laying lots on the table--and a lot of times things that I hadn't really processed as stuff that needed to be on the table. I like how he consistently hints at making the app under test testable, thus driving the ease of use, not just for automaters & testers, but for users as well. I think he does a wonderful job describing how test automation teams can bridge the gap between both development and Black Box testing, as I think this is definitely a challenge that I'm going to face in building my team.

All in all, there's tons of meat in this article, so take it in sections or get a cup of coffee and get comfy, but either way I think this is going to be a reference of mine for quite some time now.

Teach me to test

In seeking to appease my recent desires to get back in to writing code, I flirted with the idea of purchasing a book on Xcode and Objective-C so I could get crackin' on some Mac dev.  With my other recent desire of cutting back on spending, I decided to check out cocoalab.com's free eBook on the topic.  While it covers the uber-basics of getting in to development, it also covers the uber-basics of Xcode, which is what I really need.  It also does this on Leopard--something no books on the market can tout yet (so I've read). So I blew through the first 6 chapters before having to attend my roomie's bday party, and am excited to get back to it ASAP. It just occurred to me though, that while the book talks about debugging in Xcode, it barely talks about testing (well, so far).  And then it occurred to me: most development books that I've ever read don't really make many suggestions about testing at all--much less about how or when to test the code you wrote.  I realize that Test-driven Development is really a suggested technique, but it seems to me that if developers at least followed these concepts, they would find more success.  Thus, if books taught how to test your code in equal doses at they taught how to write code, we might see a reversal in the economy.  :-)