Aakansha Tiwari

Hi, Amokansha. I have around 5 years of experience in QB testing, both manual and automation. I have been working with Patience since last 1 and 1.5 years. I have a working experience in Selenium for UI automation using Selenium, VD, Coumbus, TestNG, and Maven. And for back-end automation testing, I'm using RestAssure along with RestAssure, Spring Boot, and Lambdabehave for automation. My end-to-end responsibility in Paytm Payments Bank is to manage any testing that involves API testing along with this integration, you know, and automating all these scenarios that can possibly increase the code coverage of the dev code.

So what are the key elements for a QA prospective, what when we raise a bug, we make sure that the bug is valid. The priority and severity of the bug, if mentioned, are over there. Steps to reproduce if it's related to data or some critical functionality, how the dev can reproduce it. If we can identify the impact, we will mention it also. So that's the thing we make sure to highlight in the report. If a bug report as a QA person, we make sure that the steps to reproduce and the impact or the description of the bug is one of the main key points of any bug. And how do we prioritize the bugs depend on the product. If it's a critical bug, then we need to prioritize it as P0. If it's something that is not very high-impact on the application functionality, then the product can take a call to prioritize it or we can see the severity or priority of that bug. Severity is one of the key factors we can consider to prioritize any work. If it's highly severe for the system, then we need to prioritize it as soon as possible. If less severe, then we can delay depending on the priority, depending on the severity of the bugs, we can take action on the bugs.

We make sure different operating systems operate different versions of that particular operating system are compatible. Some times that happens that we don't need to check every version of the device or an OS Android of that particular device, but we make sure different OS versions are compatible with the new changes or with the app. The UI is not breaking. The functionalities are not breaking on the current versions, basically. We can sometimes ignore the older versions where we are not providing support, but the current versions are working correctly or not with the new changes.

So, in my current augmentation, there was a feature of updating a primary doc of a user with this hash value. And, like, the complexity of the system is that we have to use two different kinds of databases with two different kinds of microservices and integrating them. Then, the third service will use that particular hash number in their system. To automate that, I need to make a connection with all three services in between all three services, then make that because it's not like every service is up and running on the testing environment every time. So, we have to mark those few services to get a response every time, so that whenever we're running our test cases, they work fine in automation along with one test case, a positive test scenario, where every time it gives the correct answer. Otherwise, the mocking part of one service is a challenging thing. So, we first proceed with all these testing that we manually do and identify a scenario where we can actually hit the service all the time to get a correct response. For other scenarios, we use mocking and that's how we proceed to automate all the features because it wasn't very feasible to keep all the services up and running every time because we're working in a microservices fashion. So, that's why we use mocking.

Okay. So for manual and automation tests, Okay. So to test any service manually test any service using a peak load, which is kind of not very feasible, but we try to do it using Postman. We can use some CSV file if your subsystem supports that and run your particular API for continuous some time to see the variation in the response time. Or you can use JMeter for automation purpose and see the performance of the API wherever you are testing at a peak load condition. So what I verify a peak load condition depends on the system's stress, load ability to handle the load or enter concurrent users at a particular time. So to test those things manually, it's not very feasible, but for testing purposes, we can use to concurrently hit the application. We can take the help of the developer so that he can reduce variables for testing purposes. He can reduce some variables, such as my production application which can concurrently handle thousands of users. But for testing purposes, it's not very feasible to have thousands of users still hitting the application. So we can ask the developer to reduce it to 700 and we can try to do it by using automation or by manually or we can parallel use both approaches to test the load at peak hours and see how my application is behaving. If I get actuation, we can report. I can report it to the developer and he can fix it for the lower batch of the application. Or we can develop and deploy that particular feature and test how it runs on 1 or 2 servers that particular application is behaving for that peak condition to see the differences of the load on the particular.

For in any automation framework, we can ensure the usability or maintainability of the code. For usability, we have used the page object model. In my last organization, when we used the UI automation framework, we were using the form, which is a page object model, where we kept similar code in page classes, Java classes, and reused it again and again, or we created generic methods in our framework. So that we could use a single method and use it everywhere according to our convenience. So, you can change or prioritize the method according to your requirement. This will increase the usability of code. Maintenance depends on how frequently you make changes in your application, and you have to make the same changes in your automation framework also, so that you are up to date with the new changes every time the release is going, so that you are not missing any bug or any functionality that should not be breaking. So, you can also use various plugins, like if you go with the structure framework, you can use it to reduce code and, like, you don't need to write getters and setters, and you can directly use annotations to make it easy and reduce the code line of codes. And it's very helpful to use in your automation framework. So, there are various things you can use in your automation style scripts where you can reduce code and reuse the same particular code, depending on your requirement.

So in a singleton class, we have basic concept of only one instance at a time. So, in this if this code is given, we have three things that we make sure in a singleton class that it will work fine. Then we check if the instance is not null. If the instance is not created, we create the instance. Otherwise, we return the existing instance of the particular database connection. Then we have one thing that might break this code or cause a potential bug is the connection close. We are not closing any connection anywhere. So, what will happen is suppose I'm using that particular instance of the database connection at my end and another application is trying to access their particular connection. At my end, when the work is over due to some reason, I am not releasing the connection. The other instance is consumed at my end, but other services are blocked for that. So we have to kind of create a connection close. It's one thing that we can enhance in this. It might be that we are using it somewhere else, but all three conditions are getting followed over here. So all the singleton thing that we are mentioning design pattern, we are following correctly. Only thing that I can see that if we can add one more condition where we can close the connections if the work is over then it would matter more better than the

