236: Sleeping Is Not Your Best Friend in Automation with Michelle Macdonald

Are ya ready, kids?

Aye, aye, Captain.

I can't hear you.

Aye, aye, captain. Oh.

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 of Test Talks. Have you ever watched spongebob squarepants? If so, this episode is for you as we test Talk with Michelle McDonald all about her SpongeBob theme talk she gave at Selenium Conference in Chicago on Sleeping is not your best friend in automation. Discover why sleeping is not optimal, and learn better ways of using weights in Selenium. So, are you ready?

I'm ready.

If so, who? Listen up.

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, Michelle, welcome to Test Talks.

Thank you.

It's great to have you on the show today. Today I'd like to talk about your presentation you gave at Selenium Conference. Sleeping is not your best friend in automation. But before we get into it, could you just tell us a little bit more about yourself?

Sure. For many years I was just involved in programming and development work and I've been working in my current position at Pronto for about 13 years, but I joined the QA department about five years ago or six years ago actually. And, and then we started building up our automation because the, the product that we have, our company is an ERP company and the product that we have, all of a sudden we were building this web connection so that we could have a communication between our ERP and the browser. And so we needed a complete suite of test automation for that. So I had to learn Selenium and automation concepts and all sorts of things. So I'm still learning, I'm still learning. I still think that I'm a long way to go when it comes to testing and automation, but that's what I've been doing.

Cool. So, yeah, I was surprised that you're testing an ERP system and you chose Selenium because I know there's a lot of vendor tools out there that integrate really well with erp. Why did you choose Selenium? I didn't even know it actually worked with ERP systems. So how did you get it working?

So basically what I needed to do was I needed to just first of all experiment and play around with the Selenium IDE at that time, the IDE was in one of its other incarnations of life back then. And from there I realized that I had to write my own scripts to test what I wanted to do and have more flexibility and more power over my scripts. So basically we have thousands and thousands of screens because we have all sorts of modules and functions, we have point of sale, we have financials, general ledger, we have purchasing. And all the screens in a way behave the same way. So what we did was we built some sort of overall general page objects and methods to sort of interact with anything and everything in rerp. So we don't have tests that cover everything because that would mean we'd have infinity number of tests, but we test well. First of all, I had to build tests to make sure that all the functionality was intact in the browser, that all the data tables were navigable, all the buttons could be clicked, all those sorts of things. Dialogues and pop ups were working as expected. So that was, it was pretty easy actually. And we just, I decided to make sure that we had explicit weights used all throughout our test suite. So we had real control over how we were expecting things to appear and happen and so forth. And that's where I really had this interest in this talk that I gave because I could see the easy way out sometimes was just to pop in asleep in your code. But for me it was more, far more efficient and better to, to use fluent weights and things like that.

Nice. So in the email you sent me actually I thought was interesting as part of this framework, I guess you have less technical testers that are able now to write scripts using the framework you created. Is that.

Yeah, yeah. For a lot of them it was really hard at first because you know, they weren't.

Didn'T have a lot of programming experience but we held training sessions for them.

And did one on one pair programming and just sat with each of them. Basically I, first of all I, I taught my manager and then together we spread it across the team. So there's about 12 of us that learn how to write scripts and even though sometimes they find it hard because you know, they might want to do complicated things like they might want to do some looping or some sort of something fancy like data providers or something. But basically we just spent time with them and promoted it as obviously opportunity for them to really improve I suppose their resume and their career as well, that they have this experience in using a test automation product and they also have that Control. They love it because in their projects they can write their own scripts for repeatable tests and things like that, and then they can add it to the suite at the end of the project for regression testing. So they just. I think they really enjoyed having that. That extra angle to their job.

Awesome. So how do you encourage them, though, to do automation? Because, like you said, they didn't have a program background. A lot of people I speak with usually, like, I'm not an automation engineer, not doing it well.

Some are more keen than others, so some will. More. More will spend more time.

