Less waiting, More Testing with Geetha Achutuni

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Geetha all about Less waiting, more testing 10 tips to reduce Test Execution times. If you don't know, Geeta is a seasoned software professional passionate about automated testing and delivering high quality software. She has a proven track record of designing and implementing robust testing solutions that have helped organizations achieve their software delivery goals. In addition to Geeta's expertise in automation testing, she has skills in building accelerators that streamline software delivery process and improving efficiency. Bunch of topics we might delve into as well. Also, as you'll hear in this interview, she's very passionate about technology which extends beyond the workplace. So she enjoys sharing her knowledge through writing white papers and presenting at industry conferences and sharing her awesomeness on podcasts like this. So Geeta believes in staying ahead of the curve and continuing learning and growing professionally. Really excited to have her on the show today. You don't want to miss it. Check it out.

This episode of the Test Guild Automation Podcast is sponsored by the Test Guild. Test Guild offers offers amazing partnership plans that cater to your brand awareness, lead generation and thought leadership goals. Get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us, from boosted event attendance to impressive roi. Visit our website and let's talk about how Test Guild can take your brand to the next level. Head on over to test guild.info and let's talk.

Welcome to the Guild.

Thanks Joe. Thanks for this opportunity and that was very nice introduction. Thank you.

Absolutely. So I usually botch the introduction. So is there anything that I missed in your bio that you want the Guild to know more about?

Yeah, nothing much. Just one specific thing maybe. So I have more than two decades of experience, mostly into test automation. So I started my career with Windrunner. Later it was oh yay, nice.

Same here. Cool.

Then it was utp, now uft. So all these things.

Nice. So what was it like? A lot of times when people learn a tool and the tool goes away, they sometimes just their career descends. But it seems like yours continued. So how did you make that transition from Winrana, QTP and probably I assume selenium.

Yeah. The bottom line is it uses the Same programming language. So I was passionate about programming, so I picked all other tools that came my way. Yes, it helped me.

So what are you currently using?

Selenium. Selenium with Java Python.

Nice.

Node js. So all the leading tools.

Very nice. So you made a good point already in that you Learned programming using WinRunner and it's the same concept, it's just slightly different syntax. It sounds like. So you're able to pick up. It sounds like Java, Python and other languages. Yes, very nice. So I think the main topic you wanted to talk about was 10 tips to reduce test execution time. Always curious to know why you picked this topic.

So because. So it is evident these days that all the products and applications are using agile methodologies. So where they have to make frequent releases so to keep the user expectations and then have a quality product for the users. So for this. So all the organizations have adopted test automation as a platform to improve their consistency in the delivery and then have the quality also in place and have test coverage also in place. So keeping all these in mind. So I thought like we have to accelerate the test execution. So basically scripting will take its own time. So given the features that the developers are building and then the testers have to write the code for that, but there is a scope to accelerate the test execution. So that is what I have just explored and we have come up with few proven ways so where we can say that it'll surely help in accelerating the test execution.

All right, so let's dive into those proven ways I guess. What's our number one? The number one tip?

Yeah, sure. So to start with, the first one is the core part of it. So where it all talks about having a reliable and efficient way to identify and interact with the elements on the page. Sahanal about the locator strategy that I'm talking about. So here what I wanted to share is that the teams have to have a unique attribute. So what we have done in our projects is that we have spoken to the development team and then educated them on having the automation and then they were open to add a data auto tag which can be used by the automation teams to identify the element uniquely rather than having the expanse which might take its own time based on the browser that we are interacting with. So this one would help. And then we should always use standard locators like id, name, css, link text and on we should obviously avoid using link text. Rather we can say partial link text or instead of saying equals, we have to say contains. So there are small strategies which would obviously help and reduce the time that is taking to identify the object. And also there can be a flakiness due to these things. So we need to avoid all these things as a whole when we are talking about the locator strategy.

Absolutely. So how difficult was it to convince your developers to do an auto tag? I think you work for a pretty big company. Like every field has an auto tag.

Not all of them. So we used to explore the application, come up with the test cases that are to be automated, then picked few fields which are to be used for the automation purpose. Then we raised a ticket, and then developers used to create auto tags for only those specific elements. Not every other element needs an auto tag.

Right, okay, that's a good point. So you're not overburden them, it's just that. Yes, as you see, you need them, then you open a ticket. So it's not just doing auto tags for the sake of doing auto tags.

Yes.

So do you have any examples of how it was before an auto tag and then after the auto tag, how it's approved? Was there anything that was almost unautomatable without the auto tag?

Without the auto tag? They were. There were few things, like, based on the technology, now people are using Angular and react, where the IDs also will change based on the sessions that the user is having. So we can reduce the number of failures if we are using this data. Auto tags.

