Considerations for an Enterprise Test Automation Implementation
Going through my bag this morning I found my notes from Mark Meninger’s talk on Considerations for an Enterprise Test Automation Implementation from KWSQA Targeting Quality 2009. I had a bit of deja-vu with the metaframework stuff from two years ago which makes me think that there really is something to this pattern that could be monetized. He had way too much content for his time block, but that seemed to be a pattern with the other talks I peeked my head into as well. That’s okay though. I don’t claim to be a master speaker yet and these regional conferences are where you are supposed to make your mistakes, erm, learning opportunities.
- enterprise – serves all departments of the organization, across silos
- typically, every group does something on their own to achieve similar results
- benefits of enterprise automation are: shared components, shared development and a consistent philosophical approach
- the notion of ‘working with developers to improve their test process’ seemed to be a bit of a shocking one. Ummm, this is kinda the definition of agile-testing and that’s almost mainstream now so it certainly shouldn’t be shocking to anyone.
- when merging different efforts you have to decide what will stay the same and what will be different. (politics)
- framework – manages the process, SUT, pulls strings
- don’t glue your framework to a single type of testing
- metaframework + dsl = enterprise automation (as far as I could tell)
- Mark’s group doesn’t own testing; individual product test leads do. His group provides test tooling services (enterprise tool smiths)
- manual tests -> automated tests -> automated automation
- the barrier is coming down between development and qa; there is still a division but it is now more of a fence than a wall