Supriya singh

So, my name is Updia Singh. I completed my BTEC in 2013, and then I started my MTech in 2013, which I completed in 2015. I began my first job in January 2016 at Finestra software solution in Bangalore. It's a payment-based application where I worked, and our clients are from Budapest. We created a small interface for them to facilitate transactions, known as inter-day transactions or foreign transactions. As an automation engineer, I evaluated manual test cases and created automation scripts using the Robot Framework, which is a Python library. In 2018, I joined Trident Shocks Lab. Currently, I'm working with Core Method software solution, the parent organization of Trident Shocks, where I'm a senior quality assurance lead. I have a team of four members, and I handle them, providing support for manual testing and automation design. We focus on web automation using the Robot Framework and API automation. Additionally, we use JMeter for performance testing and tools like Postman for API testing.

Okay, so the test automation architecture for a hybrid mobile application would be as follows for mobile testing, we have multiple platforms like iOS, Android, and iPhones. In that case, currently, we are using the Robot Framework. So, the Robot Framework is a kind of framework that uses the APM library in order to test mobile automations. We are using the Robot Framework wherein the architecture is defined with test data, then a library is defined. The test data will come up, then the Robot Framework will come up, and then there will be tools related to that, and there will be a settings section there. After that, there will be an execution. This architecture is basically a data-driven architecture. Here in the Robot Framework, we use keywords that will drive all our automations, and we have the APM libraries that expose a set of keywords to us, which we use directly into our system, and which helps in automation.

When we encounter a complex testing scenario, we automate it by breaking down the sequential cases into individual test conditions. This allows us to execute each condition independently and validate the output before passing it as an input to the next condition. For instance, if we're executing a set of conditions where the output of one condition becomes the input to the next, we can validate the output to the database or third-party system, like Excel or a database, more efficiently. Our approach is to mark our test data in such a way that the output of one condition should have a specific number of different outputs. We then format the output from the first test case in a particular way, and only then do we provide that input to the next two test cases. This method provides an easier approach to database validations and helps us sort out issues in the automation part.

We approach testing a mobile app's compatibility with different versions of operating systems by utilizing DevOps to manage our test automation. The entire application is managed using DevOps, where we have different versioning processes in place. Each version has a unique set of scenarios and cases that need to be executed against it. Currently, we're using a set of automation that targets a particular version, isolating it from other versions. We have a small piece of code that tests version e, and another code that tests version b, for example. We integrate our CICD (Continuous Integration and Continuous Deployment) processes with Git, which pulls code from our DevOps repository. Every version gets pulled, and if there's a bug or enhancement, we pull those code into our system. We then push the updated code into the same repository, where it's continuously tested through CICD. This is how we test the different versions of our mobile app.

How do you ensure the accuracy of test data for executing tests, especially when testing complex business scenarios? Accuracy of test data is crucial because there will be test data that follows a certain pattern, such as being in JSON format or dictionary type or list type. So, first, you have to identify the requirement and determine what type of test data it is. For example, what type of data can be in the key, whether it's a rare card type of data or adjacent type of data or a dictionary type of data that has to be sent. So, what we will do is write multiple checklists for any test data. We have to ensure that this particular type of data is included. For example, if it should be in JSON format, our condition should check for that type of data. If the data comes in the same format, then only we will take that particular data and provide it as an input to the test case. We should not be providing the data directly; instead, we should be accepting it after checking. This will ensure that the data coming into the test case is correct.

Describe the testing challenges you face to the queue automation in the past and the steps you took to overcome them. Okay, the major challenge which I faced in testing was basically being into automation. So I faced an issue with execution time. Like, basically, we have around 400 to 500 test cases or test scripts, and running those test scripts overnight is one thing which we were doing, but that was also problematic because it was continuous. Some cases would continuously fail and come next day, and seeing those issues again and running is a tedious job. So what was the issue, how did we resolve it? We basically incorporated parallel testing. Knowing parallel testing, we laid down a time frame, and the overall execution time from around 4 to 5 of us was just turning into 1 hour. So by using parallel testing, we achieved a total execution time reduction, which helped, and it's very quick and fast as well.

