Most Frequently Asked Questions during QA Automation Interview

About this doc..

This document is created with the intent of helping QA professional for interview questions related with Automation Testing, Selenium Web-driver, API Testing and some other basic questions asked frequently along with solution and example. This is the initial version and it will be improved over time and more and more questions will be added in it. Please add your questions and suggestions in the comments section.

This post covers topics on Automation Framework design  Automation concepts, selenium-webdriver, API Testing etc.

Table of Contents:

Title ............................................................................... Page No.

Table of Contents: 1

Most Frequently Asked Automation Questions: 2

What are Page objects and what are its advantages: 2

Selenium webdriver: 3

Following keywords are used for handling alert related objects: 3

Example showing how to handle frames on a webpage: 3

Switching to Frame: 3

Implicit and Explicit Wait. What are they and whats the difference. 4

Working with objects with changing values/property at runtime or Dynamic Objects: 5

Identifying the dynamic objects using the following methods: 5

What is difference between soap and Rest API:
How to design automation framework or What are different kind of Automation frameworks which can be used for automation.? 7

                  

What are Page objects and what are its advantages:

The main advantage of Page Object Model is that if the UI changes for any page, it don’t require us to change any tests, we just need to change only the code within the page objects (Only at one place). Many other tools which are using selenium, are following the page object model.

Within your web app’s UI there are areas that your tests interact with. A Page Object simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place.

Advantages:

There is clean separation between test code and page specific code such as locators (or their use if you’re using a UI map) and layout.

2. There is single repository for the services or operations offered by the page rather than having these services scattered throughout the tests.

Selenium webdriver:

Following keywords are used for handling alert related objects:

To accept Alert:

Alert alert=driver.switchTo().alert();

System.out.println(alert.getText());

alert.accept();

alert.accept

alert.getText

alert.sendkeys

alert.dismiss()

alert.notify() Will wake up the thread which depend on this. This thread should be the owner of object else it will throw exception “Illegalmonitorstateexception”.

Example showing how to handle frames on a webpage:

Switching to Frame:

public void switchToERCFrame(){

                        switchToInstallFrame();

                        WebElement frameERCs = driver.findElement(By.id("wdsFrame"));

                        driver.switchTo().frame(frameERCs);

            }

How to locate and Click on object inside Context-Menu of a page:

Steps

First identify the main object in context menu for eg “user-management.-> CreateUser” is context menu. When user hovers the mouse over user-management link then it displays the context menu with option like CreateUser, update, delete and search users.

For Automation of step “User move mouse over User-Managment link and then click on Create_User in the context menu following code illustrate how to do it using Web_driver (python script, similar in java code also)

Then move to element  main-object

Action.perform  (will move the mouse over user management and click on it)

Again identify/Locate the sub-obj in context menu and move to sub object using actions move to element

Action.perform               

Using ActionChain

# Below steps for locating and moving to a context menu on page for eg.: User-management menu.

actions =  ActionChains(self.driver);

mainMenu = self.driver.find_element_by_id("administrationMenu")

actions.move_to_element(mainMenu)

actions.perform()

time.sleep(2)

# Below steps for locating and moving to Create-user in context menu.

#actions =  ActionChains(self.driver)

submenu = self.driver.find_element_by_id("usersListMenu")

actions.move_to_element(submenu).click()                           

actions.perform()

         

Implicit and Explicit Wait. What are they and what’s the difference.

Implicit waits are used to provide a default waiting time between each consecutive test step/command across the entire test script. Thus, subsequent test step would only execute when the specified amount of time have elapsed after executing the previous test step/command.

Explicit waits are used to halt the execution till the time a particular condition is met or the maximum time has elapsed. Unlike Implicit waits, Explicit waits are applied for a particular instance only.

Working with objects changing values at runtime or Dynamic Objects:

For eg: if the object is located next to some label then it can be used to locate the dynamic obj.

//label1/following::input

 

Identifying the dynamic objects using the following methods:

1. Absolute XPath

Xpath Position or Absolute Xpath are most frequently used to resolve the dynamic element issues. Only problem with using XPath locators is that they are very fragile. They are most prone to breakage in case of change in web page. This factor could get worse exponentially as the test suite size and complexity increases. Below is an example of Absolute XPath and XPath Position

web_element_name=html/body/div[30]/div[2]/div[2]/div/div/div/div[1]/table/tbody/tr/td[2]/table/tbody/tr/td[1]/table/tbody/tr/td[1]/table/tbody/tr[2]/td[2]/em/button

//p[6]/label[2]/div/ins

2. Identify Element by starting Text

If the dynamic elements have a definite pattern to them, then we can also use JavaScript functions like “starts-with” or “contains” in our element locators to separate the dynamic part of locator from static part.

For example, in case of dynamic submit button Id example which we discussed earlier, we can apply ‘starts-with’ function to access this locator irrespective of its dynamic part.

