We had the privilege to catch up with Dorothy (Dot) Graham at this year’s STAREAST Software Testing Conference.
With more than 40 years of experience in the software testing industry, Dot has a deep understanding of the challenges and opportunities that exist for software testers today. Dot shares some of the key takeaways from her two tutorials and lightning keynote at STAREAST, and discusses some of her recent work with Test Automation Patterns in our interview from the STAREAST expo.
Watch the full interview below.
Miss any of our other STAREAST interviews? Watch them all here.
What were your two tutorials at STAREAST about?
One of them was about how to do good test automation, from a management perspective. The second tutorial was looking at a Wiki that I’ve been developing with Seretta Gamba, that’s called Test Automation Patterns. And we were looking at patterns, but more from a generic technical point of view.
Let’s start with the first tutorial. If you had to summarize the tutorial into three key findings, what would they be?
It’s important to know why you’re automating and to set clear objectives. It’s very important to be aware of some technical issues, particularly testware architecture.
And don’t forget about people issues. It takes time, so it requires management support.
How about the second tutorial? What was that session about?
The second tutorial was about Test Automation Patterns. People can find more about this session at TestAutomationPatterns.org.
Basically what we were doing was looking at what the Wiki does. It creates various problems – or issues — which are things you need to do with automation. The patterns are basically ways of solving the problems that have worked for other people. So, the Wiki has something like 80 patters and 50 issues. We follow four categories – process, management, design, and execution – because the problems that automation has are very varied.
Could you give me an example of a pattern? What would a real world issue look like?
One of the patterns is management support. If you’re going to do automation well, it’s no good just starting at the grassroots and hoping it will scale up through the whole organization. You need management support because it takes time to build good automation. There are also the design patterns, which includes things like testware architecture.
One of the other things I talked about in the tutorial was zombie tests. A zombie test is a test where maybe it’s going to be updated but it hasn’t been updated yet. It comes from Christoph Mecke, who wrote one of the chapters in our book, Experiences of Test Automation. And what it is, is that the middle of the test has all been commented out but the test still runs. And because it’s not doing anything it turns green. So you have all these tests that are running but aren’t actually doing anything. So you get a false sense of confidence.
Tell us more about the lightning keynote you did at STAREAST?
In that, I was basically doing an analogy. So, at first glance it looks like automation is very easy. When you see your first demo, or write your first test, you’ll say “oh, that was easy.” But that’s like picking the low hanging fruit. But what you really want to do with test automation within an organization is more like building an orchard so that you can grow enough fruit to feed a small town.
You need to fertilize the ground, you need to choose which trees are going to grow, you need to prune them, you’ll need to bring them to market and sell them. I think the analogy works pretty well.
From your 40 years of experience within this industry, where do you find that people most go wrong with test automation?
There’s certainly more than one. I think one of the things people don’t do is they don’t research before they start. They don’t look at what else is available. They don’t read books or see what other people have done. They make so many mistakes by just going out and trying things without seeing what’s out there to help them.
And other things like not having enough management support or not having enough time to do it well. Not having the right structure, as well. I see framework as an implementation of testware architecture. And there are some commercial and open source framework tools. And there are tools that have infrastructure built into them, as well.
We’ll be sharing more interviews from the STAREAST Software Testing Conference all this week. You can stay up-to-date about updates from upcoming shows and all of our latest content by subscribing to the SmartBear Blog.