Getting a Late Start on Test Automation

[article]
Summary:

Successful test automation requires team commitment, teamwork between testers and developers, and getting an early start. That's what Bret Pettichord said in a previous column. Bret notes that a reader, Jack Baseley, replied with a very good question: "How do you propose to deal with late starts?" Do we just give up? Bret picks up where he left off and devotes this column to answering that question.

My last column, Three Keys to Test Automation, stated that successful test automation requires team commitment, teamwork between testers and developers, and getting an early start. Jack Baseley replied with a very good question: "How do you propose to deal with late starts?" Do we just give up?

Jack asks:
My group just started an automated project and this article was a great help. My only concern is that an early start for automation is not always possible. How do you propose to deal with late starts?

My previous column identified two particular problems with late starts: you may not be able to get either the testability changes you need or the test strategy changes that you want. These circumstances make automation more difficult and may even prevent you from automating parts of the test suite.

Thus, I have a couple questions for those of you getting a late start. Why wasn't automation started earlier? And why do you want to do it now? Test automation is an investment.

In general, the later you start, the more you need to invest before you start seeing returns. Does the cost benefit analysis look better now that it did earlier?

I already said that commitment is key. With a late start it will be doubly so. You are going to need to double up on your staff. You'll still need to maintain your manual testing staff while the automation is developed. And you'll need a separate automation staff to get that effort off the ground without derailing your existing testing activities. Can your company make this kind of commitment to automation? And this is only the start.

An even bigger commitment will need to be made to changing your testing strategy. Testing strategy includes the way test cases are designed and described, how testing progress is reported, how tests are grouped and assigned, and how decisions are made regarding what tests need to be run when. All this changes with automation. And efficiency will require further changes. People resist change and often for good reason. Change entails risk. Manual testers may be concerned about their role once automation is implemented.

Managers may be uncomfortable having to learn new tradeoffs and having fewer eyes on the software. Changing test strategy on a mature product means taking avoidable risks.

About the author

Bret Pettichord's picture Bret Pettichord

Bret Pettichord is an independent consultant specializing in software testing and test automation. He co-authored Lessons Learned in Software Testing with Cem Kaner and James Bach and edits TestingHotlist.com. He is currently researching practices for agile testing. Contact him at www.pettichord.com or bret@pettichord.com

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03