- 29.1 Three Grains of Rice
- 29.2 Understanding Has to Grow
- 29.3 First Day Automated Testing
- 29.4 Attempting to Get Automation Started
- 29.5 Struggling with (against) Management
- 29.6 Exploratory Test Automation: Database Record Locking
- 29.7 Lessons Learned from Test Automation in an Embedded Hardware-Software Computer Environment
- 29.8 The Contagious Clock
- 29.9 Flexibility of the Automation System
- 29.10 A Tale of Too Many Tools (and Not Enough Cross-Department Support)
- 29.11 A Success with a Surprising End
- 29.12 Cooperation Can Overcome Resource Limitations
- 29.13 An Automation Process for Large-Scale Success
- 29.14 Test Automation Isn't Always What It Seems
This chapter is from the book
This chapter is from the book
This chapter is from the book
29.4 Attempting to Get Automation Started
Tessa Benzie, New Zealand
Test engineer
My company was keen to get into test automation. We had a couple of days of consultancy (with one of the authors of this book) to explore what we wanted and the best ways of achieving our goal. We discussed good objectives for automation and created an outline plan. We realized the need for a champion who would be the internal enthusiast for the automation. The champion needed to be someone with development skills.
We hired someone who was thought to be a suitable candidate to be the champion for our initiative. However, before he could get started on the automation, he needed to do some training in databases, as this was also a required area of expertise, and we needed him to be up to speed with the latest developments there.
After the training, he was asked to help some people sort out some problems with their database, again “before you start on the automation.” After these people, there were some other groups needing help with databases. When do you think he finally started automation? As you may have guessed already, he never did! Of course, it can be very hard for a new person to say no, but the consequences should be pointed out.
A few months after that, a new test manager came in who was keen to get the automation started at the company. He did some great work in pushing for automation, and we chose and acquired a test tool that looked suitable. There were a couple of other contractors (the test manager was also a contractor) who were coming to grips with the initial use of the tool and began to see how it could be beneficial.
So we had a good start, we thought, to our automation initiative.
Shortly after this, there was a reorganization, and the contractors and test manager were let go. A new quality assurance manager was brought in, but test automation was not on her list of priorities. Some people were trying to use some of the automated tests, but there was no support for this activity. However, there were many, many tests that needed to be done urgently, including lots of regression tests. Now we had “football teams” of manual testers, including many contractors.