- 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.2 Understanding Has to Grow
Molly Mahai, United States
Test manager
When we started looking at automation, I read everything I could get my hands on. I knew I couldn’t automate everything. I knew automation would not replace people, and I knew it would require investment. I read Software Test Automation (Fewster and Graham, Addison-Wesley, 1999) at a recommendation, and I learned about the steps to take.
The funny thing is that even knowing all that, I felt I could not accomplish the first steps to set up an architectural framework. I know that sounds simple, but what does an architecture look like? How do we want to capture our tests? How will we set it up so that we can reuse scripts? All these questions kept preventing us from making progress. So, in my usual fashion, I made a decision and picked an architecture. I had no idea if it would work or not, but we needed to get moving with something. This freed us up to learn, and learn we did. We created a regression suite that addressed a handful of our applications, and it looked like we were moving in the right direction, but we ran into problems. There were too many scripts, and the initial grouping (directory structure) was not sufficient for our use.
This time, though, I knew a lot more and figured out that our architecture was lacking. We had too many projects, the library was cumbersome, and so on. So, I redesigned the architecture and created staging areas, including a sandbox area for development scripts, a place for scripts in use, and a place for scripts that were part of the production suite. We also enforced the naming conventions that we had put in place. These simple changes fixed a good many of our organizational problems.
The key is that we knew about this potential pitfall, and we knew how important it was to have an architecture that worked for us, but we couldn’t design that architecture until we knew more of what we wanted to accomplish. For us, this was not a pitfall that we could avoid: We had to learn our way through it. The great thing was that I was intently aware of this potential problem (from reading the book), and I kept my eye on it. We redesigned the architecture as soon as we realized it wasn’t working for us, and the impact on our automation effort was negligible.
I relate this to trying to explain to teenagers that they will view things differently when they are older. They cannot grasp it through hearing from someone else; they must learn it for themselves.