Types of XPath

  1. Absolute XPath

Absolute XPaths starts with the root of the HTML pages.

Absolute XPaths are not advisable for most of the time due to following reasons

  1. Absolute XPaths are lengthier and hence they are not readable
  2. Absolute XPaths are brittle when minor structural changes are done to the web pages

Absolute XPaths shall be used only when a relative XPath cannot be constructed. (highly unlikely). Absolute XPaths tends to break as web pages/content is changed. Hence it is not recommended to use absolute XPath in Selenium.

Syntax: Absolute XPaths start with  /html

Example: /html/body/div[1]/div/div[2]/form/div[2]/input

2. Relative XPath

Relative XPaths is used for locating an element with respect to an element known as XPath. The element of your choice is referred relative to a known element.

Syntax: Relative XPaths are started with two forward slashes ‘//’.

Example: //div[@id=’divUsername’]/input

Note: Absolute XPaths are faster than the relative XPaths

3. Exact XPath

Locating elements using their attributes, values and inner text of the elements.

Why do we need to master many XPath syntaxes?

We may not be able to locate the elements directly using their unique attributes as some elements do not have unique attributes (id or name). Some attributes are dynamically changed. There could be elements without attributes. Hence we may have to locate them differently than the static elements.

XPath can be used for:

  • Locating elements with respect to a known element
  • Locating elements with partially static attribute values
  • Locating elements without attributes or without unique attributes

XPath can do bidirectional navigation (Going forward and backward)

XPath is one of most flexible and strongest location strategy and can be used for locating an element in a web page.

Using XPath for locating elements in HTML

We have our own way of introducing (explaining) XPath to the trainees in our public training programs.

When A=B and B=C. We ask the students what can be derived from these expressions. Immediately the students reply with A=C, even before the question is asked.

Then we give following two statements

  • XPath is for  locating the elements or nodes  in XML documents
  • XML and HTML has similar syntax (HTML is a subset of  XML)

Hence XPath can be used to locate elements in HTML pages (web pages).

Mastering in XPath for Selenium Test Automation


Selenium test automation engineers must be comfortable in locating elements in web pages effectively. XPath are very powerful location strategies used in Selenium as compared to other location strategies (id, name, linkText, partialLinkText and tagName )

Mastering XPath is essential for the Selenium test automation engineers to locate dynamic web elements and elements without id or name. Tagname is not a useful location strategy to locate elements as there are many elements with the same tagname. LinkText is only useful for the <a> tags only. Also, it is not useful when the visible text changes as in multilingual systems.

It is noted that most of the amateur Selenium automation engineers do not pay much attention to master location strategies. Recording and playback will not work with the applications with dynamic content. This leads to failure of test automation scripts (brittle) when web pages with dynamic contents are automated. Most of the testers rely on extracting the XPaths from browser plugins. These tools have got limitations and do not provide best values for dynamic elements. We will discuss XPath in detail with examples and explore few tools to extract XPaths automatically.

Why Do We Require TestNG In Selenium?

You have written so many automated scripts in your Testing Framework. When you wrote those scripts inside a main method. To run that particular script, you need to run main method of that particular class.

Let’s assume that we have 100 test scenarios to automate and we developed 100 test scripts using typical style of writing java codes i.e. A class with main method.

  1. If you want to run all test scripts at once, you need to create a separate runner class where you will call main method of each script class. But it will be very difficult to continue or stop script execution when some scripts fails.
  2. It is difficult to run a subset of all test scripts or you have dynamic requirements of running scrips. You manually need to write a lot of codes to handle these scenarios.
  3. Every scenarios can have same or different prerequisites and post requisites conditions. You may need to write duplicate codes repeatedly.
  4. Establishing relationship or dependencies among test scripts will not be easy task.
  5. You need to write a good amount of codes to generate a report which will say status of test run.
  6. Asserting or verifying behavior will require good knowledge of coding.
  7. Parallel testing, categorization and grouping all will require developer’s effort.
  8. If new test scripts need to be added, you might fed up in maintenance and modifications.

