In my automation framework, I have used several Object-Oriented Programming (OOP) concepts to design a scalable, maintainable, and reusable structure.

Encapsulation

Encapsulation is achieved by creating POJO (Plain Old Java Object) classes where we define private variables and provide public getter and setter methods to access or modify those variables. We use access modifiers like private, public, protected, and default to restrict or allow access to class members. This helps in data hiding and ensures a controlled access mechanism.

Inheritance

Inheritance allows a class (child) to inherit fields and methods from another class (parent). In the framework, we typically create a BaseTest or BasePage class with common functionality (like driver initialization, setup/teardown, logging, or wait mechanisms), which is then extended by all test or page classes. This promotes code reuse and improves maintainability.

Polymorphism

Polymorphism in the framework is implemented in two ways:

1. Method Overloading (Compile-Time Polymorphism): This involves having multiple methods with the same name but different parameters (either in type, number, or sequence). It is commonly used in utility classes like waitForElement(By locator) and waitForElement(WebElement element).
2. Method Overriding (Runtime Polymorphism): This occurs when a subclass provides a specific implementation of a method that is already defined in its superclass. It allows dynamic method binding and is useful when extending base classes such as BaseTest or BasePage.

Abstraction

Abstraction is about hiding the internal implementation details and exposing only the necessary functionalities. It is implemented through both:

1. Abstract Classes (Partial Abstraction): Abstract classes can have both abstract and concrete methods. All classes that extend an abstract class must implement its abstract methods. This is useful for enforcing a common structure across different page or test components.
2. Interfaces (Full Abstraction): Interfaces contain method declarations without implementations (all methods are abstract by default in interfaces). Any class implementing an interface must provide the implementation for all its methods. This approach helps in loose coupling and supports dependency inversion principles.

In my project, I frequently used method overriding to implement runtime polymorphism and provide specific behavior in subclass implementations while maintaining a common interface from the parent class.

For example, in a test automation framework I developed, I created a base class called Browser with a method launch() that sets up browser configurations. Then, I created subclasses like ChromeBrowser and FirefoxBrowser that override the launch() method to handle browser-specific setup details.

This approach allowed me to write flexible and reusable code where I could treat all browser instances polymorphically, like:

Even though the reference type is Browser, the overridden launch() method in ChromeBrowser gets executed at runtime.

Using method overriding helped in extending the framework easily to support new browsers without modifying existing code, thereby following the Open/Closed Principle. It also simplified maintenance and enhanced code readability.

Polymorphism is one of the core principles of object-oriented programming. The term means 'many forms', and it allows objects to be treated as instances of their parent class, even if they behave differently.

There are two main types of polymorphism in Java:

1. Compile-time Polymorphism (Static Polymorphism):

This occurs when method overloading is resolved during compile time. In this case, multiple methods in the same class have the same name but differ in parameters (type, number, or order).

Example:

The correct method is chosen at compile time based on the arguments.

2. Runtime Polymorphism (Dynamic Polymorphism):

This happens when method overriding is resolved during runtime. A subclass provides its own implementation of a method that is already defined in its superclass.

Example:

Here, although the reference type is Animal, the actual object is Dog, and the overridden method in Dog is executed at runtime.

Polymorphism promotes code flexibility, scalability, and reusability, making it easier to extend and maintain applications.

Approach of the program:

1. Initialising the input string "user name"
2. Converting to lowercase to ensure case-insensitive comparison. (toLowerCase() method)
3. Initialise a counter variable, vowelCount is then initialised to track the number of vowels.
4. Execute a for loop with the length to input String
5. Get every character from a string using the charAt Method.
6. Add a condition if the character is one of a,e,i,o,u . Then increase the vowelcount by one
7. Print vowel count

In my current project, I’ve worked with Postman, Rest Assured, and SoapUI, depending on the type of API and testing needs.

1. Postman – I mainly use Postman for manual API testing and quick validations during development. It’s great for sending different HTTP requests (GET, POST, PUT, DELETE), setting headers, query parameters, and writing automated test scripts in the Tests tab using JavaScript. I also use collections and environments to organize tests and run them in bulk using Newman for CI.

2. Rest Assured – For automated API testing in Java, I use Rest Assured integrated with TestNG or JUnit. It’s powerful for writing clean, maintainable test scripts and validating responses using assertions. I’ve built API test suites where requests and validations are fully automated and integrated with our Selenium UI tests.

3. SoapUI – I’ve used SoapUI for testing SOAP-based web services. It allows importing WSDL files and automatically generating requests. I used it to validate XML responses, apply XPath assertions, and perform data-driven testing using Excel and properties files.

Each tool has its strengths. For example, Postman is great for exploratory testing, Rest Assured is ideal for automation and integration, and SoapUI is perfect for legacy or SOAP services.

