≡ Menu
Joe Colantonio – Selenium-UFT-QTP-SoapUI-ALM-LoadRunner & more

UFT – What is an API test type?

UFT – What is an API test type? post image

The UFT API Testing Manifesto

This is an excerpt from my book “The UFT API Testing Manifesto” that I’m trying to complete. Still not sure if I should just blog the whole book, make the book available as a free PDF or sell it on Amazon. Let me know what you think I should do.


What the Heck is UFT?

Good question. In previous releases HP had separate products for functional testing. QuickTest Professional (QTP) was used for testing GUI applications, and Service Test was for testing non-GUI technologies. HP’s latest test tool release — Unified functional Testing (UFT) — combines both products and features a frontend that merges the separate tools into one common user interface.

When creating a new test script in UFT, the user is given a choice between creating either a GUI Test (Formally known as QTP) or API Test (Formally known as Service Test).


UFT also allows the user (with a proper license for each piece) to integrate steps from GUI, API and LoadRunner into one test script. The ability to call and pass data from one test type to another enables the user to create end-to-end testing solutions.

These tests can also be saved and run from HPs Application Lifecycle Management (ALM — also known as Quality Center). With ALM integration one also has the ability to create Business Process Tests.

What is API testing?

Application Programming Interface (API) is a specification that acts as an interface for software components. Where most functional testing involves testing a user interface like a web page or a .NET form–API testing involves bypassing a user interface and communicating directly to an application by making calls to its APIs.

API testing allows the user to test headless technologies like JMS, HTTP Databases.and Web Services (FYI: ApI testing also replaced the Web Service Add-In that was previously available in QTP)

Also API testing allows the user to create custom code in C# to achieve custom functionality. We’ll take a deeper look into this concept in later chapters.

Headless testing

Most headless testing consists of bypassing the GUI and sending a request directly to an applications backend or service, and receive a response back, validating the response to make sure things are working as one expects them to.


The above example is often referred to as client/server relationship. A client makes a request by asking for a resource and the request goes out to find the server that will fulfill the request. The server locates the desired resource and then sends a response back to the client.

Why is API testing Important?

With Agile development becoming the standard in most organizations, the ways in which we develop software and automate tests have changed dramatically.

Pre-Agile, most of the time spent on automation was done against a graphical user interface (GUI). This is the piece that HP GUI Test handles. But if you’ve been doing automation for any length of time you know how time consuming, fragile and hard- to-maintain these types of tests are. Entire books have been written on how organizations have invested large sums of money into creating custom functional GUI test automation frameworks, only to become frustrated with their reliability over time; to the point where people stop using it and the software becomes shelf-ware.

Also, GUI tests that go against a user interface tend to take a long time to run. For certain Agile practices like continuous builds, when new code is checked in, the amount of time it take to get feedback from a GUI regression suite of tests is unacceptable. In those case quicker feedback is needed.

The sooner bugs are found the better, since a developer instantly knows the code changes they made have broken the build and need to be looked at. In test-driven processes, users need a large percentage of a test sets to run fast and frequently, and must be able to integrate it into the development lifecycle.

Don’t get me wrong — GUI testing is still very important; it’s the only test type that truly tests how a user will experience an application during production. Certain defects can only be caught by GUI tests. In other words, while it’s crucial, GUI should not be the only type of automation a user focuses on, nor should it be the biggest piece of the total amount of automated tests that one creates.

All the reasons I just listed have given test automation a reputation for being unreliable and not worth the effort to create. Right about now you might be thinking, “This stinks! Isn’t test automation a core agile practice??” No worries! Luckily, the type of automation Agile focuses on is Unit testing (and the more reliable API lower level testing) and less on GUI automation.

In his book, Agile: Software Development Using Scrum author Mike Cohn introduces the concepts of a test automation pyramid:


This image represents the opposite of the way most non-agile development teams perform automated testing.

GUI Test

GUI testing focuses on testing an application user interface to make sure that its functionality is correct. IDE GUI testing is at the top of the pyramid and represents a small piece of the total number of automation tests types that should be created.