Above are some scenarios which need extra coding effort. Will it not be good, if you get something which can perform above scenarios and you just need to plug and use? Your problem will be solved. That something is called TestNG.

Just think what is Selenium. Selenium is also a plug and use library or API, which perform what you want like launching a browser or load a URL. You do not need to require to write the codes by your own. TestNG is also similar to Selenium. It is also a jar file, which provides you so many ready made functionalities to use.

As per TestNG official website, “TestNG is a testing framework designed to simplify a broad range of testing needs, from unit testing (testing a class in isolation of the others) to integration testing (testing entire systems made of several classes, several packages and even several external frameworks, such as application servers).”.

TestNG is a framework because it bundles a lot of functionalities in it and provides to end users. Selenium is also a framework.

How to select the right API testing tools

Selecting the right API testing tool plays an essential role in the success of a testing project. A suitable API solution can help save plenty of time and budget for the team. There are generally some options to consider:

Home-grown tools

Home-grown tools are suitable for the application that present unique testing challenges, for the team members with skills, time, and inclination to write their own test framework or build one on top of an existing open source tool. While these internal solutions can require team’s efforts to develop, they are generally programmer-friendly, precisely customized, and effectively integrated with the existing process and other infrastructure.

Open source tools

Using open source tools (JMeter, Rest-Assured) can be lightweight and appropriate for agile development. They mainly have a broad appeal, with features useful to both programmers and testers. However, not all open source tools are well documented, and training can be an issue for the testing team.

Vendor tools

Commercial tools (SoapUI Pro, Tricentis Tosca) are perceived as a safe bet as they are likely to come with available manuals, support, and training. Unfortunately, they remain some drawbacks: vendor tools are historically programmer-unfriendly as they tend to use proprietary scripting languages that programmers don’t want to spend time learning; they also tend to be heavyweight; and test scripts may be brittle, easily broken by minor changes to the application.

Particularly, these tools are generally expensive to purchase and maintain the license.

However, there are recently some vendor tools that can eliminate some disadvantages from the above vendor tools. For instance, Katalon Studio is a free tool with comparable features to commercial tools, or Postman is considered easy to setup and use compared the rest of commercial solutions. You can learn more about the top API testing tools here.

Selecting the right API testing tool is challenging but you can shortlist the choice from the candidates above considering your requirements, pros and cons of each solution — try not too ambitious at the early stage and doing the POC with the top 3 relevant solutions. You will have a better understanding of your project’s critical factors and issues to eliminate tools or fine-tune your choice to the most suitable solution for your project. Below is the top 5 API Testing Tools for 2018 (Learn more Top 10 API Testing Tools for 2018)

The interest in API testing has been trending up over the last five years, according to Google Trends. This growth possibly indicates that the demand for applying API testing has been increasing along with Agile and CI/CD adoption trends. Testing API and web services is no longer an activity taken solely by developers but gradually taken by the testing members who independently verify and validate API/services. So now it’s a good time for you to start learning API testing if you haven’t done so, it will be a valuable skillset with high demand for the future to come.

Challenges in API testing

Initial Setup of API testing

In API testing, both manual and automated testing matter. While manual testing confirms whether the app works, automated testing helps to check how effectively the app performs under pressure. Setting up the test infrastructure get it working is considered among the most challenging tasks of the testing process, as it is not only particularly tricky but also a significantly motivation-killer. However, it will be a long-term benefit once the team gets through those challenging setup process.

To avoid these challenges, teams need to start the API testing in the early stage, specifically in the design phase and make sure to conduct the interval checking of APIs for 100% uptime.

Update the Schema of API testing

The schema (data formatting which handles requests and responses for the API) should be maintained during the testing process. Any changes in the program that create additional parameters for the API calls must be reflected in the schema configuration.

In today’s API economy, the changes in API helps facilitate the demand, but those changes can cause downtime. To avoid this issue, the team needs to test the API in beta and alpha environments, which is seen to reduce 90% of the chances of issues happen.

Testing Parameter Combinations

APIs handle communication between systems by assigning data values to parameters and passing these parameters through data requests. Testing all possible parameter request combinations in the API is necessary to detect the problems regarding the specific configurations. A more significant project would end up assigning two different values to the same parameter, or create instances where numerical values appear when text values should be. Adding parameter will aggressively increase the number of possible combinations.

