How Can We Speed Up Our Work during Web Application Test Automation?

The full transcript

Harshit Paul (Director of Product Marketing, LambdaTest) - Hello everyone! Welcome to another episode of the LambdaTest XP Series. Through XP Series, we dive into the world of insights and innovation, featuring renowned industry experts and business leaders in the testing and QA ecosystem.

I'm Harshit Paul, Director of Product Marketing at LambdaTest, and I'll be your host for today's episode on how to speed up your web application testing workflows. But before we get started, let me introduce you to our guest on the show, Alex Pshe, an experienced Software Developer in Test (SDET) at the JetBrains Aqua team.

Hey Alex, welcome to the XP Series. How about you let our listeners know more about yourself and share your expertise?

Alex Pshe (SDET, JetBrains Aqua) - Yeah, thank you so much for having me today. Yes, my name is Alex, and I am a part of the JetBrains Aqua team. So it is an idea for test automation. And today I would like to tell you a little bit more about Aqua from my QA perspective.

So I suggest starting with a very short introduction. If you don't have a lot of time and you want to get the main insights. I'm going to show you it right now. So, let me share my screen. As I already told you, JetBrains Aqua is a powerful IDE full test automation.

Actually when I'm thinking about IDE and the value of IDE in QA automation engineer life, so the first question I would like to ask myself is how the IDE can help me as a QA automation engineer.

So to answer this question, the next question I wanted to ask myself is, what is my goal as a QA automation engineer? And I think all of you already know that our main goal is to write tests as fast as possible because, yes, right now, this speed of change is just so insane.

So we should be on the same level with our delivery processes, but at the same time, of course, we don't want to sacrifice the test quality. And it's quite difficult to achieve these two metrics at the same time.

So why JetBrains Aqua, and why do I want to share this information with you? Let's try just to check what we can do in 40 seconds as QA automation engineers who try to automate just typical UI auto-test.

So for example, let's imagine we are working here on this bank application, and we're trying to test this registration form. So normally, we try to find the selectors in the HTML source and, after that add these selectors as the elements to our class. So it's just a normal process. All this is very predictable. We know how to find these selectors. We know how to add it to our source element.

And yeah, we just spend our time adding all these elements. Of course, sometimes we can make some mistakes. That's normal. That's a human factor. And during these 40 seconds, you just saw we added only one web element. Okay, this is reality, nothing special.

So one locator in 40 seconds. Sounds okay, but could it be better? Actually, yes. What took our time? The first, we were searching for locators. And, of course, it takes our time, at least, to open through inspect our HTML source after that to find our element, to prepare the correct locator because we have a lot of different ways how to choose our locator to make it the most stable and also to make it very predictable for our future.

Also, we can take some time to switch between apps because, for example, we have our browser, and we're trying to find our locator there at the same time, we have our ID, and we're trying to add our elements with our locator. And of course, we have a lot of human beings factors here, like typos and also errors. And that's normal. We have this risk. We should always consider it.

So let's try to see what we can do with Aqua here. Absolutely the same bank application. But in these 40 seconds, we will try to add by clicking our special button here, selecting an element on the page and trying to add this element by a specific shortcut. So yeah, we will add all possible fields that we need to test and also the final button.

And the final bottle to register our user. Yeah, so as you can see, we just added the whole page in 40 seconds. The same 40 seconds, but with different results. And what we did do exactly, we picked the element. After that, we use special shortcuts to add this element directly to our page object class, and after that, we just repeat these actions about 12 times.

What else? Yeah, if you are a QA automation beginner, of course, we got you. And we have a very cool wizard, which helps us to generate projects in several clicks. As you can see we have the list of all possibly, the most famous frameworks, like UI frameworks, for example, Selenium, Selenide, Cypress, and Playwright.

So in several clicks, you can add your new project from scratch here without any preparation. So if you just joined the project with UI tests, we also got you. First of all, you can find a broken locator. Here, for example, you can see that the second locator is highlighted because actually it is broken and we cannot find the corresponding element on our web page.

Also, you can see a number of matches. It means how many matches this locator has on this web page. For example, the first locator has 15, the second zero, and the last one matches. Also, you can navigate to the web elements. You can click on this special icon, and after that, you can navigate directly to the corresponding web element.

Moreover, you can explore all available locators if you just start typing your keyword. For example, it can be an input keyword. Here you can see all locators and all web elements that are available on the current web page with such substring input. And if you want to write API tests, also really fast, we also got you.