Very cool. All right, so what's number one? I'm blown away by number one. What's number two?

Yeah, so number two. Moving on. So this talks about the smart weights that we have to use. So in most of the cases, or the cases where. Which are not consistent across the applications, the developers are bound to use thread sleep. So which will actually wait indefinitely, irrespective of the element is available or not. So usually avoid using thread sleep. That is the first one. And then we always force the automated testers to have explicit weight with the expected conditions. So this will help them to see whether the element is available or enabled or intractable. All these things. So before we actually interact with the elements. And then we also have implicit wait, which is a strong one. So which will have a timeout also. So the script would wait until the timeout is reached. But this will be of great help for all the basic locators.

So it's a function that you wrote that everyone utilizes for the weight, or is it built in somehow when they use. I don't know. How does it work?

Yeah. So implicit weight, as I told It's a built in function that comes with selenium, but the explicit weight with the expected conditions. So based on the element that we are interacting, we would say if it is a text box, then we can say it is enabled. If it is a button, we can say if it is enabled or interactable or if it is available, if it is visible. So there are many other parameters that we can check based on this expected condition. So based on the element that we are interacting, we have multiple methods already built into the accelerator, so we can use the appropriate one based on the element that we are interacting.

So how big is your team? Forget to ask that. That you're working with your automation team.

So they should have some basic knowledge on the automation for sure and scripting. So that will help them to pick the tool and the features that are available and then write optimized code.

But how do you know that they use, do you review other people's automation tests before they check it in to make sure they're using the smart way?

Yes. So we have the code repository. So before they commit the code to the code repository, it'll go through a series of code reviews. So where we would help them to automate or have an alternative way of implementation.

Awesome.

To improve the code.

Yeah, sounds good. Cool. All right. All right, so I definitely agree with the first two that probably would solve, I would think 50% of issues with automation or 60 always has to do with either weights or bad element locators. So I'm curious to know about the other eight because I know about the first two. So what's the third one?

Yeah, so third one is to optimize your code. So here I wanted to share that we need to use proper data structures. There are many data structures that are available when we talk about any programming language like Java, Python or any other language language. So that is the main thing. Instead of using the basic data structures like arrays or normal variables, we have to pick lists or maps or dictionaries, which are very advanced. And then we need to ensure that we make minimum HTTP calls or DB calls. So once we make a DB call, there should be an appropriate code where it pulls the data from the database and stores into dictionaries or data sets. So we should minimize the number of requests there, the HTTP request and the DB calls to make sure that we are minimizing the test execution time. And also we have seen a few cases where testers tend to ignore the ELSE conditions for every IF condition. So I have mandated that we need to have an ELSE Condition for every if so that we can capture the failure at the same step instead of moving to further steps and failing at a different point, which is not appropriate. So I have mandated to have else condition and also there should be a break condition for all the loops. So these are the two best practices or the guidelines that I have put across for my team.

Nice. So this seems a little more advanced. So I guess do you have to train them then or like this must be more difficult to say. Well, this is. I wouldn't use this data structure. I would use this other data structure to solve this.

Yeah. So during the code review, so we usually give them some guidelines or we have coding standards that we have published for, for the teams so that they can pick directly from that. But otherwise these can be shared during the code reviews.

Is there one data structure? You're like, don't use it at all because it's going to slow it down.

Yeah, basically maps.

Okay, cool. All right, so that's three. What's the fourth one?

Yeah, fourth one. This is the recent enhancement. So there is an option to utilize the cache memory provided by the browser itself. So instead of going back to the data server and then fetching the data, we can create cache memory in the browser itself and update them. We can have expiration times for that cache and then we can refresh that for any new updates for the data and then we can directly read from the cache instead of going back to the data database.

All right, can you explain this a little bit more? Because I'm just trying to imagine like. Can you give an example? Like you're storing something in cache of the memory so you're able to access it quicker than actually making a call to the database. Could you give an example of when that would be?

Yes, that becomes a local storage for this script.

Okay.

It's more like a local variable.

Okay. All right. What do you usually use this for? Is there any functions or features?

Yes, there are built in methods that are provided by Selenium itself. So we can create those methods out of those, the built in methods and then directly make calls to the cache memory only.

So I've never heard of this. So what would someone look up for more information? Is this cache memory in Selenium or.

Yes.

Okay. All right, cool. See, I'm learning. I love it. All right, so what's the fifth thing then?

Yes. So fifth one is to avoid creating new browser sessions or launching new browsers for every other scenario. So first thing is that we have to make independent scenarios. First thing and Then for a group of scenarios, we should try to use the same browser. Because while we launch the browser, we have to set many capabilities for the browser. So to avoid using the cookies or clearing all the cache data, all these things. So these things are taking more time than the test execution. This is what we have observed. So what we have done is for a group of 10 to 15 test scripts, we have to go with one single browser session. So this also like closing the browser, launching a new browser, setting the capabilities, erasing the data, all these things can be skipped.

