In the realm of automated software testing, the efficacy of a test script is defined not merely by its ability to perform actions, but by its capacity to verify outcomes. Within the Micro Focus Unified Functional Testing (UFT), formerly known as QuickTest Professional (QTP), checkpoints serve as the critical "truth-tellers." They are the mechanism by which developers and quality assurance engineers bridge the gap between expected behavior and actual runtime execution. By comparing the current state of an object against a predefined baseline, these checkpoints determine the final PASS or FAIL status of any given test case.
Understanding the Core Functionality of Checkpoints
At its most fundamental level, a checkpoint is a validation step. It acts as a gatekeeper in your automation suite. Without these verification points, an automation script might click buttons, enter data, and navigate menus—but it would have no objective way of knowing if the application under test (AUT) responded correctly.
In our ongoing series regarding UFT/QTP training, we have previously explored the Expert View and the Step Generator. Today, we turn our focus to two of the most frequently utilized validation tools: the Standard Checkpoint and the Image Checkpoint.
The Standard Checkpoint: The Bedrock of Verification
The Standard Checkpoint is the workhorse of the UFT library. It is designed to verify the property values of objects within the application, such as edit boxes, buttons, tables, or static text.
Key Characteristics
- Object Property Validation: It specifically targets the internal attributes of an object (e.g., text, visibility, enabled status).
- Runtime Comparison: During execution, it compares the current runtime value of the property against the value captured during the recording or design phase.
- Flexible Implementation: These checkpoints can be inserted during the initial recording session or added retroactively while editing an existing script.
- Active Screen Utility: UFT allows for the use of the "Active Screen" to facilitate the insertion of these checkpoints. However, a critical prerequisite exists: the Active Screen must have captured sufficient information about the object in question. If the object was not interacted with during the initial recording, the Active Screen may lack the necessary object metadata to define a checkpoint.
- Repository Integration: Once a checkpoint is created, it is automatically saved to the local Object Repository, though it can be migrated to a Shared Object Repository for enterprise-level scalability.
Practical Scenario: Validating UI State
Imagine a login module consisting of a Username field, a Password field, and three buttons: "Login," "Cancel," and "Help." A common requirement is to ensure that the "Cancel" button is visible to the user. By applying a Standard Checkpoint to the "Visible" property of the "Cancel" button object, the test script will automatically evaluate whether the UI is rendered as intended. If the button is hidden, the script will record a failure, alerting the QA team to a potential UI rendering defect.
Chronology: How to Insert a Standard Checkpoint
To ensure accuracy in your automation suite, follow this standardized workflow for implementing Standard Checkpoints.
During Recording
- Initiation: Start your recording session in UFT.
- Accessing the Tool: Navigate to the Insert menu and select Checkpoint, or click the specific Standard Checkpoint icon in the toolbar.
- Selection: A list of relevant checkpoints will appear based on the current context. Choose "Standard Checkpoint."
- Targeting: The UFT interface will temporarily hide, allowing you to select the target object in your AUT.
- Definition: Once selected, the Checkpoint Properties dialog box opens. Here, you define which property (e.g., Name, Value, Text) to monitor.
- Parameterization: You may choose to use a constant value or link the property to a data source (parameterization) for data-driven testing.
- Timeout Setting: An often overlooked feature is the "Timeout" parameter. This tells UFT how many seconds to wait for an object to reach the desired state before declaring a failure—an essential feature for handling dynamic web elements that may take time to load.
During Editing
If you are modifying an existing test, you can right-click any object within the Active Screen and select "Insert Standard Checkpoint." Alternatively, you can use the Insert menu while in the Keyword View. This flexibility allows engineers to refine their verification strategy as the application evolves without needing to re-record entire user flows.
The Image Checkpoint: Beyond Textual Data
While Standard Checkpoints verify properties, Image Checkpoints focus on the visual integrity of the application. In modern web development, icons, logos, and status indicators are vital to the user experience.
Unique Capabilities
An Image Checkpoint is a specialized derivative of the Standard Checkpoint. While it shares the same underlying architecture, it includes a specific "Compare Image Content" feature. When enabled, UFT performs a pixel-by-pixel comparison between the baseline image stored during creation and the image displayed during runtime.
Strategic Use of Image Verification
This is particularly useful for detecting visual regressions. For example, if a "Status" icon changes from green (active) to red (error), a standard property check might not catch the nuance if the underlying object ID remains the same. An Image Checkpoint, however, will detect the difference in appearance and flag it as a discrepancy.
When the test results are generated, UFT provides a visual diff, displaying both the expected and actual images side-by-side, which significantly accelerates the debugging process for QA analysts.
Supporting Data and Technical Nuances
Managing Checkpoint Properties
Checkpoint properties are not static. They can be modified at any point in the development lifecycle via three primary methods:
- Initial Definition: During the creation process.
- Keyword View: By right-clicking the checkpoint step and selecting "Checkpoint Properties."
- Object Repository: By navigating to the object in the repository tree and accessing its properties directly.
The Role of Add-ins
It is important to note that the effectiveness of these checkpoints is heavily dependent on the loaded Add-ins. Whether you are testing a Java-based application, a SAP GUI, or a standard web browser, ensure the appropriate Add-in manager settings are configured. If the Add-in for a specific technology is not loaded, UFT will be unable to "see" the object properties, rendering the checkpoint ineffective.
Implications for Quality Assurance
The implementation of robust checkpoints has profound implications for the software development lifecycle (SDLC):
- Shift-Left Testing: By integrating checkpoints early in the development phase, bugs related to UI layout and object interaction are caught before the application reaches staging.
- Reduced Manual Overhead: Automated verification replaces the need for manual sanity checks, allowing the QA team to focus on exploratory testing and edge-case analysis.
- Data-Driven Accuracy: With the ability to parameterize checkpoint values, teams can run a single test script across thousands of different user scenarios, ensuring that the application behaves consistently across diverse data sets.
- Maintenance: Because checkpoints are stored in the Object Repository, they are easily maintained. If a developer changes an object’s ID or name, you only need to update the repository once, and all associated checkpoints will be updated automatically.
Conclusion
Standard and Image Checkpoints form the backbone of a reliable UFT automation framework. They move testing beyond simple record-and-playback, transforming scripts into sophisticated diagnostic tools. By mastering the nuances of property selection, timeout management, and visual image comparison, testers can ensure that their automation suites provide not just execution, but genuine, verifiable quality assurance.
As we continue this tutorial series, we will delve into more specialized checkpoints, including Table, Database, and Text Area checkpoints, which offer even deeper layers of verification for complex enterprise applications. Stay tuned for our next installment, where we will tackle the intricacies of data-driven verification.