So we have a special HTTP client, and you can use it to write API tests really fast and furious. So, for example, you can see it's just the basic HTTP requests, but we also support parameterization. We support this kind of CI/CD execution. So actually, it's the analog of Postman, but you can reuse it inside IDE, and also you can inherit all benefits from hosting these files inside your version control system.

So it means you will see git history, you can maintain it, and it's really convenient for QA automation engineers. So, we have data generation, we have response extraction, parameterization, and everything you need to start your API tests. And yes, as I just mentioned, it's even included in the CI/CD pipeline.

So you can run it in one line and yeah, so that's pretty, pretty convenient. And also, if you want to connect manual and automated cases, we got you. So if you want to try JetBrains Aqua right now, you can download it through a QR code. And I'm going to share with you real examples of test automation inside IDE.

So, first of all, let's look into JetBrains Aqua. So actually, it's the same IDE as all our JetBrains IDE, which are based on the IntelliJ IDEA platform. And here, you can see different widgets. So it's actually pretty simple. We have a terminal, we have Git, and everything is the same in our IntelliJ-based platforms.

So we also have here a lot of QA specific features. For example, as I already mentioned, we can create a new project. If you want to start your test automation from scratch, you can choose any UI framework you prefer. So, for example, we can do it with Playwright, and after that, you can choose different parameters like node interpreter and the location, name everything, and create your first project.

So yeah, you will see here the process of generation. So yeah, let's go while, yes, it will finish to another part. So also what we can see here, for example, if you want to create your first UI test. Let's go into our project. So we have special functionality. We have created a new one, and here you can choose the Selenium page object.

After that, what you need to do is to choose your file name and URL, like your website language, Java, Kotlin, or anything you prefer, and also the UI framework. So here I have my framework in Java. So let's, for example, create our test bridge and let it be a local host web page and framework Selenide.

So after that I can click OK and add this element to my virtual control system. Here as you can see, the page object was generated with our name, and also, we have this page URL which was automatically opened here directly in this special window. So this special window we call Web Inspector.

Actually, it's an embedded browser. So it means you have access here to your webpage. Right now, I just opened this local host, and as you can see, I have a local TeamCity server here. But also you can choose any and our website you want. For example, we also have our special test page for training purposes. And here is what we can do after that.

For example, if I want to test this page, I should somehow interact with web elements. So we have special functionality for it. You can see right now I'm trying to highlight this button and select an element on the page, you can click on it, and after that, there is a kind of special mode where you can choose different web elements on the page.

For example, test page, after I click on it, I can see a special locator here. What is important about this locator? So as you can assume, we have a special hidden logic here in how we try to suggest your locator. So the point is that you know, locators are really important in test automation because they can have a big influence on our test stability.

That's why we're trying to suggest to you the best locator, which is possible based on different best practices. For example using data test attributes and stable science, which we can rely on. So here, as you can see, Web Inspector suggested we use the data test attribute, but we can also see special information here. For example, how many matches this locator has on this webpage.

So only one match means it's a unique locator. Okay, also, we have 17 variants. What does it mean? We can click on it. We can see that also there are several variants to find this unique locator. So for example, using only tag or tag plus class or also class names. So a lot of different ways. And all of them are CSS locators. But also we have the possibility to choose an Xpath way to add our parameters.

In this case, you can see we have 18 variants of Xpath. So actually, yes, based on this information, you can choose the way you prefer to pick up this element. So, for example, I prefer CSS. What after that? Also, you can see here a special window, and we can assume that this Is actually an HTML source and that's true. So we have here a hierarchical structure of different tags on our page.

And also in these structures, we're trying to highlight the important attributes. For example, here, in this case, we can see that this web element has a data test. What we can do after. So our goal is to add our locator to the code. We can do it in different ways. For example, we can click an element to code or use also shortcut. Let's try to do it.

So I just click on add an element to code, and you can see that it was automatically added to my source code. Also, you can see that it was added according using this UI framework, so Selenide element. Why? When we just created our new page object class, we chose this Selenide framework. So if you change your mind, you can always click on Selenide and choose another UI framework.

So, okay, what we can also do, if for example, we have some really specific UI framework, which we don't support yet in Aqua, you can just click on copy, in this case, you can copy your locator. Also, if you want to add an element to code, by some specific parameter, for example, text or data attribute or tag with classes or CSS. So you can choose this special option here. Okay.

