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.
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 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 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!
My book The UFT API Testing Manifesto has been released!