XPath: //button[starts-with(@id, 'Submit-')]

3. Identify Element by containing Text

Similarly, in some scenarios where dynamic element is surrounded by a static value, we can use ‘contains’ function. For example we have following element locators…

<input class="new-userfield-001">

<input class="old-userfield-002">

As we can see ‘usefield’ part of element is static, so we can apply ‘contains’ function to access this element locator as shown below…

XPath: //input[contains(@class, 'suggest')].

4. Identify Element by Index

If there are multiple elements present on page with same locator then we can use following Java code in our selenium WebDriver script to interact with element of particular index.

driver.findElements(By.xpath(“//*submit”)).get(0).click();

5. Identify Element with reference of a closest stable element:

We can use the DOM structure to find the closest stable element first and then this stable element can be used as a reference element to find the required element.

XPATH: //span1/../following-sibling::div//button1

DOM structure could be found using Firefox extension like Firebug and FirePath. But in complex and large applications this approach is difficult to use because of large DOM structure.

6. Identify Element by stable preceding Text

Following method can be used for locating element which has changing attribute or dynamic properties and it doesn’t have any pattern or contains fix values. Where we cannot use startswith or contains.

Here we can locate the the element using static element nearby the object.

For web elements like text field and text areas we can identify them by using the stable text labels nearby. This approach might not be possible in all scenarios but it does resolve the dynamic element issues where possible. Example of this approach is shown below.

//label1/following::input

How to do right-click using selenium webdriver??

builder.contextClick(R1).sendKeys(Keys.ARROW_DOWN).sendKeys(Keys.ENTER).perform();

About Web Services:

Some common question for about Web Services. There is given frequently asked Web Services interview questions and answers that has been asked in many companies

1) What is Web Service?

Web Service is a software system for communicating two devices over the network.

2) What are the advantages of web services?

    Interoperability: By the help of web services, an application can communicate with other application developed in any language.

    Reusability: We can expose the web service so that other applications can use it.

    Modularity: By the help of web service, we can create a service for a specific task such as tax calculation etc.

3) What are the different types of web services?

There are two types of web services:

    SOAP

    RESTful

4) What is SOAP?

SOAP stands for Simple Object Access Protocol. It is a XML-based protocol for accessing web services.

5) What are the advantages of SOAP web services?

    WS Security

    Language Independent

    Platform Independent

6) What are the disadvantages of SOAP web services?

    Slow

    WSDL Dependent

7) What is WSDL?

WSDL stands for Web Services Description Language. It is a xml document containing information about web services such as method name, method parameter etc.

8) What is UDDI?

UDDI stands for Universal Description, Discovery and Integration. It is a XML based framework for describing, discovering and integrating web services. It contains a list of available web services. WSDL is the part of UDDI.

9) What is RESTful web services?

REST stands for REpresentational State Transfer. It is a architectural style. It is not a protocol like SOAP.

10) What are the advantages of RESTful web services?

    Fast

    Language Independent

    Platform Independent

    Can use SOAP.

    Allows different data format.

What is difference between soap and Rest API:

No.	SOAP	REST
1)	SOAP is a protocol.	REST is an architectural style.
2)	SOAP stands for Simple Object Access Protocol.	REST stands for REpresentational State Transfer.
3)	SOAP can't use REST because it is a protocol.	REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
4)	SOAP uses services interfaces to expose the business logic.	REST uses URI to expose business logic.
5)	JAX-WS is the java API for SOAP web services.	JAX-RS is the java API for RESTful web services.
6)	SOAP defines standards to be strictly followed.	REST does not define too much standards like SOAP.
7)	SOAP requires more bandwidth and resource than REST.	REST requires less bandwidth and resource than SOAP.
8)	SOAP defines its own security.	RESTful web services inherits security measures from the underlying transport.
9)	SOAP permits XML data format only.	REST permits different data format such as Plain text, HTML, XML, JSON etc.
10)	SOAP is less preferred than REST.	REST more preferred than SOAP.

Why API testing or Advantage of API testing?

• Testing Complexity is Reduced:  
•  By isolating a component from the rest of the application test preconditions are greatly reduced making it easier to write tests, and quicker to run them.
• Testing without Source Code:
•  Third party libraries are often delivered in binary form without source code. API testing allows the correct performance of the object code to be confirmed.
• Negative and Error Testing
• Often it is difficult or impossible to cause error conditions in a completely integrated system. API testing allows error conditions to be easily injected by controlling all inputs to the component.
• Testing is Easily Automated
• Because APIs can be controlled with scripted or compiled test code, it is much easier to automate tests.
• API testing uncovers the issues faster then GUI testing. Issues are uncovered at early stage.
• API Testing is language and platform independent. The response is returned either in xml or json irrespective of underlying language used for coding.
• API testing can be performed even when UI is not ready and this also uncovers the potential issues at the earlier stage, which reduces the cost and effort for fixing these issues.
•  Basic functionality is tested at logical layer. It test many functions and parameters which might not be available when testing on gui.

 