Also you can see what we tried to suggest to you the best name for your web element based on your locator. Also, here we have several hour functionalities like refreshing structure, automatic refreshing structure, and settings. What we can see here in our code. In our code, after adding this element, we can see this special icon which actually shows us the number of matches for this locator on our web page.

So let's, for example, try to change our web page and come back to the previous page with Team City. And you can see the match; the number of matches changed to zero because there are no web elements that have this type of locator. So yeah, it means, for example, if you just join your team and you open your test automation project and some of the classes can have thousands of different locators, you can always check very fast, but all of them are actual and not broken.

Okay, what else we can do here? We can try, for example, to type different substrings here, and when you type something, we have this beautiful feature of auto-completion. So yeah, it actually means that the IDE can suggest you how to write your locators. For example, I want to see all elements with data test attributes, and I can see that its title is also, we have children here, and I can input a lot of different locators.

And also, some of them are highlighted as multiple meshes. So it means that this locator is not unique. And yeah, after that, you can just choose it, and that's okay. So also we can click on this, and yeah, the good thing is that we will directly navigate to the corresponding web element on the webpage and why it can be helpful for us.

As I just said, if you join a big project and for you it can be really difficult to kind of debug the test state, you can use this feature and directly navigate from source code from different locators to web elements. Yes, and of course, it's the way to speed up your work. What else? Let's see which functionalities here we have.

For example, we also have all features from browser like go back, go forward, also refreshing the current browser webpage and also clearing browser cookies, enabling, disabling pop-up windows mode open developers tools and etc. So, also what we can do with JetBrains Aqua, if we will move a little bit to our API part, I will show you some examples.

So for example, with TeamCity, let's come back to TeamCity page. Yeah, with TeamCity, we have API and we have UI. So for example, as for UI, we just see how we can really fast to add all elements, but what about API? So with API, we have very interesting structure which called HTTP client and requests.

So I have special folder here for keeping all HTTP requests. I can edit with special new and here HTTP request. After that I should prepare some names, let it be test. Also adding to our virtual control system. And you can see that it looks exactly like just a normal file, nothing special. Okay, but we have here special functionality.

First of all, this plus, which allow us to add new request. We can check which request we prefer, get post or some other requests. So let it be get request. After that, It has actually pretty simple structure. So we have our URL. We have also our different headers. And after that we can add body if we need body. So the idea is pretty simple.

You can use this HTTP request directly from IDE, but by clicking on run. And you can get the same results as if you just send your request with Hurl or Postman. I am going to show you my real examples, these examples for testing TeamCity. And what I have here, first of all, I generated random data with such a special structure, it's just HTTP client syntaxes, so you can use it like this, alphabetic and the length is 10.

After that, I'm trying to generate an autification token by using this get request. And also I provided a here header. And after that, this, yeah, I just, what I do, I set up the response from this request. As you understand, this response will contain my token. And I've add this token as a global variable here to this variable token. Why?

Because I'm going to use it further. And after that, what I'm going to do, I'm going to create project. So here I use a post request, of course, for project creation. I provide also different headers. And here this header is important because you remember we just received before token from previous request and I'm going to use it here as a parameter.

So that's why I use these two braces here so it's parameter and after I provide my body. Body we've also generated random values from the first part. So after that, I also created build configuration in the same way and I run build in team city based on also previous information and I check build status.

So finally, I'm going to check build status by get request and as a response to this request, I expect some state and I'm asserting here that response status is not So, yeah, you can see that actually I have the whole API test here. And for this purposes, it can be fully automated. So it means that actually I don't need to write code.

I can just use a real request as a core request here, and also inherit the whole possibilities of version control system because I use my API tests as a code, but actually it's not code. Yeah, and that's why these tools are so powerful because if you don't have a lot of time to set up from scratch your API framework, you can just create new file here in your folder and add all these requests.

And also it can be used as API test documentation when you, for example, did your manual test cases. And after that you want to keep all these sequences of requests somewhere and you can just create a new file and add everything here. And also we support the transformation from the Quirrel to this type of request.

So if you have Quirrel, you can just copy it and paste here, it will be automatically generated in this syntaxes, which is also quite convenient for transportation. So it was about API part. And as for the last but not least part a test management system.

Actually, I know that test management systems and in general, the question how to keep your code if you have manual test cases and at the same time, automatic test cases, it's really difficult and we have a lot of different custom solutions, but what we can suggest here in Aqua. And Aqua, we have our test management system also inside IDE.

