Using Patterns to Diagnose Test Automation Ailments
As soon as I started with test automation, I got completely hooked. I was lucky to start in 2001, when there was already a lot of literature on strategies and the tools were already quite efficient, even if not as powerful as nowadays.
I went on to develop an interesting framework and got to talk about it at EuroSTAR conferences. Dorothy Graham heard me once and found my talk interesting enough to ask me to write a chapter for her book Experiences of Test Automation. When the book came out, I was curious to find out what the other contributors had written.
Some of the best features in the book are sidebars that compact the experiences in the chapter to tips or suggestions for better automation. As I was reading along I noticed the same tips or suggestions coming up again and again, and suddenly it clicked: patterns!
In my career I have worked mainly as a developer, so I know a lot about patterns and really appreciate their worth. My next action was to search for a book about automation patterns—but I found none! Apparently I have a brash streak, because I decided on the spot to write the missing book myself. (Well, not so brash after all: I asked Dorothy Graham if she would be interested in doing it with me.) We developed a wiki about test automation patterns, and we have already held quite a few tutorials where we introduce them and explain how best to use them.
Now, tutorials are learning events for both the participants and presenters. We realized before long that it wasn’t very easy for someone new to the concept to find the patterns that would be most helpful in their context. After considering the problem, I remembered a conversation I had a long time ago with a doctor friend. He explained to me how doctors can diagnose a new patient relatively quickly: They start by asking general questions, and depending on the answer, they ask other, more specific questions, then even more specific questions. In the end, having asked the right questions, a doctor can pinpoint the disease with some precision, and then the cure is straightforward.
So we developed a similar method for our patterns. We ask questions about the condition of a test automation effort that can lead to the specific issue that’s ailing the project. As with the disease, once it is known, it becomes easy to select which cure (i.e., pattern) to apply. And the charm of the method is that once you have the questions, you can actually make the diagnosis yourself.
I will be demonstrating this method at STARWEST in October, so if your automation is ill, the doctor is in!
Seretta Gamba is presenting the tutorial Test Automation Patterns: Issues and Solutions and the session The Doctor Is In: Diagnosing Test Automation Diseases at STARWEST, from October 12–17, 2014.