Naturally wanting to do it, but I suppose we just really encouraged it and I suppose because we were willing to spend the time and not leave them floundering on their own. And also the framework, I set up a framework.

That allowed them to. Rather than write a fully fledged Selenium command, I would create little routines and methods that allow them to do things like click buttons and close dialogues and write to input fields. So the scripts that they actually write are a little bit more simplified than the ones that perhaps I might write or the code that I will put into the page objects and so forth. So we actually made it a little bit easier for them to write their own scripts. And the only, I suppose, learning curve after that was not just the programming language, but just using the. We use Eclipse ID here and things like that. Just getting familiar with new pieces of software in there. So, yeah, I think because they've had the support, they've been keen to continue with it and to really keep contributing to our test automation suite.

Cool. So I just want to switch gears really quick before we get into your awesome session at Selenium conference. Sleeping is not your best friend in automation, but another interesting point I'd like to touch on. Was this your first time actually speaking at any conference?

Yeah, it was. I was blown away when they asked me to speak because I actually submitted a couple of talks and they picked this talk about sleeping. They asked me to speak on this topic and I was just. Yeah, I was going away because I thought it a bit of a silly topic, actually, but I thought, you know. But anyway, it was great. Yeah, what happened was they put me. Well, actually I. I said, can I go through the speakeasy program? So I had a mentor, Erwin Van. I can't say his name properly, I'm sorry. It's a lovely Dutch surname that I cannot pronounce. But he. He's based in Melbourne and he went through my talk proposal and just help to, I suppose, refine it a little. Bit. And I was surprised because, yeah, as I said, thought I thought the subject wasn't a strong enough topic perhaps, but it was a topic that I was passionate about, so maybe that came through.

A lot of times people are afraid to speak or, you know, they just don't have confidence for whatever reason. I was the same way. So do you have any advice or thoughts since this? You talked for the first time and what other people can do or what first time speakers can do or advice for, I guess. First time speakers?

Yeah. Well, the first thing I did was I bought a book. We went to New York for a holiday in July and I thought, I'm going to buy a book about giving presentations and read it on the plane. And I did. And it was a great book. Giving powerful Presentations, I think it was called. And it, it just really helped me sort of to think about. When I give the talk, it's not about me, it's about the audience. And I don't want to alienate the audience by saying, you should do this or you should do that. It should be more conversational. I should give a talk that perhaps appeals to motivating them to do something. So hopefully I did do that. And also I watched a few of the TED talks just to get a bit of a feeling or how professional speakers really use a stage. But of course, when I got up there, the podium and I didn't move about at all, but it was just looking at things like that I think really helped can give you confidence. And yeah, I was nervous, obviously, getting up there for the first time. I was very nervous getting up there on the stage. But I think just the encouragement and support from the Selenium team there and the people that organized the event that just gave you that confidence and gave you that encouragement. So if someone out there wants to give a talk about a subject that they're passionate about, then, you know, I think that they have to do two things. They have to try to work really hard at the content of the talk and also really look into giving presentations that are perhaps interesting and engaging.

Cool. And from what I hear, your session went really well for some reason. I guess spongebob really resonates with a lot of people.

Yeah. On the weekend after the conference, I was walking around the University of Chicago area. I was going to museum there, and these two really tall Dutch guys came up to me and said, hello, did you give the spongebob talk? And I'm like.

Oh, the one about sleeps? Yeah, yeah, yeah, that was, that was me. Did you enjoy the Talk. And I said, oh yeah, we really enjoyed it. And I said, did you feel that you needed to learn about how to use explicit weights and things like that in your test? And they said, no, no, we already do that. We just thought your talk sounded interesting and they were really nice. So that was really good feedback to make them. And yeah, and quite funny that everyone calls it the spongebob talk, which I hope the leading committee don't mind.

That's awesome. So that means you did an effective speech then probably following those rules of creating engaging content. And so that takes us to the main event. Your session was like, as I mentioned, sleeping is not your best friend in automation for folks that don't know what is sleeping.