So how it looks, for example, let's imagine that I'm going to create new test cases. I can create for it special folder also. It can be just test cases folder. And here in this test cases folder, I can create a test suite. You can see you have several options here, test suite and test run.

So for example, let's create a test suite. I will name it as a smoke and also add to my virtual control system. And here I can say, for example, it's first case and some steps, step one, step two, step three. But the point is that it doesn't have any like, one second any difficult structure, I mean, you can use it as a checklist, also as a test cases, it's up to you.

So, and in reality, it is just markdown file. So actually, you can write your test cases in any way you prefer, but the thing is that we support here different IDs. So actually, we're trying to track your test cases. And after that, when you just write your first test case, you can also add your first test run. For example, you have release soon and you want to do your regression testing and you can add new run, for example, run one.

And after that, we will suggest you to add your test cases to your run. So actually right now we have only one test case, but if you create more, you will have the whole list of test cases right here and you can choose all of them which you need. And after that, just click OK. And also we suggest you to add it to your virtual control system. And after that, here you can mark your test case with the status.

So also you can prepare the list of statuses you want. For example, it can be passed, failed, skipped, anything. And yeah, so you will keep your test run result like this with this test report. And also in case you want to see the overview of test management system, you can find a TMS window here and you can see the overview.

So like you have all your cases right here as a list. Also, you see your preview. You can edit it, you can view it in separate tab, and also you can see the list of your test trends with highlighted statuses. So the thing is that, first of all, we keep our test status and test documentation inside IDE and also inside our repository.

So it means we will inherit all benefits from virtual control system and you will always see the history of changes. You will also navigate to previous runs. You can analyze it. You can analyze difference between. And it's really cool because we often have this problem in QA world that sometimes QA keep all these documents about test runs and test documentation in different places, in Google Docs, in some test management systems, and it's difficult to track it together.

So here, because it's inside repository, you don't have such problem. But also another problem is how to connect manual and automated test cases. So for example, here we have our first case, and actually we can add this parameter, this IDE to our automated tests. So for example, I just created as a QA manual with first test case and after that, as a QA automation engineer, I want to automate it.

In this case, we can try to link manual and automated test case with annotation. It can be any custom annotation you prefer, but also you can use existing one. For example, I'm going to use annotation from Azure. So here I will provide this unique identifier from our test case with C1.

So, yeah, and after that also you can navigate from this ID to your test case. And that's how you can implement it here as an automated case and link your manual and automated one. So finally, actually, for example, in our team, in JetBrains Aqua, we use this TMS system and finally.

We have two runs. So the first run is a run with only manual cases. And the second run is the run with also a test automation. And after that, we merge these two run into one and we have these report, in general, with automation results and also manual test cases result. So yeah, that's how you can use it.

Harshit Paul (Director of Product Marketing, LambdaTest) - I believe a lot of times people, you know, it's been an old debate whether automation would be killing manual or not. But I guess the way you summed it merging the two both the halves at the same time with manual and automation is a perfect way to sum up the entire capabilities. And I think from my end, it looks pretty impressive the way we have seen it through the demo so far.

Alex Pshe (SDET, JetBrains Aqua) - Yeah, and also the thing is that, for example, in our team we have this process, but in any time, every test case should have only one source of proof. So, for example, if it's just only manual test case, in this case, the source of proof is our TMS, so it means this markdown file. But if we automated our test.

So in this case, the source of truth just migrated to the automated one. And it means that we will cut this case from our test manual test plan. And that's how we support this like invariant that automated test case should be self-documented. And that's why always we generate our report, our test automation, our execution, after execution. And, yeah, we can get these insights in general of two merge reports.

So yes, it's quite convenient and help also helps us to avoid this double work when you try to support new changes in test automation and at the same, at the same time in manual test cases.

Harshit Paul (Director of Product Marketing, LambdaTest) - Yeah, I have to double down on that. You know, as QAs, time is always of the essence, right? And everything that we have seen so far, right from the part where we are inspecting UI elements and to the part where we are generating APIs and now we are merging automation tests, I have to say this, everything seems pretty well planned as a part of the complete ID kit, which we are looking into at this point of time. So everything has been very well-placed. That's the feedback from my end. But yes, I guess the viewers would be feeling the same way as well.

Alex Pshe (SDET, JetBrains Aqua) - Yeah, so actually that's all from my side what I would wanted to show you. So yeah, I'm ready to hear your questions to answer them.

Harshit Paul (Director of Product Marketing, LambdaTest) - All right. So I did have a question while we were doing this. I'll just quickly put that away. And how does AQUA streamline the process of automatically adding locators to test code?