Interesting. Just for some reason I think like the longer you have a browser session open, the more memory it would take and the slow it would get. But it sounds like that's not. So I guess that's trade offs. So how does that work?

Yeah, there are again, that is what this win win situation. So first thing is that we shouldn't use the same browser session for more scripts because the memory would be like used up by all the variables and all. So we can't clear the memory during the runtime. The only way is to kill the browser session. So but that doesn't mean that we have to use new browser for every other script. So we can. We need to group certain test scripts and then have one browser session for those things.

How do you group them then? And that you know, if you start running on a grid, then how do you know? Like do you have to run them in groups or do you have to manage that or are they independent enough?

Yeah, so we use tags first thing. So we use tags for few things. Like if it is an E commerce application, then I can save for all check in scripts or add item to the card scripts. All these things we will group together and we will see that they are not using. There are not crossing more than 15. If they are crossing then we will create a new tag for them, then create a subset of that.

That sounds like it takes a lot of time to do so in every code review. Then you have to keep track of. All right, here's a group of 15. We need a new group of 15. We need to create a new tag.

Not really because amount of scripts that we are segregating is at the feature level. The feature level will be to a minimum. So where we will be picking sections also like only billing address only those things can have at least 10 scripts. So we will be drilling down those features also to have a minimum set of scenarios.

Cool. Okay, so what's number six then?

Yeah, moving on. So six is about using APIs instead of UI interactions? Yes. So here we need not have the UI interactions for every other script, something like login or. As I said, when we are working with E Commerce application, we can have items added to the cart using an API itself. That doesn't mean that we are avoiding UI interactions altogether. But we can pick few scripts which will go through the UI interactions. But we can replace these steps in other scenarios where that is not mandatory. Like if you are working on checkout scripts, then the adding items to the cart is a prerequisite. So we can have APIs for these kind of scripts and move on to the UI interactions for the actual scenario that we are trying to check.

Okay, cool. What are you using for APIs? A rest assured or something.

Rest assured, but in Selenium we can make a call directly so using the rest assured libraries itself. So we will get the response and then the items will be added to the cart itself based on the parameters that we are passing. Nice.

So. So you know I've seen companies that use UI tests to seed thing with users and if they use an API it would've been much easier. So it sounds like you seed all the data with APIs before you have the actual UI piece kick off.

Yes.

Nice. Any tips around that that you've seen that people get into trouble or is it pretty easy to make the APIs do it and then interact with the UI pieces of it?

It is easy. It's only thing is that the response that we are getting from the API should be handled appropriately instead of we shouldn't skip anything from the response. So we have to validate whether the actual item is added to the cart or not. So going to the product details page and having a small verification around that and then move to the checkout, the small verifications based on the response is mandatory.

Nice. So I just assume you have like a function that commonly things that you just call and it has the APIs already available to do all of.

Yes.

All right, nice.

Yes. So we have integrated both functional and API.

Okay.

So it takes care of everything. So end to end flow where we can skip few of the UI interactions.

Very nice. Love it. All right. Number seven.

Yeah, so this is also an interesting one. So we have found a way where we can block the images and pop ups which are not consistent across the application. So if for example again if you're talking about an E Commerce application, so there will be whole lot of images that will be loading when we are going for search scenarios or navigating through the menus to check the products and all. So the loading of the images was itself taking more time. So what we explored is we can block the images from loading because anyway we are not validating the actual image. It's only the properties of the product are validated. When we are picking or selecting the product, we will go to the product detail page and verify the product details across the other pages, but we are not actually validating the image. So here there is a capability for all the browsers now where we can block the images. So it'll say it'll save a whole lot of time.

I love that. How about pop ups?

Yeah, pop ups, we work with the development team there. So something like promos, which are not consistent, we can't expect them to happen or we can't predict them and then handle them. So instead of waiting to see whether a pop up is there or not, so. So we have asked them to create a URL parameter so with which all pop ups will be disabled. Wow.

Very cool. I like that.

Yeah, so this was actually implemented in few applications.

All right, so there is a way that people are dealing with pop ups. They can talk to the developers and have like a special URL that says like, I don't know, no pop ups or something.

No pop ups.

Okay.

Yes.

Oh, that's very cool. So I'm just thinking testers, when they hear about blocking images and things, they're like, oh, you're not really testing it. And how do you know if there's going to be performance issues? But do you have separate tests that do maybe visual validation to make sure that visually everything looks correct so you don't have to worry about.

