Mohd Osama

Could you help me understand more about your background by giving a brief introduction of yourself? You're definitely yourself, Mohammad. Currently, I have around 6.8 years of experience in software testing. Like, so currently, I'm working with the Nykaa Fashion. So, basically, Nykaa Fashion is an e-commerce domain. Those who are dealing with selling clothes products online, e-commerce, just like Flipkart and Amazon. So, yeah, currently I'm working with an e-commerce company that's in EICAGA version as I said. So, here are my roles and responsibilities with respect to automation and as well as functional testing also. So, as we are working in an agile methodology, so our sprint goes for two weeks. So, we just fetch the functional tasks and pick a task for functional testing. They're performing end-to-end testing, including back-end testing also, including API testing also using Postman. And, then we are automating those features for the regression suites. So, basically, I will have to perform functional testing, as well as automation testing also. So, with respect to automation, somewhere around 50% bandwidth is allocated with the automation task, and the 50% bandwidth is allocated with the functional task also. So, apart from that, I have a responsibility for monitoring and analyzing the regression source also. Like, so, I mean, we're just monitoring the regression suite on a daily basis that we are executing. Fix, analyze the failure cases. Fix the failure cases. And if any code improvement is required, I mean, in terms of code or maybe any enhancement that we are doing into the framework. That is also done by us. And, like, with respect to other tools and technology I'm talking about, so that is something, like, I have experienced for both mobile and app automation using Selenium Java and APM. And, like, other than that, I have experience to use Postman and Jira that I'm using. Apart from that, I have experience to use Kibana and Grafana for logging. And, like, I mean, just to check the logs, you can have experience to perform functional testing for the web application as well as the app application also. So, yeah, this is pretty much about me. And apart from that, like, with respect to automation, that is somewhere around 6 years of experience that I'm having. And, the total experience that I'm having, that is somewhere 6.88 years of experience. So, yeah, this is pretty much about me.

Explaining in terms of both manual and machine testing, how would you test an application response and repeat load condition? Yeah, definitely, if we will have to perform a test, I mean, perform an application under the peak load condition. So, in terms of manual and automation, what we can do is generate some n number of error requests while performing a functional testing or a feature testing. We can use either a JMeter or something like that with respect to that. We will have to hit the application with n number of requests, then we can check the behavior, what exactly that behavior is happening on the application if the load is increasing. So, basically, what we can do is use a JMeter or something like that with respect to that, I mean, the application. We can just hear the requests and check different end flows with respect to the manual testing. We'll have to check how the application is performing. What's the response time of the application, and what's the app launch time of the application. And with respect to the automation testing, I would say what we can do is write a short script or maybe the script with respect to the automation just to perform the peak load. We can just perform the load testing on that, we can just hit the application or just try to open the application with the n number of users. For that, we can use maybe some browser tags or maybe some other tools and tools just to launch a app or maybe launch a website to check the performance of that. And other than that, we can just put a load on the back end side as well. So, we have some sorts of back end servers, I would say, in the AWS. They can increase the load at the back end side, and then they can check how much load the application can handle it. Right? So, there, they can increase the container. I mean, create the container. They can just try to script to perform to increase the load. And with respect to the peak load, what we can do is check the data. Maybe some Google Analytics, from where we can check how much load we are getting on the peak load. And we can just increase the request to maybe 2 x or something like that just to prevent the load response on the application.

How do you ensure the accuracy of data test data for executing test cases, especially when test complex business scenarios? Yeah. Definitely. So, to ensure the accuracy of the test data for executing test cases, especially for complex business scenarios, we can follow these steps. So, basically, we should have a requirement document, product requirements details or description that we get from the product manager or the project manager. We should have that document before writing test cases. Right? So, we can map each and every requirement with respect to the test cases so that we can ensure that every requirement has a valid test case. And, with respect to that, we can create data with respect to that I mean, with respect to that data. So, basically, as per the test cases, we will have to create test data with all the possible scenarios. There's only one thing. The accuracy of test data, like, we can ensure that with respect to the test cases. I mean, if we will have a test case ready before getting the feature build or maybe testing build. So, with the help of test cases, we can analyze how much testing data is required for the testing and what type of data that is required for the testing. So, we can just create the data before that, and then we can perform the testing. And, just to ensure the accuracy of the test cases and as well as the test data also, we can ask the product manager and the QA manager and the dev managers to review the test cases. So, if any feedback is required, then, definitely, they will provide a feedback to update the test case or the test data. Right? And, other than that, what we can do if we'll have to perform a single test case with a number of test cases. For that, we can use test testing techniques, like, for example, equivalence partitioning or maybe boundary value analysis that we can use to perform the testing with respect to the n number of data. By using these techniques, and maybe this is an example. Like, we can ensure that we are able to perform the testing with proper data, and, like, we are ensuring that we will perform the testing with all possible test data. So, yeah, that's it, I guess.