Okay, so the current code that is displayed on the screen, what it is doing is in the first line we are creating, we are initiating our web driver that will open the Chrome browser, and we are launching an URL. Like, we are going to an URL http example dot login where that page will get displayed. Then we have a login then we are defining a test case, test login. And in try block, I'm trying to find an element and clicking on this. And we have an assert. So, what we have in our assert condition is where we are finding a text in the driver page source. The driver dot page source is a method that will give you all the page of source of the web page that will be loaded. And, that web page, on that particular web page, we want to find a text. Right? So this text, the condition that our assert condition we have, we are giving is welcome user. What we are not kind of getting is it anywhere. It's like always it's a hard-coded value over here. So you have to first find the element where that particular condition is visible. Kind of you have to check where this is present and then search in the web driver to see if it's present or not. So that's why the assert. In the assert condition, if you see, we are not checking anything. We are just simply asserting the value. There is nothing like actual and expected values. We are just passing a value. So it might help you. And we are not using any assert function also. Assert true, assert false. We are just asserting the value. It's like just a verifier condition. It's like a soft assert, which won't break your test case. It will just see if it's passed, the condition is getting true or false. If it's true, then it will move forward in the same test case. If it's false, it will just exit this case and give, it will continue on existing. Let's just say that your condition fails. So we have to properly use the assert condition over here. Like, assert fail, assert passes, assert equal to whatever you want to make sure that it's a hard set and it will stop the execution of the test.

The practices that I follow in writing and automating test cases are first to cover as many scenarios as I can in auto while automating them. Second, there should not be any flakiness in my test cases. Third, I am not taking any unnecessary weight or sleep time in my test cases. Fourth, all the conditions are matching. It's not like I'm hardcoding things; rather, I should have all the things available at runtime. So we are making sure that everything is true or false, actually passed, not some false positive. Like, all should be positive, true positive. And the practices that I follow are clean code practices. I try to write as clean code as possible. Reusability of code, I try to make more generic methods so that I can use them everywhere depending on my requirement. If I'm trying to ensure that the sequence of dependent test cases are properly working, then only I'm asserting values. I also check status codes in every scenario before going to check the status response. And since I'm testing, usually I associate with backend testing. So most of the time, I make sure that whatever pressure is happening on the db kind of because we are dealing with APIs. Sometimes you get the response, but sometimes it happens that db is not getting updated or other services are not getting the correct data. Like, if we run db, we are sending an event that is working or not. So all those things, all those conditions I try to cover in my automation to make sure that I'm following best practices and getting more core coverage.

To ensure that any migration in a service is successful, we make sure that the current service is running with the current version of the application and that the new migration is working fine. For example, in my recent feature where we are migrating users from one platform to another, we make sure that the current services are not blocked for the user. He is able to use it and make changes on the other platform. The same functionality is provided in this scenario as well. So we are making sure that the existing part is working fine, and the new part is also working fine until the full development on the new side is completed. Once all the development on the new side is done and the user is migrated, we make sure that the user is able to perform all the post-op operations that he was doing on the old side. Like previously with the old version or when he was not migrated from one platform to another, it was working fine for the user. The same applies over there. Sometimes when we are migrating the user, we restrict something. We also have to make sure that if we are restricting something in the new version, it's working fine for all users, not just new users or old users. So whatever the requirement, we make sure that post-migration, everything is working fine and there are no visible changes for the end-user. Like, because you are just migrating the user on the back end, the user should not get impacted when you are migrating something. If you are migrating from one technology to another or one platform to another, then all the things we mentioned should not break for any user, whether it's in progress or after migration. So we make sure that happens.

In our team, we are using agile methodology along with SDLC. So, what happens is whenever this print starts, we have got the requirements from the product managers or product owners. They will give us a brief introduction about the requirement. The developers will then do their own analysis along with the impact of the changes they are making. That meeting also includes QA, where QA describes if they have knowledge on the existing environment, they can provide their input about the changes and the impact. They feel that particular change can bring into the subsystem. Then we start, as a QA, I start writing the test cases for that particular feature that I need to test in the upcoming days, and get all the test cases reviewed with the developers and the product manager. In that particular meeting, we discuss the test cases and impact, and we can raise any requirements that we have for the particular testing. Suppose I am testing something and I need some new test bed or some kind of test data, so we start, and we need some other help. So we can raise the dependency if required. Otherwise, we start after the test case review meeting, and we can create the test or test data on our own. Once we get the changes, we start testing the scenarios. We maintain the test stability, all the testing artifacts with us, and provide a simple demo to the developer and the product manager that shows the new feature that we have developed. Then we deploy that particular change on a high for integration testing in a different environment where we perform the integration testing. Then it goes to the product owner, who will see the changes and decide if they are what he wants or something different is developed. And after that, we deploy the changes to production. So that's the whole cycle that we have, because we are using agile, every requirement and every change is correctly deployed, and everything is working fine. And it's like an alternative deployment. So every change is very small, so you can easily identify and monitor the changes, new changes along with the old changes. Like, you can perform regression testing to make sure that nothing is breaking.