UFT – What is an API test type?

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 can 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 application's backend or service and receiving a response back, validating the response to ensure things are working as one expects them to.

The above example is often referred to as a 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 sends a response back to the client.

Why is API testing Important?

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

Pre-Agile, most of the time spent on automation was 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 takes to get feedback from a GUI regression suite of tests is unacceptable. In those cases, 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 set 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 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 how most non-agile development teams perform automated testing.

GUI Test

GUI testing focuses on testing an application user interface to ensure 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 test types that should be created.

Unit Test

Unit testing makes up the largest pyramid section, 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” for which UFT API Testing was created. Service testing is also known as integration testing. Integration testing focuses on verifying that the interactions of many small components can integrate 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!

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: (I stopped selling this book because it was out of date. I'm working on a newer version.)

You can view my newer course version of the API book on Pluralsight. 

Amazon Kindle Version