229: A Journey through Test Automation Patterns with Seretta Gamba

Hit it.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with test automation, Joe Colantonio.

Hey, it's Joe.

And welcome to another episode of Test Talks. Have you ever wondered what it must have been like to find the Rosetta Stone, the key to deciphering Egyptian hieroglyphics? You might be asking, what does that have to do with testing, Joe? Well, listen up and find out. Today we'll be test talking with Seretta Gamba about her new book A Journey Through Test Automation Patterns. One team's adventure with the Test Automation Patterns wiki that she co authored with Dorothy Grant. This book is like the Testing Rosetta Stone for anyone who's trying to embark and decipher the what are the best practices for developing automation testing scripts? Get clarity and actionable advice on test automation patterns to improve any automation situation you might find yourself in.

Check it out. And talking about Dorothy Graham, she's actually.

Going to be one of our roundtable Experts at the 2019 Automation Guild Conference, an online conference dedicated 100% to helping you succeed in creating automation awesomeness. You don't want to miss it. Check out all our awesome speakers speaking February 4th to the 6th, 2019. Head on over to automationguild.com and register today. Test Talks is sponsored by the fantastic folks at Sauce Labs, the cloud based automated testing platform that eliminates the need to maintain your own selenium grid and test infrastructure. Try it for free today. Visit testalks.com and click on the Sign up now link under the homepage Sponsor section.

Hey Serata, welcome to Test Talks. Today I'd like to talk about your book A Journey Through Test Automation Patterns. But before we get into it, can you just tell us a little bit more about yourself?

Let's see, I started as a. I have studied physics and I decided immediately after my diploma to go over to it. At that time there was no way to study it directly and I've been a developer all the time and about 15 years ago I started to work on test automation and nobody in my company, me included, had any idea about test automation. So it was for me completely new and I had to find my way doing all kind of errors and mistakes and falling in all kinds of holes, inventing a lot on my way. And so if there had been something like the patents wiki, then it would have helped me a lot. And that's one of the reasons I think it's so important, because there are lots of People now doing more and more automation. And so it's important that they get to help that at least they don't have to make the same errors all the time again and again.

You studied physics. How did you get into it or why would you get into it when you have such a.

Well, first of all, because.

I think I'm a better good. It's better to be a good developer than a bad physicist. So I was a physicist, but not. I was never Einstein, let's say it like that. And I did a lot of programming for my diploma and I really enjoyed that. And so that's why I decided to switch.

Awesome. And I really enjoy this book because it was written in a unique style where it's not like a textbook, it's almost like a piece of fiction. So why did you write the book in that manner?

It happened per chance, I would say actually we wanted to do some case studies of people using the patterns or not using them and so on. And we tried to spread the voice and absolutely nothing happened. And after about a year I just got. How do you say? Had. No, don't want to wait any longer. And so I just invented the story and the story changed a lot in the time because of course Dot was also helping me other people reviewing it. And so I think we were already in version 15 or 16 or something like that with.com when you got the draft. But yeah, it just developed that way. And I think actually is better than with the case studies because we would never have been able to get case studies to describe all these kind of problems or patterns and so on. So I think so it's better. But it happened. It just happened, I would say.

So is there anything you learned from physics that you can apply to automation.

Or testing.

From physics?

You learn a lot.

It has been very helpful in all my career. And the reason is that if you think about it, physics is everything because everything works by some kind of physical laws. And of course in fear years of university you cannot learn all. So what you actually learn studying physics is how to.

Get solve a problem, how to do things so you know how to get on when something completely new comes up. And I have been using that a lot in all my career. I was doing all kinds of different developments for companies that did very different things. And I always found that an advantage against people that had not studied physics. So. And of course in physics also, I mean, how would they haven't found the laws of physics otherwise you do see patterns. And that was probably also one of the reasons that helped me see the patterns in test automation.

That's awesome. That's so cool. All right, so I guess we mentioned patterns a few times for the folks.

That don't know what is an automation.

Pattern or what are test automation patterns in general.

Well, a test automation pattern is actually simply a solution that somebody else used and it worked and it has used again and again. Where I found it was because I had written a chapter in the book from Doris Graham, Mark Fuster, Experiences of Test Automation. And so I got a free book and I started reading it. And this book has a very nice feature. They put on the side a box and it says a good idea tip, do like it. And so on, do like this. And I noticed that even if the.