Okay, so in any particular language, you can actually put in a pause, a delay or a fixed timeout in your script so that it doesn't do anything, say for a period of time. You can specify the time, say 5 seconds, 1 second, 1 hour if you want, and it will just put the script to sleep and pause all activity until that timeout is over. And so sometimes people do that for things like, you know, when you go into a login page and perhaps the page is loading and rather than wait for the form and all the containers to be there, people will put in say a five second sleep just to cover it, which is a little bit dangerous because it could be that time could vary obviously for that page to load. So yes, people often use sleeps as a bit of an easy way out to cover some waiting periods that they might need to perform. Sorry, I just. I remember you asked, why did we pick Selenium? Well, we picked Selenium because it was open source and we had that flexibility of choosing what language we'd like to use. We actually was another guy that started out using Ruby, but in the end we. We used the Java language because of various reasons that were better for us. But yeah, we just, I suppose because it was, it wasn't going to be a costly. The only cost that was going to be involved was for me to learn everything, to take my time in learning about how Selenium worked and how to write scripts and things like that.

So I guess. So what are some ways that that can help people avoid using weights or hard sleeps?

I think that for us here, where we work, what we do is. It's one of the things I talked about in the talk as well is that there are some really common things that we often wait for and we should have a toolkit, a toolkit of methods or little snippets of code that will help us to wait for things that are quite common. So one of the, one of the things could be that you're waiting for. You can use the webdriver weights in conjunction with expected conditions if you like. You can define, you can define your own conditions. But one of the things that we often want for is things to be visible or present. There's just a common common everyday weights that we use that we should be always make sure that we should be using. So in my talk I gave some examples of all the different ones that we often use and one of them is also invisibility. So when we're waiting for an element, are we waiting for it to be invisible or to be, or to be gone or to be stale? And often when things change on a web page or in an application, are we waiting for text or text value to change or to be a certain value that we're expecting? So I think that's, I mean, obviously I don't know how to use weights in order different languages, but I know that all the languages have those options of using webdriver weights to wait for the common everyday things that we expect when our pages change.

So yeah, I think you mentioned three things. One of them was the webdriver weight that you just mentioned. What are the other two? I think there was a fluent weight and expected conditions. When do you know when to use which one? I guess.

Okay, so webdriver weight, I suppose your common everyday garden variety, you create an instance of how long you're going to wait for something, but the fluent weight just allows you to also as an extension you can, I think the webdriver weight poles every 500 milliseconds for, for the expected condition that's waiting for, whereas a fluent weight you can specify how long you pole. So I often use fluent weights that poll every hundred milliseconds. And the expected conditions are something that you can either define yourself or you can use the ones out of the box if you use Java or Python. So yeah, there's just, I think there's, there's so many, especially building your own conditions where you, you're waiting for something. You can really be very. Create some really fancy ones, some really complicated ones if you. That suit your application.

Nice. So you also mentioned something about using CSS selectors elements and special state elements. Is that along the same lines of how getting fancy of different things you can wait for?

Yeah, because sometimes I use, I use a CSS selector that will be waiting for a class to contain this or this and this and this. And I will then wait for that element with that selector as a way of getting. Waiting for something very specific. Also, I use some XPaths as well, the relative ones, not the absolute ones. Yeah, I use XPaths as well to sometimes wait for things that are very, very specific. Because some people think, okay, when they start, I'm just waiting for an element with this id, but you can wait for so much more. You can wait for an element to have a name or an id, but also have various property attribute values as well. So I think that's what I meant by the CSS selectors.

Yeah, I think you also mentioned something about people should know their elements really inside and out.

Yeah, I found that sometimes with working, for example with the, the team here, sometimes they say I have to use asleep because.