The phone just has never determined why the phone does not connect. Click update to display. So basically, in the let function only, we have asked for user profile. User profile document dot get element by ID using user profile. So if that particular person hasn't logged in, so this profile element, we will not get it. So this is not correct here on the line number 2nd. So if the user is logged in, profile element dot inner text name is logged in through name validation. Example. The user profile. Because in the let function we have called element by user ID and we haven't provided the user profile ID here. So this profile element will not work, and due to which it will fail the case. From the call function, we have only provided true name and age. User profile has not been sent. So user details will not work. Profile element will not fetch you any result, and this will fail the case.

Python model data to cellular model data. Just a logic error that caused the test to always pass even if it is supposed to fail the test login. Snipping here. Try driver.find_element_by_id('login'). You do not click. Even if it is supposed to fail. Because the test has passed with the exception. In the print statement, like, the issue is in the print statement, we have written test passed with the exception. So if there is a failure, it will still pass the test case and it will provide you the exception. So logically, this is wrong because the print statement gives you test passed with the exception. So if there is any failure, it should catch the exception. Here, we are printing as passed with the exception e. Due to which this will never fail. It will give you a passed result.

How do you enter? Python based automation framework, we can, like, we have a we have a robot framework which is a Python based automation framework and it is very much robust and it is well defined and it's already working with the C I system. So you can have the DevOps integrated for the C I connection with the robot framework or you can use Jenkins also to integrate your robot framework with the C I because it's also a Python based and it is very robust. And what we'll do is basically we have to do is we have an automation script, and that script should be in a repository on the DevOps. And then from the DevOps, you have to create a pipeline job and you have to integrate. You have to add all the configurations of your Python or library's version and also point your code to that particular location of the repository of your automation depository, and it will and also you have to provide the variables like username and passwords which are confidential into the DevOps system. And once you provide those things, it will start to build the artifacts and then automatically it will go to the location where you have pointed your repository. It will pick that, provide the very it will detect the required variables which need to be executed. It will take that and it will run your continuously run your job against the application. So continuous integration is very look very easy and seamless in the DevOps currently which we are using. So it is perfect. Like, it is working fine. Only one disconnection is only one time connection is required. You have to keep updating your code. You have to keep you can keep adding your code into the repository, and it will automatically pick that CI and it will run through that, and it is just one time configuration in the DevOps. Or if you are using Jenkins also, it is like one time configuration we have to make.

Explain the methodology you would apply for migration testing to ensure critical operations function post migration. To explain the methodology I would apply for migrating testing to ensure critical operations function post migration, so when we are migrating, we have to understand the issues in which we can face, like for example, if we are migrating our automation from one framework to another, first we have to identify what all the critical areas, what are the parameters which are dependent on it, what are the variables and test data. Those are dependent on that per se for automation. Identify the critical test cases. Keep those test cases aside. Start to migrate the easier ones first. Check how the migrations are going on. Keep running your old critical cases with the old migration, and slowly you have to come and slowly you have to migrate your cases. Once your easy cases are stabilized and it is running fine, then you can slowly add the critical cases also to this in the new migration framework, and then you can build confidence by running it continuously. By running the new framework also the old one, it will ensure your continued testing, and also ensure that your migrations are working fine. So it won't impact, but it will help you to explore. We convert all your old code into the migrated new code. So, first approach with the simple cases to migrate because we face a lot of issues and challenges while migrating. If those can be sorted, we can easily migrate our critical cases and operations also.

Automate performance testing with tools like JMeter, where you can write JavaScript code to automate web related pages for performance. Otherwise, you can also go for the Robot Framework, which provides automation code for performance testing. It also provides well-structured automation code. You can write automation code for performance testing using Robot Framework as well. Currently, we are using JMeter, where you can write all your page-level performance by providing the HTTPS URL, and you can give the load with multiple users. You can provide Chrome credentials, browser credentials, and the HTTP URL, and it will execute. It will give you all your latency, throughput, and how much time it takes and which pages have failed. You can also do this using JMeter, and you can write JavaScript code in the JMeter editor to validate your performance. Plus, you can use the Robot Framework to write automation code and get the start time, end time, and subtract it to get the performance validated with KPIs, which are defined for the application for each page. Like what are the sets of KPIs defined? For example, it could be 2 seconds, 3 seconds. Based on that, you can validate it, and this way you can do it. Currently, we are using JMeter, and there is another tool, Locust, which is a Python-based tool and is currently being explored. But still, we are working on it. Locust is used for Python-based applications.