UFT API Negative Testing HTTP 500 Errors
I recently was asked by a co-worker (Sreevani) how to use Service Test 11.20 to test for HTTP Error 500 returned from a REST service.
My first suggestion for testing HTTP 500 errors
My first suggestion was to say, “Sure. All you need to do is use the HTTP request’s checkpoints status code. Set the status code to equal the expected Value 500. Turn off the service, run the test and it should pass.” That advice however, would have been wrong. As you can see below, the test actually fails when this approach is used:


</h2
When you think about it, Service Test is behaving as you would expect when an HTTP error code 500 is received. Service Test fails the test because it expects a valid response back from the service (like 200). The HTTP 500– Internal Server Error is a general “catch all” error that means something has gone wrong.
That’s how positive testing should work–checking that the service does what it was designed to do without any errors. In this case, however, we need to do some negative testing.
Negative Testing UFT API
Negative testing is used to verify that the service did not perform a task it was not designed to perform. In this case, we need to verify the status code 500, and if it finds the expected error code 500, pass the test. (When testing SOAP web services in ST 11.20 there is an actual setting–“Fault is expected”–that allows you to do this.)

Unfortunately, this option is not available when testing a REST service.
Fault is expected when testing a REST service
My second instinct was to tell the engineer that this could be handled using custom code. To my embarrassment, however, I didn’t know what the exact syntax should be. After trying everything I could think of, I was stumped. Luckily, a developer on the project pointed us to the args.ExecutionResult object, which allowed us to tell Service Test to pass if it received a failure:
if ( args.ExecutionResult.Status == STExecutionStatus.ApplicationUnderTestFailure)
args.ExecutionResult.Status = STExecutionStatus.Success;
Place this code in the HTTP request’s AfterExecuteStepEvent Event.


Lesson Learned
The above is yet more proof that “developers are your friends!”
Joe Colantonio is the founder of TestGuild, an industry-leading platform for automation testing and software testing tools. With over 25 years of hands-on experience, he has worked with top enterprise companies, helped develop early test automation tools and frameworks, and runs the largest online automation testing conference, Automation Guild.
Joe is also the author of Automation Awesomeness: 260 Actionable Affirmations To Improve Your QA & Automation Testing Skills and the host of the TestGuild podcast, which he has released weekly since 2014, making it the longest-running podcast dedicated to automation testing. Over the years, he has interviewed top thought leaders in DevOps, AI-driven test automation, and software quality, shaping the conversation in the industry.
With a reach of over 400,000 across his YouTube channel, LinkedIn, email list, and other social channels, Joe’s insights impact thousands of testers and engineers worldwide.
He has worked with some of the top companies in software testing and automation, including Tricentis, Keysight, Applitools, and BrowserStack, as sponsors and partners, helping them connect with the right audience in the automation testing space.
Follow him on LinkedIn or check out more at TestGuild.com.
Related Posts
Bottom Line: Kobiton is the first real device testing platform I’ve seen that makes AI-powered mobile testing feel like it […]
Look, most of the AI testing tools I cover on the TestGuild Automation Podcast share two things in common: they’re […]
At least one in five people has some kind of impairment, so it’s important to have them in mind when […]
Last Updated: April 18, 2026 By Joe Colantonio — 25+ years in testing, 500+ podcast interviews with tool creators Full […]



