Going POSTal! Discover WebAPI Testing in QF-Test

With QF-Test 10, the testing of web interfaces has been fundamentally revised, with a focus on web APIs such as REST, SOAP and other web services. In this special webinar, we will introduce you to the new functions.

Materials:

• QF-Test WebAPI Preview
• Demo suite and presentation slides (Requires QF-Test 10 or QF-Test WebAPI Preview)

---

Summary

With the upcoming QF-Test version 10, web application and web API testing have been fundamentally redesigned. A major focus of this release is on Web APIs such as REST, SOAP, and other web-based services.

Testing APIs differs significantly from traditional GUI testing. While QF-Test still supports visual test nodes, script nodes are often needed to simulate realistic workflows. Complex test logic can be wrapped in reusable procedures, making it easy to maintain and scale even sophisticated tests.

After the introduction, Thomas hands over to his colleague Plamen Vesselinov, who presents the new features live in action.

Introduction to Web API Testing

Plamen begins by explaining the difference between GUI testing and API testing. Up to now, QF-Test has primarily been used to automate user interfaces — clicking buttons, entering text, and verifying visible changes. In contrast, Web APIs communicate directly via the network, exchanging data through HTTP requests, most commonly in JSON format (though XML and other formats are also supported).

For example: A client application can query a server for user information via an API by providing an ID. The server responds with the requested data. Using a PUT request, this data can then be modified.

Demo: Using the New Web Request Node

Plamen then demonstrates the new Web Request node introduced in QF-Test 10. This node is designed specifically for API testing and allows users to configure and send HTTP requests directly from within QF-Test.

He uses a simple REST service — a sample Pet Store API — to illustrate:

1. A POST request adds a new pet (“Wolf”) to the store.
2. A PUT request updates the pet’s name.
3. A GET request retrieves the updated information.

QF-Test logs each step in detail: the exact request sent, the response received, the status code, and the full JSON content. A status code of 200 indicates success.

QF-Test 10 also introduces syntax highlighting for JSON and XML bodies and supports custom HTTP headers such as Content-Type and Accept.

Pre- and Post-Request Handlers

For more advanced scenarios, QF-Test provides Pre-Request and Post-Request Handlers. These allow users to modify a request before it is sent or process a response after it is received.

Typical use cases include:

• Setting authentication credentials
• Adjusting request headers
• Automatically verifying response content

Handlers are executed in a defined order: Global handlers run first, followed by local handlers defined within the test case itself.

Test Cases, Variables, and Assertions

Next, Plamen presents a complete test suite that adds several pets using different data sets. The suite uses a data driver so that the same test case can be executed multiple times with varying input values.

The Assertion API (rc.check) enables checks and validations without interrupting the test flow if one fails. All results are documented clearly in both the execution log and the HTML report.

QF-Test 10 adds convenient Copy buttons in the report and log views, making it easier to extract large JSON bodies or specific sections for debugging.

Scripting and Technical Background

Under the hood, QF-Test uses the java.net.http package from the Java Development Kit to handle web requests. This means that standard Java methods and classes are directly available within QF-Test scripting environments (e.g., Groovy).

Scripts can be used to:

• Loop through data
• Dynamically set variables
• Parse responses
• Implement custom checks

All related classes and objects (Request, Response, rc.web, rc.check, etc.) are documented in detail in the QF-Test manual.

Authentication

QF-Test 10 natively supports several authentication schemes in its Web Request node:

• Basic Authentication
• Bearer Token Authentication
• API Key Authentication

These credentials can be supplied either through HTTP headers or URL parameters. Sensitive information (such as tokens) can be encrypted or hidden from logs and reports.

SOAP Example

In addition to REST APIs, QF-Test also supports SOAP web services. Plamen demonstrates this using a simple Calculator service that adds two numbers. The SOAP request includes an XML body and a SOAPAction header.

If the service responds successfully (status 200), QF-Test displays the result. If not, the system issues a warning rather than failing the test, since the problem is likely with the demo service itself.

Proxy and Certificate Management

QF-Test provides extensive options for:

• Proxy configuration (HTTP/S),
• Cookie management, and
• Certificate handling, including client certificates.

By default, QF-Test accepts all SSL certificates, but this can be customized. There is also a built-in procedure that allows testing Web APIs with client-side certificates.

To observe live network traffic, Plamen recommends using a MITM proxy. Such a proxy can be integrated with QF-Test, allowing users to watch HTTP requests and responses as they happen.

Future Outlook

The QF-Test team is continuously expanding the Web API testing capabilities. Planned features include:

• Support for WebSockets,
• Additional authentication mechanisms,
• Enhanced response validation tools, and
• More pre-built procedures within the webapi package.

Conclusion

Thomas Max concludes the session by thanking all participants. The QF-Test team welcomes feedback, questions, and feature requests and encourages attendees to reach out via email after the webinar.