- 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.12 Cooperation Can Overcome Resource Limitations
Michael Albrecht, Sweden
Test manager, consultant, and speaker
I was in a test team that was testing technical aspects of banking system processing without access to a GUI. For this project, we needed not just domain knowledge but more technical skills than we had. Rather than take the traditional project approach and try to hire someone, we got everyone together, both testers and developers, and developed the skills we needed between us, although we did need to bring some testers with coding skills into the team.
We had no money for tools, so we just started to use the same open source tools that the developers were using. The difference in the way we used them was that we needed to do some coding to create scenarios for our tests rather than just exercising each one individually. We also needed to verify our expected results and double-check with the database directly.
We didn’t spend any money on tools, but we did spend a lot of time (we also built our own performance-testing tool). Sometimes it is easier to explain (or hide) these costs: The purchase of a tool would appear to be a large single cost, but time being spent over months or years doesn’t appear to be as significant even if it is the same or even more money!
We found that close cooperation with the customer and working as a team enabled us to succeed in our automation. Being forced to use the same tools was a blessing in disguise in the end.
P.S. from Lisa Crispin: In one project (a good while ago), I knew I needed to get help from the developers to progress the automation, so I decided to use the same programming language for the tests that the developers were using. I bought myself a book and started writing scripts. When I needed help, the programmers were happy to help me because they knew the language.