My test doesn't work unless I use asleep. And that's when I sometimes say to them, okay, well let's, let's just. It takes us one second to click on inspect element. Let's just have a look at what is the structure here and see what's going on on. Let's understand them. And I think, I think that's really great because it gets people to know the application really well, how it's constructed and how things move. And in fact, I've actually often looked at the structure of the. For example, with the browser, I look at the structure of the DOM and I, and I've said to the developers, I've said, well, do you think that this should be like this or is this consistent? For example, we had elements that often were disabled. They were disabled in a variety of ways. So for example, they would have an element would say read only, or it would have a disabled attribute that was true, or for another element it would be. It'd have a class where it set the disabled value. It had a disabled value in the class. So I even asked the developers to make their code a little bit more consistent in the way they present the elements. So I think sometimes getting to know the structure of the web page can also help you to understand a little bit about how the web page is formed and know your application a whole lot better. So hopefully I've encouraged the team to do that and they're not scared now of digging in and looking at what something is made up of.

So that's really good, that's great advice. But how do you do that? Do you use certain tools within Chrome or Firefox that allows you to inspect the elements? How do you drill down on and Inspect all the different things with your elements?

Yeah, we generally just use Chrome developer tools, but we have. Sometimes I even. I've written some code for them that spits out.

What all the list of elements are on a particular page that they're at and spits out potential code that they can use. So, for example, you know, they go into a web page and I run the code and it just inspects all the elements and spits out all the. All the buttons and input fields and things like that to the consoles. So then they can paste that into their test. So that's another way of helping them to understand what their web pages are made up of. So, yeah, but our inspector tools are just the general stock standard ones. We don't really use anything particularly fancy, I think, because we're pretty budget conscious here. So we're just using what we can, that's for free.

You also had some things on the Invasion of the Upward Sliding Cards and the Mystery of the Unclickable Element. What was that all about?

Okay, so my talk had a bit of a spongebob squarepants theme because I'm a little bit childish, and I also wanted to entertain a little bit because I've been some conferences and books are pretty dry. I wanted to have a bit of a theme because I had an afternoon talk. I wanted bright colors to keep everyone awake. So I thought, what's one way of talking about sleeps that's a little bit more interesting, less dry? And I thought, okay, I'll create my own TV episodes called Mishmac Sleep Rants instead of SpongeBob SquarePants. And I just thought I'd talk about four examples of where I found it hard to not use sleeps. So the Invasion of the Upward Sliding Cards was just a story of how we had animations put in our. In our screen cards. And the problem I had was I couldn't click on the elements while the card was moving. Had a bit of a slow upward slide to it as it appeared on the page. So I asked the developers if they could help me in that first instance. This was a few years ago when I really didn't. I didn't know how to negotiate with animations, and they just added some attributes for me to the card to let me know when the card had stopped animating, which was fantastic. So I was able to use that in every single screen. We have thousands, I don't know, probably got 30,000 screens in our ERP. So. So using this particular weight for the animation to be over in the sliding card could be applied to all the screens. So that was good. And did you want to know about some of the other.

Yeah, that'd be great. The mystery of the unclickable element.

Okay, so the unclickable element, basically there's this thing that you often get when you go to click on something and Selenium dies and gives you this, an exception that says element not clickable at point, other element receive the click. So you're just sort of like, oh, gosh, why didn't you just click on the one I wanted? Obviously, I found most of the time when we get that, we're trying to click on something where an overlaying element hasn't quite left the party. So when you go to click on another element, it's really. It really is indeed not clickable. So what I found was that what really helped stabilize a lot of our tests was that we would actually add a wait for something to be invisible or something to be stale. So in this particular case, with the dialogue that was still overlaying my element that I wanted to click on, I just waited for the particular window to disappear or to be invisible. And it was just amazing. So within a very. Rather than put in a one second sleep, I just had to wait. And often it would just be 200, 300 milliseconds to wait. A fluent wait to wait for that to be. For that to be gone. And then I could click on my element. So it was not a mystery anymore.

I like the name of this one. The Misery and Other Utter Loathing of Evil Expanding charts.

