First up today was Linda Hayes talking about Cost Effective Test Automation Strategies. She grabbed my attention right off the bat by making clear that test automation is not about reducing your test staffing but rather about your leveraging testing resources. In fact, she says, if your goal is to reduce support and rework costs, then you actually need to do more testing, not less.

Right on!

Other choice quotes:

  • If you haven't achieved quality in your product development process, it makes zero sense to start optimizing (i.e., reduce testing on) it.
  • The best requirement ever written is a test case.
  • The one time record-and-replay is useful is to track a manual testing session. It's like the black box on an airplane - only useful after a crash.

Oh, and those cost effective test automation strategies the talk was purportedly about? Linda covered those in spades. The short version is "Build a framework". Linda is partial to using class libraries that wrap the necessary functionality for interacting with widgets (be they UI widgets, or database functionality, or SOAP messages, or whatever) that are then called from data-driven test cases. She likes this level because that functionality tends to be generic across applications, so you can use a single framework as the foundation for testing multiple applications.

I agree this is the place to start. Linda's framework is equivalent to the controls abstraction layer of our Physical Object Model. We of course see a huge amount of value in raising the level of abstraction from poking individual controls up to thinking in terms of user actions - our test cases just seem simpler when they talk about what the user is trying to accomplish rather than the details of which UI they have to poke to do so. And thanks to Execution Behavior Manager we can write just one test case and still hit every execution path.

Even so, this was a very good tutorial. Let's see if the rest of this week can be as good. <g/>