Implementing continuous testing in a DevOps life cycle. Still, we continue assessing. What we can do, if I were to say the continuous testing in a DevOps life cycle. So, I mean, we should have something with respect to the CI side and the CICD pipeline or maybe something like that. I mean, so basically, if you are getting any build, maybe getting any feature, getting any application or production, something like that, for the build of feature on this server. So, I would say, deploy the build of feature on this server. There should be maybe some chunks of code or maybe some unit testing, which should be triggered automatically. Like, if you are uploading, I mean, if you are deploying a feature on some Jenkins server, there should be a predefined test cases that we can call unit test cases, something like that. We should have that on the Jenkins, and those things that we can write into the Jenkins configuration. Or maybe we can write into the scripts also. So, yeah. If we are deploying some features, so, there should be some chunks of test cases or maybe chunks of scripts with respect to the unit test casing or maybe some more testing. Test cases should be there just to check the initial phase of the testing, automatically by the Jenkins, so that we can check the initial phase of testing over there so we can reject the build also. So, yeah, this is what we can do.

So, like, our testing challenges, I would say, I'm facing into the automation. There's a number of challenges that I have faced while performing automation testing. Whether it's I mean, basically, I have experience in both app and web automation testing, and I'm writing a script for both mobile and app automation. So, yeah, like, I get the challenges in both sides. So I'll just give you one-on-one example for both the cases. So let's suppose I talk about the app testing. So, what are the challenges that I have faced? On the app side, earlier, we used to log in using an email and password. Right? So, for that, we had stored a login password in a properties file, and simply, we were able to log in. But, like, soon after that, the team started using or maybe migrating to mobile number plus OTP. I mean, basically, they were migrating into that mobile number plus OTP thing. So whatever the regressions or test cases that we had at that time, they started failing because the test cases were written into the email plus password things. And, on the OTP side, what's happening? The OTP is, I mean, if you're entering the mobile number and hitting the submit button for the OTP. So, like, if OTP is coming every time from the OTP writer. These are quite challenges for us to automate the login scenario at that time. So what we did, we're just storing a static OTP into the backend. So every time, when we're trying to log in, we're using the same OTP from there. Other than that, we're performing A/B testing. A/B testing is something like we're checking on to a different screen, either an old screen or a new used screen, I would say. I mean, we're just checking or analyzing the performance of the two different UIs of the same feature. Right? So, and generally, an A/B experiment is running on the A/B thing. Right? So that experiment is totally dependent on the certain ID and because we never know which experiment the user will get logged in. Right? So it's totally dependent on the user side, user's experience, user behavior. Right? So, you know, it's quite difficult to automate both scenarios at the same time. So what we have done, we have just made some changes into the remote config using config files into the app site. So we have created a new APK for such features, then we're able to perform the testing or write the automation scripts with respect to those features. Apart from that, on our website, we're having an issue with the login just respect to the login and capture. So for that, we're using a session case. We're writing a method and using a static session ID to log in on the website. So, yeah, that's it.

So, explain how would you approach testing a mobile app's compatibility with different versions of operating system. Yeah, definitely. So, like, if we're performing any app testing, we'll have to check the versions of the operating system. If any feature is like any feature that we're rolling out, we'll have to ensure that feature should be working on every possible operating system that's available in the market. For that, what we can do is check the Google Firebase. I mean, if people are using Google Firebase, Google Firebase is something that provides data on the user base, like, the type of user that we're interacting with on our application. So, that data that we can get from Firebase or with that, we can get from the Google Analytics team. With that data, we can shortlist 10 most useful devices or maybe 20 devices that are helping a more number of users. When choosing devices, we should ensure that those devices have the most user base that's using our applications. So, with respect to that, we can just perform a testing. Because in the market, there are a number of versions of operating systems. Right? So, other than that, what we can do is let's suppose if any feature is being built on Google, or any feature is being developed, we can just perform the testing on the current OS version. I mean, maybe on the latest OS version or the Android version. Irrespective of that, we'll have to perform the testing on the version that's currently operating in the market. We can also do the past testing, I mean, the last 5 versions that were available in the market. These are the things that we can also think about. Right? I mean, we can just do the testing with respect to this also. I mean, either you can just check the updated version or maybe the last 5 or 6 versions. But, you will have to check the user percentage, like, the user base, with respect to your application data, on which version most of the users are available. You will have to shortlist maybe 10 or maybe 20 devices or versions, then you will have to perform the testing.

There's a logic error that's caused the test to always pass even if it's so. Phil, can you spot and explain what is causing the issue? Okay. Trevor is equal to webdriver.com. Trevor dot get to dev test login. Try. Trevor dot find element by ID "login". I dot click. Yes. So, welcome user. Okay. In driver dot page source. Accept exception as e. Print "test passed". I think the logic is written in the Python. So, basically, they are just simply invoking the Chrome browser. They're hitting the URL. Right? And, like, they'll try to find the element using ID, and they're performing the click. Right? So, while performing the click, they're not going to basically the assertion is, like, I mean, they just put the assertion. I mean, they're using some text. Right? Welcome users. But before checking the assertion, right, you will have to get the text or I would say string. I mean, the text string that you want to put into the session, you will have to find it using an element. You will have to add one more step after performing the click action. So, whatever the test that you are coming, and that you will have to locate it, then you will have to get the text. And that text, you will have to pass into the assertion. For that, you will use assert not equals. And within that, you will have to pass both the text. I mean, whatever the test that you are getting and what is the expected text you are expecting. On behalf of that, you can add the assertion. So maybe this is the way that is passing the test cases every time because you are not fetching the text, and you're just passing a one text into the assertion. So it will pass always. Yeah. Definitely. And, we are printing the test passed. And if you are getting an exception, s e, I mean, we are just putting an exception also. So if you are getting an exception, then you will have to make the changes into the exception condition, like a print test pass. Right? We will have to change this statement also. So, yeah, this is the issue that we can