This challenge can be solved by picking some applications that aren’t very critical to daily operations to utilize the API and release it to those applications only. By doing this, testers can know how the API is utilized and whether there are any changes should be done for a general availability release.

Sequencing the API Calls

It is a challenge for testing teams when API needs to be in a specific order to work correctly. For instance, a call to return a user’s profile information goes through before the profile is created, the request will return an error. The process can become even more significantly difficult when involving more applications.

To help overcome this issue, a flowchart is recommended to visualize the API calls. Developers then can build and integrate API calls faster with less unexpected problems.

Validating Parameters

Software testing team may find it challenging invalidating the parameters sent through API requests because of the sheer number of parameters and use cases for those parameters. Testers need to ensure all parameter data uses the correct string or numerical data type, fits within length restrictions, fits within the designated value range and pass other validation criteria.

To solve this problem, testing team can use the continuous synthetic API monitoring to detect the problem early. Besides, it should be combined with an APM solution to get the 360-degree view.

Tracking System Integration

Ensuring the API testing system is working correctly with the data tracking system is another challenge in API testing. This integration is essential in bringing back the appropriate responses on whether a call is working properly. It is also useful in monitoring the API performance. Tracking system integration is a late stage in a whole process, which cause the team not to give it enough attention.

It can be improved by planning since the design phase to see how it will integrate with other systems. Each application has various requirements that need to be met. So, the team should not test in parallel with other critical integration systems. This can be achieved by implementing and adding load testing in the continuous delivery.

API testing best practices


When starting to develop test scenarios, some of us are relatively common to jump right into some of the negative test scenarios (to verify invalid information, validation on special characters, uncommon input, etc.). These types of verification might cause crashes and other interesting problems. In other words, easy bugs might be found quickly with negative test scenarios. Unfortunately, it is not necessarily the best use of a tester’s effort. It is suggested that mainline scenarios should be focus first with higher priority. A basic guideline is to identify the most common parameters and conditions that an end developer will use when calling the APIs and test these scenarios extensively.

Functional and Non-functional testing priorities

API is an essential part of modern web applications, its non-functional aspects such as performance, security, connectivity will affect the system heavily. The behavior makes traditional testing mindset, which focuses on functional testing first, not suitable anymore. Functional and non-functional testing should be performed at the same time with equal priority.

End-points management

A typical product may have hundreds of API/Web services endpoints, which look very similar to each other, and might cause duplication issues to the testing project. How you organize the tests and the endpoints will influence the productivity, effectiveness, and maintenance of your tests.

Test endpoints could be grouped by path (including path parameters), which generally performance action on specific object types. For examples:

api/2/issue: affects to Jira issue
   -- Create issue
   POST /rest/api/2/issue
   -- Create issues
   POST /rest/api/2/issue/bulk
   -- Get issue
   GET /rest/api/2/issue/{issueIdOrKey}


api/2/group: affects to Jira Group
   -- Create group
   POST /rest/api/2/group
   -- Get group  DEPRECATED
   GET /rest/api/2/group
   -- Remove group
   DELETE /rest/api/2/group

This method will help us preventing missing test endpoints, and test scenarios.

Endpoint as a template

This endpoint is a part of the data-driven approach, which relates to data models more than input data. One of the most challenging issues in API testing is test data mapping with data models, subsets of data models. For examples:

An API creating new Jira issue requires an input data model having required fields (such as Project Key, Summary) and non-required fields (such as Description, Assignee, etc.). All the combination of required and non-required fields should be tested to ensure that all the test scenarios are covered. For each combination, we then apply data-driven to test with different data set.

This practice suggests that we consider each combination as a test template for the endpoint, then apply data-driven approach for this test template to generate actual executable test scenarios.


The most important feature of any API test tools is the capability of the data-driven approach. Lacking data-driven ability will lead to test data hardcoded, duplicated test scripts, test verification, therefore causing massive effort at maintenance phase.

