Jyothirmayee Pattem

Background by giving a brief introduction of yours. Okay. Hi. Uh, firstly, my name is Jyoti. Jyoti, my part time. I'm currently working as a, and listen with Pro Technologies pro technologies. Our oral 4 years of experience, you know, automated testing, um, along with, uh, in some cases, we perform manual testing as well. So we can consider as how experience, you know, 4 years experience in, uh, manual testing as well Appium and, uh, API testing as well. Uh, I worked on a b d framework and as well, um, POM framework as well. We worked on, um, a data driven testing and a framework. And, um, we we used your CICD pipeline, uh, Jenkins as the CICD pipeline. And, uh, uh, we used Git as a version control tool, and currently, we are working, uh, in a agile model. And my daily daily, uh, daily activities are, firstly, I need to log in, and I need to go for daily scrum calls. In that scrum call, I need to explain, like, what are the targets, what are the tasks I have done yesterday, and what are the task task we have to done today. Uh, this is how these are my, uh, day to day activities, and this is my brief introduction about myself.

What are some best practices? Some best what are some best practices when writing Erkin test scenarios to ensure clarity and efficiency in test automation? Best practices. Best practice when writing Erkin. Um, the best price practices when adding getting test in our tools to ensure clarity and efficiency in test automation are, um, for first, we need to understand that, uh, what what are the test case we need to write and for which conditions we need to write the test cases. And, um, we we need to understand, like, in when which programming language we need to write and, uh, what what are the conditions we need to take. Later on that, um, the main aspects are clear and concise language in which in in this, we need to understand in which, uh, programming language we need to write the code and, like, we need to we need to write in a very simple terms because, uh, BD is a framework which is designed to understand for both the non IT and IT candidates. So, um, in this gate, um, in this BD framework, we'll use a very very common English words like given, when, then. Oh, so that non ID people can also understand very easily. Um, firstly, uh, to write a test scenarios, we need to, uh, understand about clear and concise language, and we need to check for the prioritization. I mean, like, uh, which test scenarios we need to write first and, uh, what are the first priority? And, uh, we we need to take about we need to write prioritization. And we have to manage the test data, and we have to perform, uh, negative testing, and we have to perform the usability, and we need to perform the retesting, and, um, we have to perform the regression testing. These are the best practices. And for and first thing, we need to check for the test coverage. I mean, like, um, we need to check all the conditions, uh, for for all the scenarios we have covered the test case or not. And, um, we we need to check the automation framework. I mean, like and and we need to check continuous integration, continuous deployment tool. Like, uh, it is running the test case automatically or not. Uh, like that. These are the best practices, uh, we have to take while writing check-in test scenarios to ensure clarity and efficiency in test automation.

How do you effectively set up and use a local mobile device testing grid for parallel test execution? How do you affect set up and use. To effectively set up and use a local mobile device, testing it for parallel to execution. 1st, we have to choose mobile automation testing framework, like, which framework we need to use, like, Appium or, uh, Selenium Grid or, um, what kind of automation tool we are using? Um, most of the cases, we use the setting just because it is open source, and it doesn't cost any single penny for installation. And it supports multiple languages like Java, Python, C plus. So most of the conditions, we will use only Appium as, um, as, uh, Appium tool for using while testing. And, uh, for effectively setup, first, we need to choose, uh, which framework we need to use. And the later on that, we need to install Selenium grid app and and the required notes to our local machine. Uh, after that, um, we need to connect our physical, uh, uh, our local mobile device and our emulated device to the notes. Like, um, if you are performing testing in our local mobile device, we we need to connect our device to the notes. Or, uh, if you are performing testing on emulated devices, we need to connect our devices to the nodes. After all that, uh, we we need to configure some test scripts, um, regarding to our project. We can perform parallel execution in Appium. Um, it means, like, um, for example, we have 2 devices with the 2 different versions. We can perform the same test case in a 2 devices. After that, we need to perform, uh, we need we need to check, like, the test execution was correctly executed or not, uh, and we need to check the reports which we have generated using test engine framework. And this is how we can effectively set up and, uh, use a look on wild device test for parallel test execution.