Unit Test

Unit testing makes up the largest section of the pyramid, forming a solid base. A Unit test is created to verify a single unit of source code like a method. By doing this developers can isolate the smallest testable parts of their code. Unit tests are the easiest to create and yield the biggest “bang for the buck.” Since unit tests are usually written in the same language that an application is written in, developers should have an easy time adding them to their development process.

Service – API Test

The middle Service layer is the “sweet spot” that UFT API Testing was created for. Service testing is also known as integration testing. Integration testing focuses on verifying that the interactions of many small components can integrate together without issue. Since API tests bypass the user interface they tend to be quicker and much more reliable than a GUI test.

And most importantly — since API test do not rely on a IDE to be ready they can be created early in the development cycle. Bonus — API tests (as I will try to demonstrate in the example in this book) are actually much easier to create then GUI tests!

For more check out my upcoming book The UFT API Testing Manifesto

UPDATE (8/4/2013): My book The UFT API Testing Manifesto has been released!

My first ever book “The UFT API Testing Manifesto – A step-by-step, hands-on testing guide for the masses” is finally available! Grab your copy now:

20 comments… add one

  • Mark

    Hi Joe,

    Thanks for your explanation regarding API testing
    I just installed Unified functional Testing (UFT) two days ago, and starting to get familiar with the new interfaces and also the new features like API testing.

    BTW, you should definitely sell your “The UFT API Testing Manifesto” book on Amazon and also provide it for the Kindle. I’ll buy a copy.

    Mark

    • Mark » Thanks Mark – I’m actually still editing the book. Due to time I had to scale back the scope of it and probably will make it available for free soon :)

  • ravi kumar

    Please let us know your book is completed or not

    • ravi kumar » Still working on it. Should be done soon. If you are on my email list you will get an update as soon as its released.

  • Siva

    Hi Joe,

    Learnt a lot through your blog. Waiting for your book release

    Thanks,
    Siva

  • David Clutton

    We are just starting out with ALM/QC 11.0 and UFT 11.5 Thank you very much for the OTA information. I also would be happy to purchase the book. Seems like you should get a return on all the effort.

    • Thanks David! Believe it or not I finally finished the UFT API Manifesto guide and it should be available on Amazon by next week.

  • Alan Carda

    Glad to hear the UFT API manifesto guide is nearly ready to go!

    We’ve been using QTP for years, hoping to be able to convert a large portion of our testing to GUI/API hybrid. So far (1 week in), passing data into a called API test is a bear. Looking forward to your insights.

    • Thanks Alan for your support! My first ever book “The UFT API Testing Manifesto – A step-by-step, hands-on testing guide for the masses” is finally available! Grab your copy now.

      You can download it for free thought Amazon’s KDP Select program starting this Monday August 5th till midnight (PST) on Wednesday the 7th.

  • Salai

    Hi joe,
    Is it possible to validate the API response (SOAP/REST) services in QTP XML Checkpoint. If yes, please provide some details how to explore.

    • Not sure how to do this in QTP ( it has really bad support for API testing in general) I know it is possible to create REST checkpoints in UFT API testing

  • Anjali

    I think the best blog I have read giving the clearest picture of UNIT Testing and Integeration testing in all perspectives.

  • Andrea

    Joe, I want to thank you for your blog and book. It’s been of great help and very valuable in helping me with API testing. As always, your knowledge is greatly appreciated.

    Andrea

  • vinod

    Hi Joe,

    Wen we try to associate a GUI test to the API test, and run, UFT seems to have closed/crashed.

    Any suggestions?

  • vinod

    Hello Joe,

    Wonderful explanation, and thanks a ton for sharing the information.
    If the book is available for download plz provide me the link.

  • naga

    Hi Joe,

    It was quite interesting to know this UFT what ever u have provided info..Thanks dude.If possible can u plz release the next version, am ready to know.

    Regards
    Naga

    • Hi Naga – I’m currently working on a second edition. It should be done and released soon – available for purchase on amazon and pdf version.

Leave a Comment