Difference between RPC (Remote procedure call) and Rest API.

The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients:

·         Clients are required to know procedure names;

·         Procedure parameters order, types and count matters. It's not that easy to change procedure signatures(number of arguments, order of arguments, argument types etc...) on server side without breaking client implementations;

·         RPC style doesn't expose anything but procedure endpoints + procedure arguments. It's impossible for client to determine what can be done next.

·         etc...

On the other hand in REST style it's very easy to guide clients by including control information in representations (HTTP headers + representation). For example:

·         It's possible (and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs;

·         Client implementations do not need to depend on particular procedure names and arguments. Instead, clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats (e.g. Atom, HTML, Collection+JSON, HAL etc...)

·         It's possible to easily change URIs without breaking clients as far as they only depend on registered (or domain specific) link relations;

·         It's possible to embed form-like structures in representations, giving clients the possibility to expose these descriptions as UI capabilities if the end user is human;

·         Support for caching is additional advantage;

·         Standardised status codes;

There are many more differences and advantages on the REST side. 

REST vs RPC

REST is not a framework like WCF, a protocol like HTTP, a framework like JAX-RS, or a communication format like SOAP.  REST is an architecture, a structured way of representing a software solution - specifically, exposing aspects of a solution to a set of remote client-consumers.  The central tenet of REST is that these aspects of a solution can be modeled as resources which the client can consume or act upon.  

This resource-oriented thinking, and not the implementation details of how one communicates between client and server, is what REST is actually all about.  This is the key difference that separates actual RESTful APIs from RPC based on HTTP verbs.

Why is this important?

The RESTful approach enables us to model our domain objects as consistent, hierarchical URLs with predictable semantics mapping (loosely) to CRUD.  As well, HTTP comes with standard error codes, MIME types and generally does most of the heavy lifting, so we benefit from not needing to maintain a thick user-developed protocol stack that is subject to frequent modification.

Consider the following example of HTTP APIs that model orders being placed in a restaurant.  

• The RPC API thinks in terms of "verbs", exposing the restaurant functionality as function calls that accept parameters, and invokes these functions via the HTTP verb that seems most appropriate - a 'get' for a query, and so on, but the name of the verb is purely incidental and has no real bearing on the actual functionality, since you're calling a different URL each time.  Return codes are hand-coded, and part of the service contract.
• The REST API, in contrast, models the various entities within the problem domain as resources, and uses HTTP verbs to represent transactions against these resources - POST to create, PUT to update, and GET to read.  All of these verbs, invoked on the same URL, provide different functionality.  Common HTTP return codes are used to convey status of the requests.

Placing an Order:

• RPC:  http://MyRestaurant:8080/Orders/PlaceOrder (POST: <Order OrderNumber="asdf"><Appetizer><Appetizer><Entree>Tacos</Entree><! --Rest of the order--></Order>)
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (POST: <Order><Appetizer><Appetizer><Entree>Tacos</Entree><! --Rest of the order--></Order>)

Retrieving an Order:

• RPC:  http://MyRestaurant:8080/Orders/GetOrder?OrderNumber=asdf (GET)
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (GET)

___________________________________

Different Ways to Design A Framework

• Test Script Modularity Framework

• Data-Driven Automation Frameworks

• Keyword-Driven Automation Framework

• Hybrid Test Automation Framework

Test Script Modularity Framework

• Builds a abstraction layer in front of a component

to hide the component from the rest of the

application.

• Done by creating small, independent scripts.

• Each script represent modules, sections, and

functions of the AUT.

• Small scripts can be combined to from larger tests

• Results in high degree of modularization and

maintainability.

Data-Driven Automation Frameworks

• Test input and output values are read from

data files (ODBC sources, CVS files, Excel files,

DAO objects, ADO objects.

• These values loaded into corresponding

variables in captured scripts.

• Test flow navigation coded into test script.

• Thus script is just a "driver," or delivery

mechanism, for the data.

Keyword-Driven Automation Framework

• Requires the development of data tables and

keywords, independent of the test automation

tool.

• Essentially represents a manual test case as a

series of keywords or actions.

• In a keyword-driven test, the functionality of the

application-under-test is documented in a table

as well as in step-by-step instructions for each

test.

Hybrid Test Automation Framework

• Combination of all of the above techniques, pulling from

their strengths and trying to mitigate their weaknesses

• Allows data driven scripts to take advantage of the

powerful libraries and utilities in a keyword based approach

• The framework utilities can make the data driven scripts

more compact and less prone to failure.

• The utilities can also facilitate conversion of existing scripts

to keyword driven equivalents.

• On the other hand, the framework can use scripts to perform some tasks that might be too difficult to re- implement in a pure keyword driven approach.