"A 503 status code means Service Unavailable.

It indicates that the server is currently unable to handle the request, typically due to being overloaded, down for maintenance, or temporarily unavailable.

This is a server-side error, and it’s often temporary. The server might return a Retry-After header to suggest when the client should try again.

For example, if I send a request to an API during server maintenance, I might get a 503 response. It tells me the server is reachable but not ready to process requests at that moment.

In testing, if I encounter a 503, I usually check server logs, deployment status, or load balancer health to identify if it’s a temporary issue or a deeper infrastructure problem."

"In API testing, success status codes indicate that the request was processed correctly by the server. Some of the most common success status codes are:

1. 200 OK – This means the request was successful and the server returned the expected response. It’s commonly used with GET, PUT, or DELETE methods. For example, if we send a GET request to /users/1, and the user exists, we’ll receive a 200 status with user details in the response body.
2. 201 Created – This is used when a new resource has been successfully created. It’s mostly associated with POST requests. For example, when we create a new user by sending a POST request to /users, if everything is correct, we get a 201 response along with the details of the newly created user, sometimes including a location header.

Other common success codes include:

1. 204 No Content – The request was successful, but there’s no response body (common with DELETE).
2. 202 Accepted – The request is accepted for processing, but the processing isn’t completed yet (used in async APIs)."

In Postman, we commonly use four main HTTP methods when testing RESTful APIs:

1. GET – This method is used to retrieve data from a server. It’s read-only and doesn’t change anything on the server. For example, fetching user details from /users/1.

2. POST – POST is used to create new resources on the server. For example, when we send a POST request to /users with a JSON body, a new user is created.

3. PUT – PUT is used to update an existing resource. It usually replaces the entire resource with the data sent in the request. For example, updating a user's profile using /users/1.

4. DELETE – This method is used to remove a resource from the server. For example, deleting a user using the endpoint /users/1.

In Postman, I use these methods along with headers, body, and parameters to validate API responses, status codes, and payloads.

In my current project, we're using a custom hybrid automation framework built with Selenium WebDriver, integrated with TestNG as the test runner and Maven for build management.

The framework follows the Page Object Model (POM) design pattern to enhance code reusability and maintainability. All page interactions are separated from test logic, which makes our tests cleaner and easier to maintain.

For reporting, we’re using ExtentReports, and test data is handled using Excel files with Apache POI, depending on the scenario. We’ve also integrated the framework with Jenkins for CI/CD, so tests run automatically on every build.

We use log4j for logging, and WebDriverManager to manage browser drivers dynamically, which helps with cross-browser testing.

Overall, the framework is modular, scalable, and well-suited for both functional UI testing and regression testing.

In Cucumber, we often use Scenario Outlines with Examples tables for data-driven testing. But when we have a large amount of test data or want to maintain it externally, I prefer using Excel files.

To achieve this in a Java-based framework, I use Apache POI to read the Excel data. In the step definitions, I pass a row number or some identifier from the feature file, then dynamically read the corresponding data from Excel at runtime.

Example:

in the feature file, I’ll write a Scenario Outline with just a row number. The step definition then reads that row from the Excel sheet to get the username and password.

This approach helps keep the feature files clean and lets the QA or BA teams manage test data easily in Excel without editing the code.

It also allows greater flexibility and reduces redundancy in tests, especially when working with complex datasets.

Gherkin uses a few key keywords to structure scenarios in a Feature file. These keywords are part of the Given-When-Then syntax, which is central to Behavior-Driven Development (BDD). Each keyword helps define a specific step in the scenario, which is later linked to executable code in Step Definitions.

Gherkin Keywords:

1) Feature:

Purpose: Describes the feature or functionality being tested. It provides a high-level description of what the system is supposed to do.

2) Scenario:

Purpose: Represents a specific test case that describes a particular behavior of the system. A feature can have multiple scenarios.

3) Given:

Purpose: Describes the initial context or pre-condition for the scenario. It sets up the state of the system before an action is taken.

4) When:

Purpose: Describes the action or event that triggers a change in the system’s state. It represents what the user does in the scenario.

5) Then:

Purpose: Describes the expected outcome or result after the action has taken place. It defines the expected behavior after the "When" action.

6) And:

Purpose: Used to chain additional conditions or actions in Given, When, or Then steps. It helps combine multiple conditions or results into a single step.

7) But:

Purpose: Similar to And, but it’s used to introduce an exception or a negative condition. It is often used to describe an exception to the rule.

8) Background:

Purpose: Defines common preconditions for all scenarios in the feature. It is executed before each scenario and is useful for setting up a shared context for multiple scenarios.

9) Examples:

Purpose: Used in Scenario Outline to provide multiple sets of test data for a single scenario template. It allows running the same scenario with different values.

For Example: