API Testing

API Testing

API stands for Application Programming Interface. API enables two separate software system to communicate with each other. API contains methods and routines used by the system that other systems call and get the result to consume in the own system.

API testing is totally different from GUI Testing and it focuses on Applications business logic layer.  This testing does not care about the look and feel of the application.

Setup of an API Environment:

Usually, setting up the API Test Environment is not that easy because it doesn’t involve any user Interface.  You need to configure the environment based on the application requirements. You need to study the web service document provided by developers and then design the setup. Using API code, you should make the specific call to API and consume the output for doing verification or other depended API calls.Output could be status (say OK or Error) or any kind of Data (object id) that to call another API method.

Ideally API should catch and handle the problem instead of just failed. If the input is not correct it will let you know the status with great detail like ‘Incorrect request” etc. In a very easy way, I can say, you send a request message to web services and after processing, web service sends you back a response based on that input. It could be ‘Bad Request’ if the message sent incorrectly and contains response in a specific structure based on the architecture of the web services. This response should contain enough information to understand the output and correct if there is some problem with the request.

To understand the API call, let’s see a basic example;

Consider, API functions, which are for an e-commerce web service cart web services;

AddItemToCart(ItemType item, float price, int count)

Once you look at the method, AddItemToCart, you need to pass an item of type ‘ItemType’, price in ‘float’ and count of items in ‘int’ data type to add items to the cart. The output should capture all output message and you need to parse them and get the desired response.

Approach to API Testing:

For say, if you going to test end to end scenario for a purchasing an item, you would be using few API calls.

  1. AddItemIntoCart()
  2. Checkout(), if Item added to Cart.
  3. MakePayment() if you are able to add the item to checkout step.
Based on output response of each API method you proceed to the Next.

API Test Tools:

There are various free and paid tools available in the market, which are specifically designed to test various API for the database application, mobile apps, desktop apps etc. You can download free tools as an extension or as standalone and access web services via the tool. These tools can emulate all or part of the environment in which the API would typically operate. It is not necessary that the tool can emulate all the API calls you need, but I am sure you will find the tool that can do most as per your need. SOAPUI, POSTMAN, Parasoft soaTest are few tools, which you can try.

Read More

Dark side of a Software Development Engineer in Test (SDET)

A lot of people have an opinion that a software development engineer in test is a more difficult, more responsible, more skilled position than that of an automation QA engineer who is actually just a ‘tester’. It’s because the SDET is almost a software developer: he deeply knows programming languages, design patterns, algorithms. He can create a high-quality, maintainable, and performant code. He creates tools for automated testing, writes his own frameworks – such kind of work is more complicated and, therefore, should be better-paying. That’s why many automation test engineers like to name themselves an SDET, alluding to their high skills and value.

Sure, everything said above is true, if and only if the SDET also has a deep knowledge of software testing methodologies and APPLIES it to his work. Unfortunately, in real life you can see the following situation:

There are two QA teams on a project – manual testers and automation testers (who proudly consider themselves SDETs). The manual team creates a set of test cases and passes them to the auto-team for automation. The automation team develops its own framework, converts the test cases to automated ones, writes test scripts, and runs them.

As you can see, there are two different roles: 1 – the team of high skilled manual testers who write test cases and are responsible for the product quality, 2 – high skilled developers who convert manual test cases to automated scripts. Obviously, the manual test cases and the programming code will be much qualitative in terms of an architecture and design.

But, there are also some cons:

When the automation team receives manual test cases as an input and produces automated scripts as an output only, it means that the team is not responsible for the product quality. It’s because they cannot be responsible for the product test coverage, test strategy, or test design quality – they do not do this. And it also means that the AUTO-TEAM is the only one in the project who IS NOT RESPONSIBLE FOR THE PRODUCT QUALITY!!! And therefore it is not motivated to give the product of high quality. Their goal is tons of test reports marked ‘passed’.

Simple example. Assume there is a defect found in the production branch.

Customer: why has it happened and who is responsible for that?
Manual QA: I created a fine test case that covers everything you need, including the found defect. Then I passed the test case to the automation team. They converted the test case and ran it.
Automation QA: I covered all the requirements and all are reports are green (all the tests are passed).
Customer: But there is a defect!
Manual QA: If you run my test cases manually, you will catch the defect.
Automation QA: Our tools cannot catch such kind of bugs and It’s not my fault that the manual QA did not foresee that and did not provide a more suitable scenario. All my scripts exactly repeat the test cases, every single step.

To avoid a problem similar to the one described above, the SDET must have and apply his/her knowledge of manual software testing. He must be at the heart of the software development process as the customer’s advocate. In addition, he must be responsible for the product quality. So, any SDET must have a very deep knowledge of manual testing and preferably some working experience in this position. Sure, now he does pure automation and writes the code like a developer but he also must take part in the development of the test strategy, create his own test plans and test cases and be responsible for his part of the work.

If you hear someone calling himself an SDET, whereas his function is limited to the development of testing tools, you should know that this person must have come to the software testing from the development field (or always dreamt to be a developer but lacks qualification) and has an insufficient knowledge of software testing and reluctance to study it.

So, make your own conclusions but note that everything written above is only my personal opinion.

Read More

Smart click (part 1)

When using the Selenium Webdriver tool for testing web-based applications, I faced a problem: sometimes the common Click() method does not work for specific elements. Or, for example, it may work fine in the FF browser and fails to click in Internet Explorer. After a little investigation, I noticed that instead of the Click() method I can use methods from the Actions class, or I can click elements with JavaScript. But I also discovered that I have to use one action for FF and another for IE – often an action worked with one browser but failed with the other. I had to add extra logic for specific elements and it began spreading some mess in my code.

Then a couple of months later “funny” things started to happen regularly. Guys from Mozilla Corp. or Microsoft delivered a new version of their browser. The old version of Selenium Webdriver didn’t support this new browser, so I had to upgrade it to the latest one. But oops… most of my specific clicks turned out to work conversely. Or did not work at all, and I had to return to the common Click() method. Chaos in my code was about to come.

That’s why I started looking for a method that would work consistently with any browser, webdriver, or elements and would also give me some additional helpful features like events logging with screenshots, handling exceptions, coded-behind verification, etc. Finally, I realized I had to invent it myself.

I asked myself what I do when I click a web element (assume a button) in a browser manually and came up with the following list:

  1. I determine what the button I am going to click.
  2. I am sure if I can click the button. I check if it is present on the page, is displayed, is enabled for a click, etc. In other words, I verify conditions for a successful click.
  3. Then I click the button.
  4. I verify that click has been successful, that some changes has occurred – expected or not – even if I’ve got an error, it means that the click itself has happened. So, I verify conditions after the click.

I do all the thing from the list above unconsciously. So does everyone else.

So I decided to write my own version of the Click() method reproducing all my manual actions for clicking a button in real life. Here is the recipe:

If you have separate classes for different types of web elements in your testing framework, such as buttons or links, you can add the method Click() to this class(es) and use a private IWebElement instance defined inside the class for interactions. For example:

public class WebButton
{    
    private IWebElement element;
    public WebButton(/*constructor parameters*/) 
    {
        element = //instance of IWebElement according to constructor parameters
        //bla-bla
    }

    public void Click(/*possible parameters*/)
    {
        //logic for clicking the element in a smart way
    }
}

If you use an ordinary IWebElement interface for describing web elements, you can create an extension method for the interface. Like this:

public static class Extensions
{
    public static void Click(this IWebElement buttonToClick, /*possible parameters*/)
    {
        //logic for smart click on buttonToClick
    } 
}

You will be able to invoke the methods in your tests in this way:

//1st case
WebButton button = new WebButton(/*constructor parameters*/);
button.Click();

//2nd case
IWebElement button = driver.FindElement(By.Id("buttonID"));
button.Click();

 

 

Read More