Selenium Interview Questions and Answers - PART 2

1. WebDriver is interface or class?

• WebDriver is an interface in Selenium.

2. If we do not add a driver exe file what will happen and what kind of exception will be generated?

• If the driver executable is not added, Selenium won't be able to communicate with the browser, and a WebDriverException will be thrown.

3. What is the difference between close and quit?

• close(): Closes the current browser window.
• quit(): Closes all the browser windows and ends the WebDriver session.

4. Difference between get and navigate().to() ?

• get(): Loads a new web page in the current browser window.
• navigate().to(): This does the same as get() but allows for additional navigation options like back, forward, and refresh.

5. Difference between findElement and findElements?

• findElement: Returns a single WebElement or throws  NoSuchElementException if not found.
• findElements: Returns a list of WebElements. If no elements are found, it returns an empty list.

6. How do you get all the links on the current page? Which locator will you use other than XPath?

• You can use the CSS selector a to find all links.

List<WebElement> links = driver.findElements(By.cssSelector("a"));

7. Methods of WebDriver?

• Some common methods are: get() , getCurrentUrl() , getTitle(), findElement() , findElements() , getPageSource() , close() , quit(), navigate() , manage() .

8. What is the use of the getCurrentPageSource method?

• It returns the source code of the current page.

9. When do we go for the findElements method and what is the return type?

• Use findElements when you expect multiple elements. It returns a list of WebElements.

10. Why do we get WebDriverException?

• This exception is thrown when WebDriver is unable to interact with the browser. Possible reasons include incorrect WebDriver setup, browser crashes, or network issues.

11. Absolute and Relative XPath?