Case studies were completely different, the same boxes were coming up again and again. And so there were. I noticed that the patterns. So the patterns are simply solutions that have been already used by practitioners and they have worked. So it's like inventing the wheel. If you're starting, you don't have to invent the wheel again, it's already there to use. That's the general idea.

Very cool. So how many patterns are there? And I think in your book you mentioned 90. Is that all the patterns that you have listed?

No, I think There are about 86 and the issues are about 55 or something like that. But of course since it's a wiki, we hope that somebody else will add new patterns or new issues. I mean automation is changing since when I started it was only with, how do you say, capture, replay and so on. And now there are so many other also possibilities that I mean there must come new patterns all along. But right now there are about 86.

Awesome. And as you alluded to earlier, it's like physics. You have a law that applies to everything. Same thing with automation. Doesn't matter if it's a record and playback tool or a program.

Well, yeah, because actually we're trying to.

Do that because for instance, we are not talking about any actual tool. And the idea is that if we do, then the wiki would be old very soon because the tools change very fast. So we don't want to talk about that. But general stuff that is useful for any tool, for any kind of company, for any kind of.

Test automation and so on. So the idea is to keep it a little bit wishy washy if you can, if you want, just to be able to. I mean, management problems will be the same, I'm sure. Also 20 years from now, tool problems, probably not. So that's the general idea, because there's.

So many patterns, do you have to use all of them? And if not, how do you know which ones to use?

That is a problem that we didn't recognize immediately.

So we had just a list of patterns, a list of issues, and the issues then suggest the patterns. But we realize that's difficult because we have tried to give readable names to the patterns and to the issues, but that's not enough. So we introduced a new feature and we called it diagnostic. And this diagnostic is simply something that works like diagnostic by a doctor. And I had the idea from a friend of mine who, who was a medical doctor, and he explained to me how doctors manage to find illnesses of patients that come through the door and they have never seen them before. They don't need much time if they're good doctors, of course. But the trick is that they ask questions. And first very general questions. And these general questions, the answers lead you to more detailed questions and so on. The answers, depending on the answer, you get new questions and you don't need so many to get to the point where you can say, okay, if you're a doctor, this is the illness, and then you can do something when you know that. Or to us in the test automation patterns that they say, okay, you have probably this issue and then this, and this is what you should do, and those are the patterns that you should apply. And so.

We think that in this way it's much more easy for people to find out where the problem is. Then if you just see the list of patterns and issues, there's much too many. I think it would be quite boring to read all of them and then you don't know which one was it anyhow.

Yeah, but I really like about that approach.

It really is unique to the person and their situation.

So what may be right for them or what they need will be different than another person following these patterns.

Yeah, of course, but the idea is.

That when, I mean, I always try.

To explain how this work and with DOT also when we have tutorials, we let them also do exercises to try it out. But the idea, of course, is that they go back to the company and then take the people that are concerned with test automation and together they try to answer the questions of this diagnostic to find out what is going on. And an interesting thing in the diagnostic, and probably you have seen it in the book too, is that sometimes you can answer differently, but at the end you get to the same point, or sometimes you have lots of questions and you think all of Them would be good and you don't know which one to answer and things like that. So it has to be done repeatedly until you really find your best way.

You do do a lot of tutorials, I believe, on this, on site with a lot of folks. Are there certain patterns that keep coming up over and over again that you've noticed?

Yeah, the patterns, I noticed them from the book. And then of course, once you start with the idea of patterns, then you and you see your own experience and talk with other people, you notice there are even more. So the first patterns were just one, taken from the book from Dorothy and Mark Fuster. But then of course we found other patterns too and some people even added also some.

I hope that this will go on.

Now, are all patterns technical or could they be cultural as well?

I would say there are 50, 50, because we have a lot of management patterns and those I would say are rather cultural. And that is also one of the problems with test automation. Most people think it's simply technical stuff, you have to learn to script something, you have to have the tools and that's it. But nothing can destroy test automation as fast and as thoroughly as a manager. So there is lots of problems that people have right now is simply because they don't.

Their management is not really responding to the needs of test automation.

In the right way.

And they think that test automation can deliver stuff that it cannot, or they think that you can have stuff that.

Is not possible, or you don't ask for things that would be easy to do but you think they're very difficult and stuff like that. So yeah, I think you could call these management patterns more cultural.

And so with these cultural patterns you have diagnostics that someone could follow to see how to make it better, certain actionable steps they can perform well.