Yeah. When the guys built this workspace full of widgets using SVG scalable vector graphics, what I found was when the widgets with all of the SVG moving parts appeared on the page, they were just moving, they were expanding, they were growing. There seemed to be animations all over the place. And I couldn't actually click on a bar graph when I wanted to. I had to actually put in a sleep. And I suppose the. I told the story, and I honestly told everyone at the conference when I gave the story that I actually did forget for a year to take the sleep out.

And.

And then I was going. I think I was going through something that had regressed and I just, I thought, oh my goodness, it's still there. I haven't solved this problem, you idiot. So I decided to dig a little deeper and I actually wrote some code where I wanted to just output the class attributes of this particular bar or bar chart. That was all the different bars that were moving and growing as they loaded on the page, I wanted to output to the console just over and over again while it was expanding, what was actually changing in the class. And because I couldn't actually see anything identifiable in the dom. And then when I looked at the console after I ran it, I could actually see the particular class attribute called expanded. Yes. So there was an attribute. Out of nowhere it got expanded. And I was able to then just wait for my bar elements or the widgets with the specific chart types to wait for them all to be expanded. And then I took the sleep out and I was happy and no longer embarrassed.

I think the last one was the terminal Sleep Fest Mutiny.

Yeah, the Sleep Fest Mutiny. It was a mutiny because I always said to my boss, you know, don't use sleeps when you get into trouble.

I was a bit of a hard taskmaster when it comes to sleep. And I went away and I came back and I thought, I don't know, he looks guilty. And I had a look at the code, at their code. They write a lot of scripts for business functionality, smoke tests and the like. Yeah. So I basically, I went away and my boss had put sleeps, and what he was doing was he's writing a test where a UNIX terminal appeared and he wanted to enter some commands in and then close the UNIX terminal again. And he had sleeps in between each line of code. And so I just said, let's look at the dom. And it really wasn't that hard. They were just div elements, I think, because my boss is also a manager and he wears very many hats. He said, I'm going to use sleeps because I just want to get this done.

And then I said, no, no, no, no. And we had a look and basically what we just had to wait for was every time there was a UNIX command, there was a prompt and it just contained some text and we just put some weights in for that. So every time he was waiting for a command prompt ready, he just had to wait for some text to appear, a fluent weight for text to be present. So the solution was quite, quite easy. And then I think I reduced the test by three seconds, which doesn't sound like a lot, but over time, if we can reduce all those needless fixed weights, then we can get the test suite, and the test suite already runs in parallel, but we just want to make sure that we can get it done as quickly as possible.

Okay, Michelle, before we go, is there one piece of actual advice you can give someone to improve their automation testing efforts? Let us know the best way to find or contact you for me even.

Though we use Selenium and we have our own framework now, which works really well, I still continue as a, I now call myself a test automation or engineer. I still, I look at other products and I'm, I've been, for example I've been playing with Catalon. It's, it's a, it's a nice looking product. It's quite, it's quite. So far I'm finding it quite to use and I've also been playing around of course with the new Selenium ide and I'm always at the moment I'm looking at implementing Docker. So I think as, as a test, we never stop learning. We keep so many products out there, we should at least give each one of them a bit of a proof and concept if we can give them a bit of a go and always continually look at whether the solution we have is the best fit for our company. So yeah, that's my advice. Just to never stop, just to be content. But to keep looking and listen to your talks and find out what's out there, not only what you're using. Anyone can contact me through Twitter. I Shmakers is my Twitter handle. One girl actually has been kept in contact with me since the conference, which is really good. She had some questions and yeah, so I'm easily found on Twitter.

Thank you Michelle for your Automation awesomeness. The links to everything of value we covered in this episode and head on over to testtalks.com 236 and while you're there, click on that. Sign up for a free trial link under the exclusive Sponsor section to learn all about source Labs, awesome products and services. And while you're there, why not also click on the Register for the 2019 Automation Guild. Automation Guild is dedicated to helping you get started for the new year so you can stay in confidence. I'm ready for any type of test automation effort. So that's it for this episode of Test Talks. I'm Joe and my mission is to 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 awesomeness.