• Absolute XPath: Starts from the root and follows a complete path (e.g., /html/body/div ).
• Relative XPath: Starts from the middle of the HTML DOM structure (e.g., //div[@id='example'] ).

Interesting aspects of API testing

1. Security Testing: Identifying vulnerabilities and ensuring secure data transmission.
2. Performance Testing: Measuring API response times, throughput, and scalability.
3. Functional Testing: Verifying API endpoints, request/response formats, and business logic.
4. Usability Testing: Ensuring API documentation, error handling, and user experience are intuitive.
5. Penetration Testing: Simulating attacks to identify vulnerabilities and weaknesses.
6. Fuzz Testing: Sending invalid or malformed requests to test API robustness.
7. Load Testing: Simulating high traffic to ensure API performance under stress.
8. API Gateway Testing: Testing API gateways, like AWS API Gateway or Azure API Management.
9. Microservices Testing: Testing APIs in microservices architecture, ensuring seamless communication.
10. CI/CD Integration: Automating API testing in continuous integration and continuous deployment pipelines.

Reducing API Latency and Improving Response Times

1. Caching: Implement caching mechanisms, like Redis or Memcached, to store frequently accessed data.
2. Content Delivery Networks (CDNs): Use CDNs to distribute content across multiple servers, reducing the distance between users and data.
3. Optimize database queries: Use efficient database queries, indexing, and connection pooling to reduce database latency.
4. Code optimization: Optimize code, use efficient algorithms, and minimize computational complexity.
5. Parallel processing: Use parallel processing techniques, like multi-threading or async processing, to handle requests concurrently.
6. HTTP/2 and HTTP/3: Upgrade to newer HTTP protocols, which provide improved performance and multiplexing capabilities.
7. Serverless architecture: Consider serverless architectures, like AWS Lambda, to reduce server overhead and latency.
8. Load balancing: Use load balancers to distribute incoming traffic across multiple servers, reducing the load on individual servers.
9. Monitoring and analytics: Use tools like New Relic, Datadog, or Prometheus to monitor performance and identify bottlenecks.
10. Continuous optimization: Regularly review and optimize API performance, as changes in usage patterns or data can impact response times.

HTTP Cookies vs Sessions vs Tokens – Web Authentication & Authorization Explained

HTTP cookies:

• HTTP cookies are small pieces of data that are sent by the server to the client, and stored by the browser.
• They can be used to store user preferences, track user behavior, or maintain user sessions.
• For authentication and authorization, cookies can store a unique identifier that links the user to a server-side record of their credentials and roles.
• The browser sends the cookie back to the server with every request, so the server can verify the user's identity and permissions.
• However, cookies have some drawbacks, such as being vulnerable to theft, forgery, or cross-site scripting attacks, and being limited by size and number.

HTTP sessions:

• HTTP sessions are a way of maintaining stateful communication between the client and the server, despite HTTP being a stateless protocol.
• Sessions use cookies or other methods to store a session ID on the client side and associate it with a server-side data structure that contains the user's information and state.
• Sessions can store more data than cookies and can be more secure if the session ID is encrypted or regenerated frequently.

HTTP tokens:

• HTTP tokens are another way of implementing stateless authentication and authorization, without relying on cookies or sessions.
• Tokens are self-contained pieces of data that encode the user's identity, permissions, and other claims, and are signed by the server using a secret key or a public-private key pair.
• Tokens are sent by the server to the client, and stored by the browser in local storage or memory.
• The client sends the token back to the server with every request, and the server validates the token's signature and payload.
• Tokens can be more flexible, portable, and scalable than cookies or sessions, and can support cross-domain and cross-origin requests.

Cookie-based vs Token-based authentication:

• Cookie-based and token-based authentication are two common approaches to implementing web authentication and authorization, and each one has its own pros and cons.
• Cookie-based authentication relies on the server to manage the user's session and state and uses cookies to store and transmit the session ID.
• Token-based authentication relies on the client to store and transmit the user's information and claims and uses tokens to encode and sign them.
• Cookie-based authentication can be simpler to implement, more compatible with browsers, and easier to revoke.
• Token-based authentication can be more efficient, secure, and flexible, and support more scenarios and platforms.

How to choose the best method

• When deciding which method is the best for web authentication and authorization, there is no definite answer as it depends on various factors such as the type, size, and complexity of the web application, the security and performance requirements, user experience and expectations, and available technologies and standards. Generally speaking, cookies should be used if stateful communication between the client and server is needed or if existing browser features and frameworks that support cookies are to be leveraged. Tokens should be used if stateless communication between the client and server is necessary or if cross-domain and cross-origin requests need to be enabled. A combination of cookies and tokens can be used to achieve a balance between statefulness and statelessness or to enhance the security and functionality of your web application.
• Stateless Protocol does not require the server to retain the server information or session details. Stateful Protocol requires the server to save the status and session information.

Understanding HTTP Headers: Types, Examples & Their Role in Web Communication

HTTP Request and Response objects consist of a body and header. While the body in the Response holds the data message (HTML, JSON) or form fields in the Request, the headers let the client and the server pass essential information about each other.

Headers can be grouped into four categories by their context:

• General headers contain information that is relevant for both request and Response, but no information about the data in a body.
• Request headers hold information about the client and requested resources.
• Response headers include server details, like time, location, and configuration.
• Entity header informs the browser about the type and body of the resource.

Let’s inspect more in detail. Go to the webpage https://madurai.nic.in/, open the console > Network tab, and select the document to inspect headers. You will likely see the headers divided into General, Request, and Response.

General group consist of the following information:

• Request URL: https://madurai.nic.in/wp-admin/admin-ajax.php
• Request Method: POST
• Status Code: 200 OK
• Remote Address: 164.100.225.214:443 (The IP address of the server)

Request Headers include the following properties:

• Accept: / (Accept any content type)
• Accept-Encoding: gzip, deflate, br, zstd (An algorithm, such as compression that is used on the recourse sent back.)
• Accept-Language: en-US, en (Hints the server about the expected language)
• Connection: keep-alive (Controls how long connection should stay open)
• User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 (Lets server to identify the characteristics of the application, OS, vendor, and versions)

Response Headers include:

• Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 (Set the instruction for caching. Other setting types: no-cache, no-store, no-transform)
• Content-Encoding: Specifies the compression algorithm used for the response body
• Content-Length: 17 (The size of the recourse in bytes)
• Content-Type: application/json; charset=UTF-8 (The resource type received. The current type is a JSON document.)
• Date: Tue, 09 Jul 2024 06:57:27 GMT (The time when the message was created)
• Expires: Wed, 11 Jan 1984 05:00:00 GMT (Sets the date when the relevant content will no longer be new/fresh)
• Server: Specifies the software used by the server at the time of the sent Response