Reporter.ReportEvent in UFT/QTP with Example

What Is Reporter.ReportEvent in UFT/QTP?

Reporter.ReportEvent is a standard method built into UFT/QTP (now sold as OpenText/Micro Focus UFT One) that writes a custom, human-readable message directly into the test results window. Unlike the automatic pass or fail verdicts that built-in checkpoints generate, a ReportEvent call lets the tester decide exactly what gets logged, when, and how it should be labeled.

This HP QTP tutorial demonstrates the use of the function Reporter.ReportEvent and Results Formatting. The tutorial asks you to build a short script, and completing that scripting exercise is the fastest way to see custom reporting update the Results tree in real time.

Click here if the video is not accessible

Reporter.ReportEvent matters most in automation because a script usually runs unattended, on a schedule or inside a CI/CD pipeline. The run results file becomes the only record of what happened, so a step that fails silently, or passes without explanation, makes debugging much harder later. Adding an explicit ReportEvent call after a critical action turns the Results tree into a readable, step-by-step audit trail that a tester, developer, or manager can review without opening the script itself.

This is different from an object checkpoint, which UFT generates automatically and reports using its own default step name. Reporter.ReportEvent instead lets you attach business-meaningful language, such as “Order confirmation displayed” rather than a generic “Check Point Pass on WebEdit object,” which is far easier for a non-technical stakeholder to read in the final report. The method works the same way whether the script targets a web page, a Windows desktop application, or a mainframe terminal, since Reporter is a global object rather than a property of any one test object.

Guru99’s UFT/QTP series covers this method right after If, Else, and Exists statements, because most Reporter.ReportEvent calls sit inside a conditional block that decides whether the outcome should be reported as micPass or micFail.

Reporter.ReportEvent Syntax and EventStatus Values

You can use Reporter.ReportEvent to report custom test steps in Micro Focus UFT’s test results tree. The method accepts three required arguments and one optional argument, in a fixed order, as shown below.

Reporter.ReportEvent EventStatus, ReportStepName, Details [, ImageFilePath]

EventStatus sets the icon and color shown for the step and can flip the overall run status; ReportStepName is the short label that appears in the Test Results tree, generally written as the expected result; Details holds the longer description, typically the actual result observed; and the optional ImageFilePath attaches a screenshot captured earlier in the script to that specific step.

Each constant can also be passed as its numeric value instead of its name, so Reporter.ReportEvent 1, “Step”, “Detail” behaves exactly like Reporter.ReportEvent micFail, “Step”, “Detail”. Using the named constant is easier to read in a script that another tester will maintain later.

A script commonly nests several ReportEvent calls inside one action: a micDone entry before an action starts, one micPass or micFail entry for the key check, and additional micWarning entries for anything unusual noticed along the way.

• When test cases are executed using automation tools, it can be difficult for certain users to understand the raw test results. You can use results.xml to create an XSL file that presents the test results the way you prefer.
• You can also use VBScript library functions to store the results in an xls or a text file for reporting outside UFT.

How to Use Reporter.ReportEvent: Practical Examples

Knowing the syntax is one thing; seeing it inside a real script is what makes the four status constants click. The example below wraps a check inside an If…Then…Else statement, then reports a pass or a fail with Reporter.ReportEvent so the outcome appears in the Results tree exactly where a reviewer expects it.

If Browser("Guru99 Demo").Page("Guru99 Demo").WebButton("Login").Exist(5) Then
    Reporter.ReportEvent micPass, "Login button check", "Login button was found on the page"
Else
    Reporter.ReportEvent micFail, "Login button check", "Login button was not found on the page"
End If

This mirrors the pattern shown in Guru99’s VBScript conditional statements tutorial, where an If…Then…Else block chooses between two outcomes; the only difference here is that each branch also calls Reporter.ReportEvent to log the result.

Use micDone for a step that is purely informational, and micWarning when something looks unusual but should not fail the run outright. The next snippet logs a data-entry step as Done, then flags a slow response as a Warning and attaches a screenshot using the optional ImageFilePath argument.

Reporter.ReportEvent micDone, "Enter search text", "Typed 'UFT tutorial' into the search box"
errorImage = "C:\Results\SearchDelay.png"
Browser("Guru99 Demo").CaptureBitmap errorImage, True
Reporter.ReportEvent micWarning, "Search response time", "Results took longer than 5 seconds to load", errorImage

Keep ReportStepName short and keep Details specific about the actual result. A reviewer scanning hundreds of logged steps after a failed overnight run should be able to tell what happened without opening the script itself, and a consistent naming pattern across every action makes that scan much faster.

Teams that call ReportEvent from many scripts often move this logic into a shared VBScript function, such as LogStep(status, name, details), so every script produces a consistent Results tree without repeating the same If…Then block.

Reporter Object Properties: Filter, ReportPath, and RunStatus

Reporter.ReportEvent is not the only member of the Reporter object. Three additional properties give extra control over what the results contain and where UFT stores them, and they show up frequently in production automation frameworks.

Reporter.Filter accepts four values: 0 or rfEnableAll shows every event and is the default; 1 or rfEnableErrorsAndWarnings hides passed steps; 2 or rfEnableErrorsOnly hides both passed steps and warnings; and 3 or rfDisableAll turns off result logging entirely. Checking Reporter.RunStatus mid-script lets a test branch its own logic, for example skipping the remaining steps in an action once an earlier step has already failed.

Because ReportPath and RunStatus are read-only, you cannot assign a value to them; use them to read information about the current run, for example writing the results folder path to a log file at the start of a script, or short-circuiting a long action after a fatal failure. Reading these properties adds negligible overhead, so it is safe to check Reporter.RunStatus after every major step in a long regression suite without slowing the run down in any noticeable way.

Best Practices for Reporter.ReportEvent in UFT

A few habits keep custom reporting useful instead of noisy.

• Reserve micFail for real failures: Every micFail call flips Reporter.RunStatus, so using it for cosmetic issues hides genuine defects later in the same run.
• Write ReportStepName like an expected result: A reviewer should understand the check from the step name alone, without reading the Details column.
• Capture screenshots only on failure: Passing ImageFilePath on every single step fills the results folder quickly and slows the run down for little benefit.
• Filter noisy runs: Set Reporter.Filter to rfEnableErrorsAndWarnings for scheduled or CI runs so passed steps do not bury the failures that matter.
• Centralize the logic: Wrap Reporter.ReportEvent calls inside a reusable action or function library so every script in the suite logs results the same way.
• Export for non-technical readers: Combine results.xml with a custom XSL when stakeholders outside the QA team need to review outcomes without opening UFT.

FAQs