Alex Pshe (SDET, JetBrains Aqua) - Yes, very good question. Thank you. So the point is that, of course, as you just saw, we have Web Inspector and we have access to the web page. So it means we can parse the DOM file, which contains this hierarchical data from HTML.

And based on this data, we can analyze WebElement and also we have our like a hidden algorithm, how to find the best locator based on different best practices. So we just consider all this information together and after that we prepare the best locator. Yes, and we just provide it in a locator evaluator for QA engineer.

Harshit Paul (Director of Product Marketing, LambdaTest) - Got it! Well, that helps! One more question - does Aqua provide any unique capabilities for page object generation?

Alex Pshe (SDET, JetBrains Aqua) - Yes, as I showed you, we have a special feature like create new Selenium page object element. And actually, yes, it provides different functionalities like automatic adding web elements to the page. But also we will try to improve it. We have some great ideas how to speed up work. So in future, I think we will have even more different functionalities to add this page object to your code.

Harshit Paul (Director of Product Marketing, LambdaTest) - Got it that helps and you know just this is a little off topic not exactly off topic but a little off the context from the IDE but I see a lot of you know reddit subreddits and a lot of these discussions which happen around what is your preferred locator strategy right so that that's more of that's more something I would like to ask you do you have any preferred go to locator that you usually take in consideration.

Alex Pshe (SDET, JetBrains Aqua) - Yes, of course, personally, I have my own strategy how I choose locators. As I also mentioned, the main thing, the main problem we usually faced with as a QA engineers in UI testing is that tests are really unstable and also way quite slow. So the problem with instability we can solve by using good practices in locator preparation. So what can it be?

First of all, we should follow this invariant that if we don't have any test data attributes, our page means we don't have web element. Because otherwise, when we try to use some classes or IDs, the point is that it can change anytime. And if we don't have any like commitment with our developers that we never change, never change data test attributes or otherwise, yes, we will have a lot of problems with stability.

So my personal advice here is that, yeah, the best practices using data test attributes and also important if we have the element collection. So it means we have different elements which are like actually the same from the business logic. So in this case, all of them should also have the same data test attributes. In this case, we can find them as a data collection.

And yeah, I would say that it's the best practice, but of course I can understand that it's not always achievable. And sometimes we face reality but we can try to follow these best practices.

Harshit Paul (Director of Product Marketing, LambdaTest) - Thank you for that. And while the entire demo was giving us a good demonstration of how feature rich Aqua's capabilities are, we are at the start of this new year. And I can't help but anticipate what's in the store for Aqua. So what are the plans for expanding Aqua's capabilities in the near future?

Alex Pshe (SDET, JetBrains Aqua) - Yeah, so of course, we will try to find new patterns in QA engineer's routine to speed up it. And it's our main goal to help QA engineers to implement the best version of their test automation. And also we have a goal to help beginners to start their path in test automation by following different practices inside IDE.

So we're trying to prepare such functionality which will kind of lead you to follow these best practices. And yeah, of course, also we will try to predict the future. I mean, like we will try to help you to implement some kind of different every six from your webpage. And for example, generate test cases and do some work which can speed up also test routine. So I think that's the main direction. Yeah.

Harshit Paul (Director of Product Marketing, LambdaTest) - All right, and with that, I have no further questions. Thank you so much, Alex, for this enlightening talk. That wraps up our today's episode of XP Series, and definitely worth deep-diving into Aqua with a lot of capabilities at hand.

And as I said earlier as well, as I emphasized, every second saved is a second earned, and every second counts when it comes to QA's bandwidth, especially in the age of agile, where there's always something or new shipping on a weekly basis, bi-weekly basis, and so on.

So a lot of things that people need to optimize in their testing workflows. And definitely we have had a great, great demonstration from you all. And so thank you so much for taking time out of your busy schedule and having this informative session with us.

Alex Pshe (SDET, JetBrains Aqua) - Thank you so much. Thank you. And I will just mention that we also have our issue tracker. So you are always welcome to create any like feature suggestions or maybe any bug report if you find someone. So yeah, feel free. And we are always waiting for new insights from QA engineers.

Harshit Paul (Director of Product Marketing, LambdaTest) - And that is Adios. Thanks, everyone, for joining us today. And thank you so much. Stay tuned for more episodes from the XP Series, where we continue to bring you cutting-edge topics in software testing. Until next time, happy testing.