In what scenario would you prioritize the use of explicit over implicit weights within your Selenium tests and why? What should you plot? Actually, in test case, we will use both explicit and the implicit weight. Implicit weight, uh, it will be used defaultly for every, uh, in in every testing. Um, we will use explicit testing in some case, like, if you have any, uh, hyperlinks. For example, uh, if if you create any web page, we will contain some hyperlinks. If you want to test that web page, uh, we need to wait until the, uh, web page have you need to wait until the hyperlink is open to check whether the hyperlink is working or not. If if you didn't use any explicit wait for that, uh, condition, uh, we we won't we'll get some error like, uh, an error was not, um, the hyperlink was not opening or, uh, we will get an exception like page load time out. To get out of these, uh, situations, we will use explicit wait. And implicit wait, we will use this default for Selenium test. This is how we'll, uh, prioritize implicit weight, uh, over implicit weight in our synonyms tests.

How do you handle dynamic page concept or interactions in Appium while writing, uh, test scripts for mobile automation? How do you handle that? To handle. Uh, to handle dynamic page content or interactions in Appium while adding test cases, uh, we we first, we need to identify, uh, like, like, when first, we need to identify the web elements. Like, we need to identify attributes like a class name or its path or, um, ID name by using we need we need to identify the dynamic elements. In Appium, we we can identify those elements using Appium inspector, um, out of UI Automator. In Appium inspector, we'll get, uh, all its path and its CSS. But in the UI inspector, we won't get that, uh, it's but so most of the connections, we will use only app inspector only. Uh, to test, um, we we can handle dynamic page content by using, uh, contains, uh, in its path and CSS. Is because dynamic page content means it will change. Uh, for example, if you refresh a page, the elements, um, the identification elements will be changed. For example, if you refresh a page, the its path for the page will change. So to get it to get rid of that issue, we will use contains method. You know, it's part of CSA selectors to to locate the elements based on partially matching this content. Uh, for example, like, uh, contains class names or attributes. Um, in, uh, by like this, we can we will use, uh, condensed method, um, to handle dynamic page contents or interactions in Appium while letting test scripts for mobile automation.

When would you choose to use a data driven approach? We what were the key driven approach in mobile test automation? Okay. Um, we we'll, uh, most of the cases, uh, we will go for a data driven approach only instead of a key to keyword driven approach in mobile testing automation. Just because we will go for data driven approach, uh, in case for for example, we need to test some, uh, we we need we need to test some data. And, uh, we we have the data in our external file. In those situations, we will go for data driven approach in in which, like, we need to get some data from external files like, um, XML file, uh, or a cell sheet. From that, uh, files, we need to we need to get the data off into our framework. And from there, we need to use the data. This is called data driven approach.

In the context of data automation data automation, Appium is often used for mobile testing. Okay. There is a snippet where Appium interacts with the Android application. Can you spot the mistake and explain what issue it might cause? Okay. Here, uh, here you're finding the it's part by using, uh, find element. And, uh, and in the in the third line, uh, we we create we wrote, like, element dot click. Here, we need to, um, here, we need to assign this element or click to a variable so that it will work. Otherwise, uh, we are not able to, um, went to that element and, uh, we can't perform this clickable options.

Assuming you have been provided with the commonly used page object model structure and desktop framework, please explain the likely issue you see here with the login method implementation. It should be having provided with the commonly used page. I get more instruction and test automation. Please tell me, like, the issue. Here, they mentioned the username and password as a string in this login method. We can't take that username and password as a string just because these are not, uh, strings. We are taking it as, uh, variables. And the sorry. These are not variables. These are like, uh, identify identicators. So we can't take this as, uh, strings.

Provide an example of a complex CSCD pipeline. Uh, how is it up the things which we will do. Complex CSCD pipeline. Yeah. How is it up?

Okay. Um, how do you use Maven or Ant to manage some build automation scripts? Uh, basically, generally, we'll use only. By using dependencies, we we don't need to, uh, like, we don't need to install any specific dependencies. Um, for example, if you if you make if you add any, uh, we don't need to add any Jafels separately to the project. If you are if you make changes in, uh, if you add any dependencies, for example, if you want to add a Selenium dependencies, by adding the dependencies, we will get a sign and make all the into our, uh, project. So, uh, this is how we can use Maven, uh, to manage dependencies or build automation scripts.