Together with data-driven, there are some important notes for test data that we should pay attention seriously: data types, blank, empty, null string. With RESTful web services, the input data is typically in JSON format, and missing value of a specific key is considered differently (null, empty) in some cases. To avoid these ambiguous test scenarios, using a subset of input data models are highly suggested.

API testing types

API testing is generally categorized into common categories below:

Validation Testing

Validation testing is among the final steps and plays an essential role in the development process. Validation test helps verify the aspects of product, behavior, and efficiency.

In other words, the validation testing can be seen as an assurance of the correct development against the stated user needs and requirements.

Functional Testing

Functional testing includes the testing of particular functions in the codebase. These features are the representation of specific scenarios to make sure the API functions are handled well within the planned parameters.

End-to-end Testing

UI testing is defined as a test of the user interface for the API and other integral parts. It is mainly about the UI functions, in which the interface is naturally graphical or rely on the command-line endpoint calls.

Generally, the test is more likely of the interface which ties into the API rather than the API testing itself. Although UI testing is not a specific test of API in term of the codebase, this still provides overview information about the health, usability, and efficiency of both front-end and back-end.

Load Testing

Load testing is generally done after a specific unit, or the whole codebase has been completed to check if the theoretical solutions work as the practical plan.

Load testing is performed to ensure the performance under both normal and at peak conditions. To do so, load testing takes on some various scenarios:

Baseline – tests the API against theoretical regular traffic that the API expects in ordinary usage;

Theoretical maximum traffic – this is to make sure during the full load periods, the solutions respond to those requests properly;

Overload test – to test the maximum capability according to the theory, then add 10-20% more on the peak traffic.  

Runtime/Error Detection

This testing type is related to the actual running of the API, particularly with the universal results of utilizing the API codebase. Generally, they focus on one of the below aspects:

Monitoring: The runtime of the compiled code is tested for different implementation errors, handler failures, and other intrinsic issues to help ensure the codebase does not contain any insecurity.

Execution Errors: The code needs to show the response to valid requests and marks the failure for invalid requests predictably and in a known way, just the same with valid requests.

Resource Leaks: The requests which are invalid or commonly illegal will be submitted to the API to test the memory, resource, data, or operation leaks/insecurities

Error Detection: The known failure scenarios will be used to test the code to make sure the errors are appropriately figured and resolved

Security Testing

Security, Penetration and Fuzz testing are the three separate elements of the security auditing process. They are used to ensure the API implementation is secure from external threats.

Besides enclosing with penetration and fuzz testing, security testing also includes additional steps like the validation of encryption methodologies, and of the design of the access control for the API. It also contains the user rights management and validating authorization checks to access the resources.

Penetration Testing

Penetration testing is considered the second test in the process if auditing. In this testing type, the users with limited API knowledge will try to attack to assess the threat vector from an outside perspective, which is about functions, resources, processes, or aim to the entire API and its components.

Fuzz Testing

Fuzz testing is another step in the whole security audit process. In this testing type, a vast amount of random data (referred to as “noise” or “fuzz” ), will be input into the system with the aim to try a forced crash or any negative behavior. This fuzz test will help test the API in term of the limits to prepare for the “worst case scenarios.”

Advantages of API testing

As discussed above, API testing is an important activity that testing teams should focus on. It offers a number of advantages over other kinds of testing:

  • Language independent:

Data is exchanged via XML and JSON, so any language can be used for automation, independent from the languages used to develop the application. XML and JSON are typically structured data so the verification is fast and stable. There are also built-in libraries to support comparing data using these data formats.

  • GUI independent

We can perform API testing within the application prior to GUI testing. Early testing will get feedback sooner and improve the team’s productivity.

Core functionality can be tested to expose small errors and to evaluate a build’s strengths.

  • Improved test coverage

Most API/services have specifications, allowing us to create automated tests with high coverage, including functional testing (happy cases, negative cases) and non-functional testing. With virtual user techniques, we rarely find API test cases that could not be automated.

  • Faster releases

It is common that executing a UI regression test suite takes 8-10 hrs while the same scenario with API testing takes only 1-2 hours. The flakiness of API testing is also lower than that of UI testing. All these allow us to release faster with API testing.