The segment of the Java code aims to apply the singleton design pattern. This is a potential issue that could prevent it from working as a proper singleton and verify and fix the suggested suffix. Public last data is going to private test. The instance is equal to the private getter instance. The instance is equal to the new database connector. The instance is equal to null, and it's going to be the new database connector. The segment of the Java code aims to apply the singleton design pattern, which is seen in situations with their equipment. A proper singleton can identify the problem and suggest a fix. Database. It was going to get the instance. Okay. So I think, like, while in this code, what we are having is the issue with respect to the database connection. Like, at the end, we are writing a code for the database, right, to connect the database. And before that, we have already put a condition using instance equal to null, then we can message a new database connection. We're just creating one more object into that, and then we are returning the instance. Just before that, you will have to write a code for the database, so that my I mean, that might be that can we work? Private static. So there's another issue, I guess, I would say. We are using a like, we are creating a variable of the instance using a private static key. Right? So, basically, it's a private variable, then you cannot use that variable directly. You will have to use the getter setter. I mean, use the getter setter, then you can use that variable. So this is also a problem, I think. So, yeah, these are the things that we can fix, then it will start working.

I think the scripts that are adaptable to change in the application interface over time. How do you approach writing test scripts that are adaptable to change? I approach writing test scripts that are adaptable to change in the application interface over time by doing a modernization breakdown of the test script into modular components that represent different functionalities. This makes it easier to update or replace individual modules. Or we can use page objects, implementing the design pattern where each page of the application is represented by a separate class. This abstraction helps isolate locator interaction with the UI element, making it simpler to update them if the UI changes. Then, we can do parameterization to separate the test data from the test logic, allowing us to easily update the test data without modifying the test script itself. We can also use dynamic locators, which are less prone to breaking when the application UI changes. However, dynamic locators do require regular maintenance and updates to remain accurate. As the application evolves, we can make changes to the UI in our test scripts to ensure they remain accurate and effective. We can also use burden control to manage the impact of these changes on our test scripts. I think that's how we can do it.

Given the requirement to the ultimate performance testing, what tools would you choose and how you did the reliability of the performance release result. Okay, I have a question. Asking the question. So, for automated performance testing, the tools we would choose are a JMeter. So, definitely, we'll have to use a JMeter. And with respect to the reliability of the performance results, we can do so every time, meaning basically, generally, like, an application has its backend services. So, we can just make the containers at the backend side, then put a load into the backend server. And then we can check how much load your service server is bearable. Right? I mean, how much load that your server is able to handle? And for that load, what we can do is find the data from, like, our Google Analytics team. They will give us the data, like, what is the load, maybe how many users are interacting with the application at peak time. So while performing the performance testing, you will have to make sure you're performing testing more than that. I mean, you will have to make it two times the number. I mean, just to check the load into your application. And how you do this is how you delay related or maybe perform testing with respect to that data. So, into another time, that will not impact your application in the future because we have the data and you're performing load testing with respect to two times that number. So this will help your applications perform very well if the load is increasing more than that.

So what is the approach to automating security testing, especially for the mobile application? Okay. So, for the automation security purpose, what we can do is check the requests that we are passing into the application, so that all should be secured for that. So, basically, whatever the back-end request that we are using, whether it's a mobile application or a web application, all those requests should be secured using SSL proxy and SSL socket layer. I mean, we will have to put security in place while developing something at the client side or maybe at the back-end side. Apart from that, we can have some other tools also, like some cloud-based things that we can apply at the back end. So, whatever the request that we will have at the back end or maybe whatever the request that we are passing through the client, that should be passed through that layer. So, that will rectify any issues on your application. Or apart from that, we can just try also. Like, if any random API, you may have some suspicious APIs trying to hit your API and your page, so we can just prevent them from using that page with respect to the number of requests? I mean, we should have a limiting or immediate limiter thing. So, that is basically happening on the back-end side. At the front-end side, like, we are not doing anything with respect to the rate limiting, I would say. Apart from that, what we can do is make sure that whatever the request that we are passing from the client side, that should be passing appropriately, like, whatever that request that we are passing using a header and body. Right? That should be passing in a correct way. We will have to test using a different parameter, I would say, or maybe an incorrect or invalid parameter. So, whatever the testing that we will have to perform with respect to the back end and the front end, we will have to perform very properly testing, with respect to the integration testing. We will have to perform, we will have to check the client side and the server side things also. I mean, let's suppose if we are checking some pages, something like that, so we will have to make sure we will have the client side validation and server side validation also. So, yeah, this is the thing that we can approach for the automation security testing.