Yes, as I said, it will be useful for search scenarios or the grid scenarios where we'll be Only checking whether 10 items are displayed or not, or 20 items are displayed or not. So there we are not actually validating the images. So these kind of scenarios, we can have these things. But for all other pages, like checkout, billing, all these things, we are having the images. We can't block one or two images.

This is great. I love this tip. Okay, what's number eight?

Yes. So number eight, I think it's being used by most of the project teams, but again it's about enabling the parallel testing teams can use the Docker, which is now very advanced, and then can go with cloud infrastructure tools like browser stack, sauce labs and all for all real device coverage also. So local things I think we have already handled with Docker. So where we are, we were able to spin up 10 machines on a local Laptop only. And we were able to use this parallel execution to quickly check these scenarios. Quickly.

Any tips for that? Because sometimes I know when people try to run in parallel because they have dependencies somehow they didn't know about stats, it doesn't work and they have to do.

Yeah, so if we have to go with parallel testing, first thing is that we have to have independent scenarios only. There shouldn't be any dependency. So though they are covering one actor, two actor or multiple users. Also we should only have independent scenario so that for each of the scenario. Also we have seen that Docker has creating one container and then spinning up that and then executing that one particular script and then spin off.

How do you handle data if it's in parallel? It's on the dockers. Do each doc have their own data instance of like a golden copy of data, or is it just your APIs that are seeding the data?

Yeah, so we have APIs which will pull the data from the data server. There is a data server which is hosted on a different one, but on the same network where Dockers are hosted. So it will pull the data from the database server, but it will be pushed to the Docker containers using the APIs.

Okay, very nice. All right, how about nine?

Yeah, nine. So people tend to ignore, once we have maybe scripted few hundreds of scripts, that people tend to ignore the code which is not relevant at this point. So what we have asked is periodically, after a quarter or so, every quarter we will go back to the scripts and check whether this functionality is actually valid or not. So removing this obsolete code also gives lot of maybe reduction in the time because we have seen that there are few sections which will be removed. And people tend to say if this is there, then continue. Otherwise it'll keeps ignoring, but it'll keeps executing all these steps to see whether this is existing or not. So all these things can be cleaned up from the code to see whether this is relevant for this release or not.

All right, so this one, I could see people being nervous about deleting anything. Deleting tests, deleting code. Like. Yes, how do you know for sure? Okay, it's definitely not being used. I guess you have a. Maybe a backup copy. But like, how do you know for sure it's.

Yeah, it would be there, that's why. So we will not completely delete the code. We will comment that giving a reason or giving a JIRA ticket there, that will be a safe way of doing it.

Absolutely. All right, great. So now we're already to number 10.

Yes, so this is also I think most of the teams are already using it's all about the headless execution. So we need to enable headless execution wherever possible. So now Chrome has given the emulation also where we can see how the application look like in different emulation modes of different devices also so we can cover but not that will not match the real device testing, but we can check how it appears on different things. And all, all these things can be enabled on headless mode which will drastically decrease the execution time.

So do you have like any way of knowing how much time this has saved this list? Like if you didn't follow this list, like how fast does your test run now? I don't know, I guess it depends on your test suite. But what's the normal runtime?

Yes like close to 400 scripts are taking close to 3 hours with 15 parallel execution infrastructure setup.

So without this, how long do you think they would run?

Again? This is with headless, with images getting blocked, with pop ups block. All these things, all these best practices it is taking because these are lengthier scripts. As I said, it is on the E Commerce application. So it has to check starting from the user creation to auto cancellation.

Right. Okay, so like how often do they run then? Is it every time a developer checks in code?

Every day?

Every day.

Every day, Every day. And there is a special job that we have created only for the unit test that will be triggered whenever there is a check in from the development team.

So you know, besides time spent in running, I know a lot of teams spend a lot of time analyzing when something goes wrong. Do you have anything there that helps you figure out when something fails quickly to triage it or figure out why is it, why is it failing without manually going into each one?

And yes, we do that. We do that. There will be separate notifications that will be sent to the slack so that we have automated. So where we will be getting to know like what is actually broken. So based on the release tickets that we have on board, so we will be verifying whether this is an application enhancement or natural failure or a code issue. So based on that we will try it and then fix them.

Okay Geetha, before we go, is there one piece of actual advice you can give to someone to help them with their automation testing efforts? And what's the best way to find or contact you?

I'm on LinkedIn so I'll share my LinkedIn address. People can reach me on LinkedIn.

And do you have one piece of actionable advice you can give to someone to help them with their automation test.

Yeah, so keep learning. You should be very strong at coding because every other version that is getting released have new enhancements, new data structures, new ways of handling the resources, everything. So we should be following the latest trends on the latest releases and then keep learning all of them.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a448 and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or your test tool tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.