Yogashankar PS

Uh, I am a, uh, senior, uh, independent contributor level, uh, test engineer with, uh, 8 years of experience in, uh, application testing, both on the back end and front end for, uh, web and, uh, mobile apps. I have experience in, uh, uh, exploratory testing, functional testing, regression testing, integration testing, and, uh, user acceptance testing for SaaS based web apps and mobile applications. Uh, currently, I'm I have been employed by Britney Bose, uh, since July 2021, where I have been handling, uh, the shipping and mailing application of Britney Bowes for, uh, u, uh, UK, Canada, and Germany regions. This includes testing for internationalization of data, uh, and, uh, data formats as well as the, uh, testing of the entire application on a release to release basis for, uh, qualification, uh, and, uh, release every 2 weeks. I've been working in the agile methodology and handling the, uh, region based internationalization and, uh, region based customization of a single code based application for a reason, uh, 3 different regions till date.

Performance testing can be integrated into a Selenium test suite, uh, in a roundabout fashion, wherein, uh, for every test, we can, uh, every test and test step, we can record the time stamp, uh, it before initiating the test and then recording the time stamp, uh, as soon as the test passes. And based on which, we can we can calculate the transactions, uh, per second, uh, value over, uh, the entire suite and, uh, thereby gauge the performance of the UI. But, uh, the, uh, the back end test have to be integrated using JMeter.

After a successful build deployment, uh, Jenkins can automatically trigger, test when we include the test, uh, step inside the, uh, inside the Jenkins pipeline. Uh, Once this happens and the pipeline is, uh, deployed, it will first, uh, uh, build the application and, uh, deploy it to the host. And once the host, uh, deployment is done, the test will get triggered as

Uh, one method, uh, that I definitely would use to troubleshoot issues that appear only during Selenium testing but not manual testing is, uh, to include all the logs of the browser state and, uh, the, uh, input. Uh, this the input data provided and the sequence in which the data has been provided and, also, uh, logging all the exception details that have that, uh, they test encountered. Do using this, uh, we can gauge, uh, the exact problem that uh, test, uh, failure has occurred due to. Mainly, uh, some of the issues that we have found, uh, till date in this manner are, number 1 is the, uh, wait time is not, uh, long enough. Sometimes the UI takes longer than, uh, what the wait time is configured for. And number 2, uh, it could be that, uh, there are some cookies that are saved, uh, in the browser, uh, which are being used and that the Selenium Browser, which is initialized, does not have those cookies. So, uh, they have to be added, and then the Selenium test usually passes.

Uh, to, uh, to ensure that a selenium driven browser can run-in headless mode in a Jenkins build, uh, what we have to do is, uh, inside the code, we have to initialize the driver, uh, with the option of headless. In Chrome, it is Chrome options. In, uh, Firefox, it is, uh, the profile wherein we configure the browser to be initialized in a headless mode. Uh, using this, uh, uh, when the, uh, when Jenkins triggers the automation test, the browsers get initialized in headless mode.

To reduce our test, uh, flakiness in the Selenium Automation Suites, uh, the number one thing we have to do is, uh, we have to, uh, have, uh, the Selenium explicit weight, web driver weight, and, uh, fluent weights for, uh, synchronizing the user actions and the, uh, the the application response, uh, in order to proceed with the next steps. And, uh, the second thing is, uh, to, uh, design the locators in such a way that, uh, they do not depend on, um, items would dynamically change, uh, from build to build or, uh, from time to time in the web page, uh, DOM, document object model. Uh, most of the times, uh, the expert, the design has to be, uh, designed in such a way that it depends mostly on, uh, parameters that are static and, uh, pertinent to the data being displayed in the field and does not depend on, uh, some dynamic IDs or dynamic, uh, data, uh, identifiers, uh, which can change.

Slash data. Assert response status code is equal to To check on HTTP status code. Now, uh, a gate API, uh, could could either be a 200 or a 204, which in which, uh, states that there has been no change in the, uh, uh, status of the API since the last request. So, uh, to to improve the check on the status code, uh, what we have to do is we have to assert an odd condition of status code is equal to 200 or status code is equal to 204.

So that the login function properly handles with very much that are not immediately In this, uh, code, uh, I do not see any, uh, weight function. So a web driver weight function should be initialized with the driver and, uh, with the proper amount of, uh, waiting time. And, uh, each of the driver dot find element, uh, should should be preceded by a web driver wait, uh, to wait for the visibility of the particular, uh, element. Uh, and only after that should the, uh, find element and send these methods be executed. In this in this way, the, uh, the login function will properly handle all the elements that are not immediately available and, uh, will

Scalable and maintainable test framework. To create a scalable and maintainable test framework using the Selenium and, uh, Jenkins, first thing is that, uh, the data providers, uh, should always be returning an array of, uh, single hash map, uh, array single element arrays, which contain a hash map of string and object, uh, data types. This way, what happens is all the test, uh, methods, which depend on data providers, will have, uh, will have a very reduced signature, uh, which will help, uh, isolate changes, uh, and and basically make the test more maintainable and reliable. The the test will contain hash maps. So the, uh, the access of, uh, each and every test data component will be based on name, uh, which also improves the maintainability. And, uh, to to make the tests, uh, scalable, uh, each and every functionality has to be first isolated into its own test class, and, uh, we have to follow a page object model pattern so that, uh, addition of new pages, uh, can also be incorporated, uh, by adding more page objects. And, uh, by, uh, by making the page objects change to one another where, uh, navigation actions on any one page object will return the page object of the new page that gets loaded. And, uh, using using page object model in this way, we can ensure that, uh, the scalability is maintained so that when when more pages are added, uh, branching off from a single page, uh, more, uh, objects get returned from that from the page object, uh, methods of that single page. And, uh, the user is able to quickly add more pages and, uh, uh, add them into the test suite without having to write too much of boilerplate code. And, uh, apart from that, uh, changes of locators can also be uh, incorporated with with minimal changes using a page object model design pattern.

In order to, uh, in order to help our team members, uh, follow coding standards in Selenium projects and also ensure that the code is scalable, reliable, and, uh, follows the same, uh, coding standards, 2 things can be done. Number 1 is to, uh, provide documentation to all our developers, uh, or our team members, basically, uh, which, uh, they can, uh, read and understand and then uh, follow the testing standards. Number 2 is to provide the in code documentation and, uh, comments, uh, in the, uh, templates and example code, which, uh, can be referred to by all the developers of the test, uh, test suite, uh, for, uh, making the, uh, for for writing their additional code. In addition to that, uh, we have to ensure a strict review and, uh, merge on the on the Git repository so that all the, uh, test code merges in the, uh, in in the project first get reviewed, and then only when the, uh, testing only when the, uh, testing, uh, code has followed the coding standards, Will the code get merged into the

Uh, I'll discuss how you would mentor junior testers in automating complex test scenarios within an agile context. Uh, in an agile context, uh, to mentor a junior team member, uh, to automate, uh, complex test scenarios, couple of things can be done. Uh, the complex test scenario can be broken down into multiple, uh, less complex steps and, uh, each of which is independently developable. And, uh, the, uh, team member should be given tasks to automate those each and every independent component first, and then the, uh, components have to be integrated to, uh, to ultimately develop the testing code required for the complex test scenario. Apart from that, uh, in case where, uh, a team member is joining an existing project, they can be given, uh, the, uh, access complex scenarios have already been implemented. And, uh, using that as a a template or an example, uh, they can start developing.