Help you point out what the problem is. Because lots of, I mean, I remember my own experiences. You just go on like you had only one eye and you try things out and you think that that's the way. Then you find out, no, that doesn't work, then you try something else and so on. So you go just bumbling around, more or less. And the idea is of course that you get simply ideas to go without bumbling around. And of course some of the patterns. For me, we have a pattern, it's called management support. And if you don't have management support or you have the wrong kind of.

Support, it will not.

Your automation project will probably fail. And of course we cannot tell them, go to your manager and tell him he's stupid. No, but we can tell them what one could try to show them how it really works. So we have other patterns that tell you to share information, to do a pilot, to celebrate when you have successes, and so on and so on. And these are all things that of course work in a certain context. So you have to put them in the context in the company where you are, but they can give you ideas where the problem can be. Otherwise you're just running around. It doesn't work, but you don't really know why.

So for the people that are listening, can we give them just a high level example of how this would work with the pattern? Is the book standalone or do you have to use it with the wiki? How does it work at a high level?

The book is standalone because we have put all the patterns, all the issues and even the diagnostic or in the appendix of the book. So you don't need the wiki to do it. Of course, especially if you want to do the diagnostic is easier to do on the wiki, but you have everything in the book. So you can really read the book and use it on the train if you want to. And not being online.

Awesome. So like I mentioned, this book is written in a unique way. And I don't know if you remember this example, but you have an example of, I think it was the abstract level pattern and how you used a hamburger as an example. So do you remember that? Can you just tell us a little bit more what that is?

Like how you explained it, the one with the hamburger?

Yeah, that one. It happened just per chance that I was trying to think how to explain it. The problem is the. That is a pattern that tells you to divide the stuff in different levels so that people with different level of knowledge or technical knowledge can still work effectively even if they don't know one level. And actually this is done also by development. So.

If you think at the beginning of the programming, people were programming in assembler and that was really the machine language. And then they started to develop languages that use assembler, but you don't have to know assembler. And so that's a general idea. You don't have to go deep, deep in the technicalities, but you can really concentrate on what's interesting for you in that case, to automate a test case, for instance. And so this approach tells you that just as in a hamburger, you have the patty and that is meat and you are not interested to know how it was grounded from what kind of cows it comes and what the cows were eating of. That doesn't interest you at all. You eat it simply you use it. And the same thing with the salad, the pickles, whatever you put also on the hamburger or also the bunch, all these things are pieces that you don't really know how they were made. It doesn't interest you when you make a hamburger. You take the whole pieces and just put it together. And you can put it together in very different ways because of course you can have a hamburger, you can have a cheeseburger and in the meantime, I don't know how many possibilities to change it. But you don't need to know how to do the, the stuff that you put together. And that's what important with test automation. If you have this reduce this pattern abstraction levels, then a tester can put together.

A test case to automate without really knowing the whole script stuff in the tool. But that helps a lot because for instance the test automator, he would know or she everything about the tool but eventually not know how to put together a test that is good, good test in that way everybody can do what you can do best. So a test automator would do the technical stuff, a tester would do the testing stuff and so on. That's the general idea of this pattern.

Very cool. So I find when I'm writing about something, sometimes I discover something I didn't think about before and I'm like, wow, I, I never knew that because I'm writing it and thinking about it a little more in detail and is there anything you learned as you were writing this that you never really thought about before?

Oh yeah, I learned a lot. I was changing the patterns and adapting them and so on because suddenly I saw a problem or an idea that we hadn't covered before. Yeah, we did that a lot of time.

Very cool. So I guess we'd even mentioned what's the wiki page for people that want to check that out.

It's called test automation patterns.org okay Seretta.

Before we go, is there one piece of actual advice you can give someone to help them improve their test automation pattern efforts?

Well, of course, simply to go to the patterns and use them.

I think that's a no brainer.

Thank you Seretta for your Test patterns automation awesomeness. The links to everything of value we.

Covered in this episode and head on.

Over to testtalks.com 229. And while you're there, make sure to.

Click on the sign up for a.

Free trial link under the exclusive sponsor section to learn all about Sauce Lab's.

Awesome products and services.

And as I mentioned earlier in the show, make sure to head on over to automationguild.com and register today for the February 4th to the 6th online conference dedicated to helping you accelerate your test automation efforts in 2019. You don't want to miss the 2019 event. Head on over to automationguild.com so that's it for this episode of Test Talks. I'm Joe and my mission is help you succeed with creating automation awesomeness. As always, test everything and keep the good.

Cheers.

Thanks for listening to the Test Talks podcast. Head on over to www.testtalks.com for full show notes, amazing blog articles, and other automation awesome.