Checkpoints in QTP/UFT with Example

What is a Checkpoint in UFT/QTP?

A checkpoint in UFT/QTP is a verification point that compares the current value of a specified object property, page attribute, or data source with an expected value captured earlier in the test. If the current and expected values match, UFT records a PASS status; if they do not, it records a FAIL status.

Checkpoints convert a script that merely replays actions into a script that verifies outcomes. A recorded script can complete every step successfully even when the application under test shows the wrong text, the wrong image, or a corrupted database record — a checkpoint is what catches that difference and reports it.

Why Use Checkpoints in Test Automation?

Recording a script only replays a sequence of clicks and keystrokes; it never confirms whether the application produced the correct result. Checkpoints close that gap by turning each recorded action into a testable assertion with a measurable outcome.

• Convert playback into verification, so every run produces a clear PASS or FAIL instead of just a completed script.
• Catch regressions early, before a defect reaches a build that testers assume is stable.
• Validate data that is invisible during manual observation, such as XML payloads, database rows, or hidden object properties.
• Document expected behaviour, so anyone reading the script understands what “correct” means for that step.

Because checkpoints run automatically on every execution, they remove the need for a tester to manually inspect each screen after every cycle, which is what makes UFT/QTP practical for repeated regression testing across builds.

Types of Checkpoints in UFT/QTP

UFT/QTP provides several checkpoint types so a tester can validate the exact aspect of the application that matters at a given step — a static property, a block of text, a bitmap image, a database record, or an entire XML document. Choosing the type that matches the object under test keeps a step focused and easy to maintain.

1. Standard Checkpoint: Compares the expected values of object properties captured during recording against the object’s current values during a run session. It is supported by every add-in environment.
2. Page Checkpoint: A Standard Checkpoint created for a web page. It checks the total number of links and images on the page and can measure page load time.
3. Text Checkpoint: Verifies that specific text appears within a defined area of a web page or a Windows-based application.
4. Text Area Checkpoint: Verifies that a text string is displayed within a defined screen area of a Windows-based application, according to criteria such as match case or wildcard matching.
5. Bitmap Checkpoint: Checks the bitmap of an image or an entire web page with a pixel-by-pixel comparison between the actual and the expected image.
6. Image Checkpoint: Checks properties of a web image, such as its source file location. Unlike a Bitmap Checkpoint, it does not compare pixels.
7. Accessibility Checkpoint: Verifies compliance with World Wide Web Consortium (W3C) guidelines for web-based technology, making it easier for people with disabilities to use the application.
8. Database Checkpoint: Runs a query at record time and stores the returned database values as expected values; the same query runs again at run time so the actual and expected values can be compared.
9. Table Checkpoint: Dynamically checks the contents of cells in a table or grid, along with table properties such as row height and cell width. It is similar to a Database Checkpoint.
10. XML Checkpoint: Verifies XML data, XML schema, and XML resources embedded in a web page or in a standalone .xml document.

The table below compares the ten checkpoint types side by side, so you can pick the right one before you start recording.

Checkpoint vs Output Value: What Is the Difference?

Testers new to UFT/QTP often confuse checkpoints with output values, because both are inserted from the same menu and both read a live property from an object. The two features serve opposite purposes.

Use a checkpoint whenever the script needs pass/fail evidence, and an output value whenever a later step needs the captured data as an input.

How to Insert a Checkpoint in UFT/QTP

Most checkpoint types can only be inserted while UFT is recording; once recording stops, the checkpoint menu becomes unavailable for new insertions. The steps below insert a Standard Checkpoint, the type used most often.

Click here if the video is not accessible

1. Open the application under test and start recording in UFT.
2. Navigate to the screen or object to verify, then right-click the step immediately after which the checkpoint belongs.
3. From the context menu, choose Insert Standard Checkpoint, or pick a specific type — Bitmap, Database, Table, and so on — from the Checkpoint submenu.
4. In the Checkpoint Properties dialog box, keep the default checkpoint name or replace it with a descriptive one.
5. Select the object properties to verify. Each selected property is marked with a check; the ABC icon marks a constant value, and the icon changes if the property is parameterized.
6. Click OK. UFT inserts a Check statement immediately after the current step.
7. Stop recording and replay the test to confirm the checkpoint reports PASS.

⚠ Common error: If the step immediately before the checkpoint closes or replaces the window it targets, UFT throws a run-time error because the object no longer exists when the checkpoint tries to read it. In HP QTP, reordering the affected steps so the target object is still open when the checkpoint executes is usually enough to fix it.

The VBScript excerpt below shows the same idea expressed through the UFT automation object model: a Check statement that returns a Boolean, which the script then reports through the Reporter object.

Dim Result ' Holds the PASS/FAIL outcome of the checkpoint

Browser("Flight Reservation").Page("Flight Reservation").WinEdit("Agent Name:").Set "Diana"
Browser("Flight Reservation").Page("Flight Reservation").WinButton("OK").Click

' Run the Standard Checkpoint that was inserted after the OK click
Result = Browser("Flight Reservation").Page("Flight Reservation").Check(CheckPoint("Flight Reservation Window"))

If Result Then
    Reporter.ReportEvent micPass, "Checkpoint Passed", "Flight Reservation window matches expected values"
Else
    Reporter.ReportEvent micFail, "Checkpoint Failed", "Flight Reservation window does not match expected values"
End If

This video demonstrates the different checkpoint types available in UFT/QTP, including standard, bitmap, and database checkpoints in action.

Best Practices for Using Checkpoints Effectively

A checkpoint is only as reliable as the object and property it targets. The practices below keep checkpoints accurate as the application under test changes.

• Check the specific object, not the whole page, to avoid brittle tests that fail on unrelated UI changes.
• Keep the checked object open when the checkpoint executes; reordering a step is often the fix for the “object not found” run-time error described above.
• Prefer Database or XML checkpoints over Bitmap checkpoints for data validation — bitmap comparisons break on font, resolution, or theme changes that have nothing to do with the data.
• Parameterize checkpoint values from a data table when the same check needs to run across multiple test iterations.
• Name every checkpoint descriptively so a failure is easy to locate in the Test Results window.
• Pair checkpoints with synchronization, such as a Wait statement or the Sync method, so a check never runs before the page finishes loading.

FAQs