Recent Content
Surviving Upgrades: How to Manage Change Across Test Automation Toolchains
The Pain Point (a story we’ve all lived) It’s Friday afternoon, and your team is on the eleventh-hour push to ship a release. Everything has been working all week — the build is green, the smoke tests passed, and you’re finally feeling the relief of a job well done. Then it happens. A test suite that has been stable for weeks suddenly fails in dozens of places, and the failures don’t make sense. You didn’t change anything. The application didn’t change. The environment didn’t change — or so you thought. But somewhere in the stack, something moved. Maybe the browser auto-updated overnight. Maybe a Windows patch was applied. Maybe the CI agent updated. Maybe the automation tool itself installed a minor version update without you realizing. Now the release is blocked. The team is waiting. The deadline is looming. And you’re left in the middle of a nightmare: “Everything was fine… and now nothing works.” That’s not a automation tool problem. That’s not a browser problem. That’s not even an automation script problem. It’s a dependency chain problem — and it’s the most common cause of “suddenly broken” automation. The Real Issue: You’re Managing a Chain, Not a Single Product Automation tools are only one link in a longer chain that includes: OS or security updates Browsers and runtimes Test tools (TestComplete, ReadyAPI, etc.) Drivers, plugins, integrations The application under test CI/CD agents and infrastructure When one link moves ahead, the chain breaks. So a “successful upgrade” isn’t just installing a new version — it’s ensuring the rest of the chain can support it. The Goal: Upgrade Intentionally, Not Accidentally Upgrades should be treated as controlled change, not something that “just happens.” The upgrade decision should be based on: Need: Do we require a feature or fix? Risk: What can break? Environment readiness: Is the stack aligned? Rollback plan: Can we recover quickly? If the answer is “no” or “not sure,” it’s perfectly valid to wait. Early Adoption: Not a Risk — a Strategy Many teams avoid early adoption entirely, waiting for others to report issues. That’s passive. A stronger approach is: Create internal early adopters intentionally. What that means: A pilot environment is designated for early upgrades Early adoption is expected, not accidental Findings are documented and shared This turns early adoption into risk discovery, not risk exposure. The One True Anchor: Test Environments Across all team sizes, the same rule applies: If you don’t control your test environment, you don’t control upgrade risk. The test environment is the contract that defines what “works.” Environment best practices: Lock OS, browser, and runtime versions per environment Disable auto-updates where possible Treat environments as managed assets Separate: Sandbox / pilot Test / QA CI/CD execution When environments are stable, upgrades become predictable. Scaling Upgrade Practices by Team Size Upgrade strategy changes with organizational scope. Here’s how: Stand-alone automation users You are the early adopter Backups are essential A spare VM can be your pilot environment Rollback must be quick and simple Small teams Use a pilot machine Freeze browser versions used in automation Stagger upgrades across the team Keep a lightweight shared change log Large teams / enterprises Environments are contracts CI/CD agents should upgrade last Forced upgrades (security, browsers) are inevitable Change visibility matters more than speed Browser Updates: The Frequent Weak Link Browsers often update faster than automation tools officially support. Mitigation strategies: Pin browser versions used in automation Validate browser upgrades separately from tool upgrades Expect compatibility lag Use community feedback to spot issues early Browser drift is predictable — and therefore manageable. A Simple Upgrade Flow That Works Everywhere Here’s a repeatable pattern that scales from solo users to large teams: Review version history and known issues Back up projects and configurations Upgrade in a pilot environment Run smoke tests first Observe and document findings Roll out gradually Upgrade CI/CD last This flow keeps upgrades controlled and prevents cascading failures. How to Start (if you have no process yet) If your team has never formalized upgrade strategy, start small. You don’t need heavy change management — just a lightweight, repeatable approach. First 30 days: Choose a pilot environment (VM, spare machine, or sandbox) Create a simple change log (spreadsheet is fine) Define one smoke test suite that represents core workflows Disable auto-updates where possible Next 60 days: Add an upgrade checklist to your workflow Upgrade one component at a time (browser, tool, CI) Share findings with the team Decide on a cadence (monthly, quarterly, or as-needed) By 90 days: Your process becomes repeatable You’ll have real data on what breaks first You’ll stop being surprised by “suddenly broken” automation Printable Checklist Upgrade Readiness Checklist Review release notes and version history Confirm need for upgrade (feature, fix, security, compatibility) Backup all projects and configurations Identify pilot environment Disable auto-updates where possible Run smoke tests in pilot Document findings and workarounds Stagger rollout to team Upgrade CI/CD last Final Thought The goal isn’t to always upgrade first — or always upgrade last. The goal is to upgrade intentionally, with visibility, feedback, and control. When upgrades are planned around environments, team size, and deliberate early adoption, automation becomes resilient instead of fragile.0likes0CommentsOCR in UI Test Automation: Extending Coverage Where Traditional Identification Breaks Down
Automated UI testing increasingly operates in environments where traditional object identification is not reliable. Modern applications frequently render text and controls using custom graphics, canvases, charts, and dynamically generated visuals that do not expose accessible properties or stable locators. As a result, automation tools that rely solely on object hierarchies and properties can struggle to validate what is actually presented to the user. Optical Character Recognition (OCR) addresses this gap by enabling automation to extract and interpret text directly from what is rendered on screen. Instead of depending on the underlying implementation of a control, OCR works at the visual layer, analyzing pixels and patterns to recognize characters and convert them into machine readable text. This capability allows automated tests to validate user visible content in situations where traditional approaches fall short. Why OCR Matters in Real World UI Testing In many business critical applications, text is not always exposed through standard UI controls. Common examples include: Charts and dashboards rendered using custom drawing libraries Canvas based interfaces and rich graphical components Embedded documents such as PDFs or reports Custom buttons, labels, or alerts built without standard accessibility metadata In these scenarios, the risk is not just test fragility it is blind spots. If automation cannot confirm what text is displayed, teams are forced back to manual validation for critical user facing information. OCR enables tests to verify visible content regardless of how it is implemented. By converting visual text into actionable data, OCR allows teams to assert that values, labels, messages, and statuses shown to users are correct, even when object level access is unavailable. This makes OCR especially valuable for validating end-to-end business workflows where correctness depends on what users actually see, not just what the application internally represents. OCR as Part of TestComplete’s Object Recognition Strategy TestComplete incorporates OCR as part of its broader approach to handling complex and non standard user interfaces. OCR is available directly within the platform and can be applied to many different types of application testing without requiring separate tools or configurations. When TestComplete encounters unsupported or custom controls, OCR can be used to: Recognize text from a specified screen region Extract and compare visible text against expected values Locate UI elements based on displayed text rather than coordinates Interact with visual elements by identifying their text content OCR actions can be recorded automatically during test creation when traditional object recognition is not possible. Teams can also explicitly define OCR based checkpoints to validate messages, labels, and dynamic values that appear during test execution. By allowing interactions to be driven by recognized text instead of fixed screen positions, OCR based tests tend to be more resilient to layout changes and UI adjustments. See OCR in Action A short demonstration shows how OCR is applied in real testing scenarios, including recognizing text in custom or unsupported controls, validating user visible messages, and driving interactions based on on screen text rather than fixed coordinates. The demo focuses on practical use cases where traditional object identification is not available. Expanding Automation Coverage Without Increasing Fragility One of the persistent challenges in UI automation is balancing coverage with maintenance. Scripts that rely on brittle locators or coordinates often fail when visual layouts change, even if the underlying functionality remains correct. OCR helps mitigate this issue by anchoring tests to user visible content rather than implementation details. This is particularly useful for: Validating alerts or error messages drawn directly on the UI Verifying values inside charts or graphical widgets Testing applications with frequent visual refinements but stable business logic By enabling validation at the visual layer, OCR reduces the need for workarounds or manual testing in areas that were previously difficult to automate. The result is broader coverage with fewer fragile dependencies. OCR as a Bridge Between User Experience and Automation OCR is not intended to replace traditional object based testing. Instead, it complements it by extending automation into areas where conventional techniques are insufficient. Within TestComplete, OCR functions as a bridge between how users experience an application and how automated tests validate it. When automation can read and verify the same information a human user relies on, test results better reflect real world behavior and risk. As applications continue to evolve toward richer and more visually driven interfaces, OCR plays a key role in ensuring automated testing remains aligned with actual user experience not just underlying code structure.Stop Skimming PDFs, Start Automating PDF Testing
On the surface, PDFs look simple, but testing them is a whole different story. Invoices, contracts, statements, compliance reports… they’re often the last thing that lands in a customer’s hands. That also means even the smallest issue, like a missing field or a misplaced decimal, can turn into something big. The challenge is that PDFs aren’t like web pages or apps where you can easily inspect elements. They’re containers packed with content, layout, images, and data from different systems. When you add in dynamic content that changes for every customer, formatting that has to stay perfect, and the regulatory risks in industries like finance or healthcare, you start to see why manual testing just doesn’t cut it. It’s slow, inconsistent, and doesn’t scale. This is where automation becomes essential. With automation, you can make sure data is always accurate, layouts stay consistent, and testing scales across thousands of documents without slowing down your team. Instead of spending hours opening PDFs by hand, QA can focus on higher-value work while still knowing that every report or statement going out the door is right. That’s exactly where TestComplete comes in. It’s built to handle the tough parts of PDF testing so you don’t have to. You can validate content down to the last character, run visual checks to keep layouts consistent, and plug it all straight into your CI/CD pipeline. The result is faster releases, fewer headaches, and a lot more confidence that the documents your customers see are exactly as they should be.Accessibility Testing Made Easy: How TestComplete Ensures Web Compliance
Most test automation focuses on functionality but in regulated industries like healthcare, finance, and education, teams must also prove accessibility and compliance. TestComplete’s Web Audit Checkpoints make this simple by integrating accessibility scans directly into automated tests, identifying errors like missing alt text, deprecated tags, and invalid HTML. Teams can set practical thresholds (e.g., zero critical errors, limited warnings) to balance enforcement and flexibility. This ensures every regression run checks not only if features work, but if they meet legal and usability standards. The result is faster compliance, reduced risk, and higher-quality user experiences for everyone. Check out our demo video to see how accessibility testing in TestComplete fits seamlessly into your automation pipeline and helps you build more inclusive, compliant web applications.Beating SAP Testing Bottlenecks with TestComplete
Testing SAP is hard for all the familiar reasons, complex UIs, transports that tweak screens, sensitive data, and heavy audit needs. Below are the common bottlenecks and how TestComplete helps you cut through them. Fragile object locators in SAP GUI The bottleneck: SAP GUI controls can be tricky to identify reliably minor UI changes or different dynpro states can break scripts. How TestComplete helps: It provides native support for SAP GUI for Windows with extended objects (buttons, edit fields, grids, etc.), so you work with properties and methods not coordinates. Pair that with Name Mapping (a central, alias-based object repository) to make tests readable and resilient. 2) UI drift after transports equals flaky tests The bottleneck: After a support pack or transport, object properties change and tests fail even though the flow still works. How TestComplete helps: Self healing tests automatically look for close matches when an object isn’t found, reducing “false red” failures and maintenance. 3) “Hard” screens, canvas elements, or remote sessions The bottleneck: Custom controls or canvases don’t expose stable object trees. How TestComplete helps: Use AI-powered OCR (and the OCR Action in Keyword Tests) to find text on screen and create easy validation as a fallback when classic object IDs aren’t reliable. 4) Test data sprawl (pricing, partners, plants…) The bottleneck: You need many variants to cover conditions, taxes, partners, plants, and languages without hand cloning tests. How TestComplete helps: Built-in data driven testing lets you drive one test with rows from Excel/CSV/DB, multiplying coverage while keeping scripts lean. 5) Audit evidence for SOX/GxP The bottleneck: Auditors want traceable, reviewable evidence: who ran what, where it clicked, and what was on screen. How TestComplete helps: Test Visualizer captures step-by-step screenshots during record/playback; Video Recorder can capture full-run videos; detailed logs tie everything together. These are ideal for defect triage and audits. 6) CI/CD traceability (and repeatability) The bottleneck: Manual runs don’t scale; teams need runs linked to commits/builds. How TestComplete helps: Use the Jenkins plugin to trigger suites in jobs or Pipelines and view results in Jenkins, creating a clean chain of custody for each build. Final thought SAP is always changing, your tests shouldn’t break every time it does. TestComplete’s native SAP GUI support, Name Mapping, self-healing, OCR fallback, and data-driven runs help you keep testing stable and audit friendly with less maintenance. The following demo illustrates these features in practice, automating the creation of a purchase requisition within SAP while maintaining stability across UI changes.From Confused to Confident: Master XPath for Web Testing
Introduction Learn how to confidently build, refine, and troubleshoot XPath expressions. This practical, example-driven guide covers TestComplete HTML and CSS basics, XPath syntax, and browser validation techniques, helping you create stable and maintainable automated web tests. While TestComplete can generate XPath or CSS selectors automatically, generated selectors can break if page layouts change, so knowing how to tweak XPath manually ensures your tests remain reliable even on pages that change frequently. HTML Basics W3Schools Reference HTML stands for HyperText Markup Language. It is the standard markup language for creating web pages. An HTML document can be represented as a Document Object Model (DOM), which is a tree of nested elements. Each element may have attribute name–value pairs that provide additional information about that element like its ID or class. An HTML element typically includes a start tag, content, and an end tag, for example: <tagname>Content goes here...</tagname> Save this simple example as a file named "index1.html" and open it in a browser, or paste it in W3Schools Tryit Editor left pane section. The <img> tag’s src may point to any valid image file or a valid URL. <!DOCTYPE html> <html> <head> <title>Page Title</title> </head> <body> <h1>This is a Heading</h1> <p>This is a paragraph.</p> <a href="https://www.w3schools.com">This is a link</a> <p>This is another paragraph.</p> <img src="w3schools.jpg" alt="W3Schools logo" width="104" height="142"> </body> </html> CSS Basics W3Schools Reference CSS stands for Cascading Style Sheets and defines how HTML elements are displayed color, size, spacing, and layout. CSS rules consist of a selector and a declaration block, which contains property–value pairs, for example: h1 { color: blue; font-size: 24px; } Save this simple example as a file named "index2.html" and open it in a browser, or paste it in W3Schools Tryit Editor left pane section. <!DOCTYPE html> <html> <head> <style> body { background-color: yellow; } p { color: red; margin-left: 100px; } </style> <title>Page Title</title> </head> <body> <h1>This is a Heading</h1> <p>This is a paragraph.</p> <a href="https://www.w3schools.com">This is a link</a> <p>This is another paragraph.</p> <img src="w3schools.jpg" alt="W3Schools logo" width="104" height="142"> </body> </html> CSS selectors are different from XPath selectors, and TestComplete can use both depending on the browser engine. XPath Basics W3Schools Reference XPath stands for XML Path Language. It uses a path-like syntax to identify and navigate nodes in an XML or HTML document. Now that we’ve reviewed how web pages are structured, let’s see how XPath helps locate elements within them. In web testing, XPath is commonly used to locate elements within the HTML DOM. Important points to keep in mind: HTML <tags> and element names aren’t case-sensitive are normalized to lowercase, but attribute values are and usually enclosed in quotes. XPath works the same in HTML as in XML and navigates elements using relationships: Ancestors, Descendants, Parent, Children, and Siblings. Absolute Path: Starts from the root with a single slash "/", for example: "/bookstore". Absolute XPath is brittle because page layouts often change. Relative Path: Starts with double slashes "//" and searches anywhere in the document, for example: "//book". Consider this XPath Expression: "//div/a[contains(@class, 'button')]/@href". Let’s break it down step by step: 1. // = Search all descendants in the document 2. div = Select any "<div>" element 3. / = Navigate to direct child 4. a = Select the "<a>" child element 5. [] = Apply a condition 6. contains(@class, 'button') = Select "<a>" elements whose "class" attribute value contains "button". The contains() is very useful for partial matches. 7. / = Navigate to the next level 8. @href = Returns the value of the "href" attribute. In Plain English: Find all "<a>" links inside "<div>" elements with "button" in the class attribute and return their "href" values. Understanding XPath expressions helps handle dynamic pages, where IDs, classes, or structures may change across builds or browsers. You could also use wildcards and parameters. Testing XPath in Chrome & SmartBear Sample Shop Browser Developer Tools (DevTools) among other things are used to debug the HTML DOM and examine individual elements. Press "F12" to open DevTools. When DevTools is docked to the right (the default), the page layout may adjust dynamically. To maintain the original layout, and for this exercise switch the DevTools dock position to the bottom. SmartStore’s dynamic structure may vary and actual results may differ if the site layout changes. The Console panel in DevTools lets you execute XPath expressions directly in the browser to validate their syntax and confirm that they correctly identify elements within the DOM. The $x("...") is Chrome-specific console command function and is also not part of TestComplete. Type your XPath inside the command. Step-by-step example On the SmartStore Page click on the header "Help & Services", then right-click on the menu item "About Us" and select "Inspect". The Elements panel in DevTools will expand and highlight the corresponding HTML DOM element. Perform the following steps in the Console Panel: Type $x("") and notice the console displays "undefined". Type $x("//a") and notice the console displays "(109)" meaning there are 109 matching <a> elements, stored in an array. Type the full XPath $x("//a[span[text()='About Us']]") and notice the status changes to (2) signaling two matches were found. Note: If your target text is not inside a <span>, adjust to $x("//a[text()='About Us']"). Press Enter to execute the XPath expression and then expand the results to hover your mouse over the first entry "0: a.dropdown-item.menu-link", the element in the SmartStore page gets highlighted. Similarly, in the Elements panel, hovering over the element highlights it in the SmartStore page. Right-click on "0: a.dropdown-item.menu-link" and select "Open in Elements panel". This navigates directly to the HTML DOM element in the Elements panel. Scroll the SmartStore page to the bottom, and in the Elements panel, right-click on the element and select "Scroll into view". The SmartStore page will scroll back up and the element on the page will be highlighted. Right-click on the element and select "Copy" > "Copy XPath", "Copy full XPath", "Copy selector", or "Copy Element". You can paste into any editor for review. The "Copy XPath" generates an absolute path, while the "Copy full XPath" is fully qualified from root, both can break if the DOM structure changes. Repeat the steps for the second match "1: a.menu-link" to reinforce your understanding. Refining XPath for precision Option 1: By adding attribute filters with name–value pairs: view the element details and update the XPath $x("//a[span[text()='About Us'] and @class='dropdown-item menu-link']") Option 2: A more robust and preferable approach is to reference an ancestor in the XPath. Copy both elements' full XPath and paste them in a text editor for visual comparison. /html/body/div/div[2]/header/div[1]/div/nav/nav[2]/div/div/div/a[5] /html/body/div/div[2]/footer/div[2]/div/div/div[3]/nav/div/div/ul/li[1]/a The full XPath is a brittle locator that breaks with layout changes. Find the top ancestor and refine the XPath, start from a logical ancestor like “//header//a…” or “//footer//a…” and continue with descendant selectors, not direct children. The double slashes (//) mean any descendant level, not necessarily a direct child. Don’t worry if your XPath doesn’t work the first time—this is normal! $x("//header//a[span[text()='About Us']]") $x("//footer//a[span[text()='About Us']]") When you copy the full XPath from the browser and try to run it, it may not work. Example of a common mistake that will result in such error: "Uncaught SyntaxError: missing ) after argument list". Why: The double quotes (") inside the XPath conflict with the double quotes wrapping the string in JavaScript or TestComplete scripts. Use single quotes (') inside your XPath string to prevent conflicts with the outer double quotes used in the scripting environment. Incorrect: $x("//*[@id="header"]/div[1]/div/nav/nav[2]/div/div/div/a[5]/span") Correct: $x("//*[@id='header']/div[1]/div/nav/nav[2]/div/div/div/a[5]/span") Common Mistakes & Troubleshooting If your XPath expression doesn’t yield expected results, refresh the page or ensure you’re on the correct frame, and check for dynamic rendering (elements loaded after page load). Also try waiting for the element or using relative paths. Check whether the element is inside an iframe — in that case, switch context before applying XPath. Conclusion XPath can initially seem confusing, but with patience and practice, you’ll confidently tackle a wide range of web element identification challenges. Mastering XPath will also help you debug TestComplete object recognition issues more effectively. TestComplete’s flexibility, combined with a solid understanding of XPath, allows you to create robust, maintainable, and reliable automated tests. XPath skills also translate to CSS selectors and other object identification methods, improving cross-technology automation. Start experimenting with simple examples today, you’ll be surprised how quickly manually manipulating XPath becomes your favorite action!TestComplete with Zephyr
In this post, we are going to talk about SmartBear’s UI testing tool, TestComplete, and writing the results to Zephyr in an automated fashion. When we think about using TestComplete with any test management tool, it can really be accomplished in two ways: Natively inside TestComplete or integrating with some CI-CD system. When we are using Zephyr, both ways will utilize the Zephyr REST API. When we link to Zephyr natively from TestComplete, it is a script heavy approach. An example of that can be found here. Today we are going to go into detail about using TestComplete, with a CI-CD system, and sending the results to Zephyr. Now let’s talk about automating this process. The most common way to automate triggering TestComplete tests is through one if its many integrations. TestComplete can integrate to any CI-CD system as it has Command Line options, REST API options, and many native integrations like Azure Dev Ops or Jenkins. The use of a CI-CD system makes managing the executions at scale much easier. The general approach to this workflow would be a two-stage pipeline something like: node { stage('Run UI Tests') { // Run the UI Tests using TestComplete stage('Pass Results') { //Pass Results to Zephyr } } First, we trigger TestComplete to execute our tests somewhere. This could be a local machine or a cloud computer, anywhere, and we store the test results in a relative location. Next, we use a batch file (or alike) to take the results from that relative location, send them to Zephyr. When executing TestComplete tests, there are easy ways to write the results to a specific location in an automated fashion. We will look at options through the CLI as well as what some of the native integrations offer. Starting with the TestComplete CLI, the /ExportSummary:File_Name flag will generate a summary report for the test runs, and save it to a fully qualified or relative path in Junit-XML structure. At a basic level we need this: TestComplete.exe <ProjectSuite Location> [optional-arguments] So something like this: TestComplete.exe "C:\Work\My Projects\MySuite.pjs" /r /ExportSummary:C:\Reports\Results.xml /e The /ExportSummary flag can be stored in a relative or fully qualified directory. We could also use one of TestComplete’s many native integrations, like Jenkins and specify in the settings where to output results: Now that our TestComplete tests are executing, and the results are writing to a relative location we are ready for stage 2 of the pipeline, sending the results to Zephyr. So now let’s send our results to Zephyr. I think the easiest option is to use the Zephyr API, and the Auto-Create Test Case option to true. The command below is a replica of what you would use in a batch file script in the pipeline. curl -H "Authorization: Bearer Zephyr-Token-Here" -F file= Relative-Location-of-Report-Here\report.xml;type=application/xml "https://api.zephyrscale.smartbear.com/v2/automations/executions/junit?projectKey=Project-Key-Here&autoCreateTestCases=true" After you modify the API token, relative location, and project key you are good to run the pipeline. The pipeline should look something like this: After we run the pipeline let’s jump into Jira to find to confirm the results are populating. Even with execution data: Also, with transactional data to analyze the failed test steps:2likes0CommentsAccelerating Quality: How TestComplete Leads in Test Creation, Execution, and Object Recognition
Temil Sanchez, the new Product Manager for TestComplete, shares insights from a recent evaluation comparing TestComplete and Ranorex. TestComplete stood out for its faster test creation, intuitive interface, and superior object recognition, which reduce maintenance and ensure robust automation. Looking ahead, the focus is on integrating AI to further accelerate test creation, enhance resilience, and help teams release quality software faster.1like0CommentsChecking API Status in TestComplete
Introduction I first saw the need to verify the state of an API several years ago with an application that used an address validation API in several of it's operations. If this API was down or did not respond in a timely manor, many of the automated test cases would run and fail. In this case, and in others, I have found that doing a simple call to the API to check the returned status code allowed me to skip, fail or log a warning with a logical message instead of allowing the application to fail with another less direct error message due to the API issue. The aqHttp Object The TestComplete aqHttp object and it's methods are very useful for performing simple checks like this and are also useful for other more complex tasks like leveraging an API to return a test data set or even verifying a certain data is returned prior to running tests against the UI that depend on the data. Sending and Receiving HTTP Requests From Script Tests More Complete API Testing Most proper API testing should be done using a tools like ReadyAPI or SoapUI. Both of these tools will integrate with TestComplete or can be used alone and will provide much more capabilities and automation options. Integration With ReadyAPI and SoapUI Code Example Here I have provided a working example of how to code a Get request using 'aqHttp.CreateRequest' to confirm an API returns a status code of 200 and it will log the returned records. function sendGetRequest() { let resourcePath ="https://restcountries.com/v3.1/all" let resourceQuery = "?fields=name,capital"; let url = resourcePath + resourceQuery; try { // Send GET request let response = aqHttp.CreateRequest("GET", url, false).Send(); // Check for successful response if (response.StatusCode === 200) { // Parse JSON response let allData = JSON.parse(response.Text); Log.Message("Total records received: " + allData.length); // Process each record allData.forEach((record, index) => { Log.Message("Record " + (index + 1) + ": " + JSON.stringify(record)); }); return true; // Send a bool back to the calling function. } else { throw new Error("Failed to fetch data. Status code: " + response.StatusCode); } } catch (error) { Log.Error("Error during request or data processing: " + error.message); } } Enhancements You could accept parameters for the resourcePath and resourceQuery. Parameterize the logging loop run or remove it. Return the JSON to the calling function for use. Perform other tasks based on the return code. Conclusion With the growing use of API calls in desktop applications and the fact that APIs are almost the foundation of any web site checking an API before a test case run is almost a requirement for consistent test runs and good error logging. This small script can bring big rewards to your test runs and reports. Cheers! I hope you find it as useful as I have! If you find my posts helpful drop me a like! 👍 Leave a comment if you want to contribute or have a better solution or an improvement. 😎 Have a great dayAzure DevOps Pipelines - Running “Headless” Tests
One of the most common requests I get from TestComplete customers who run their tests from Azure DevOps pipelines is: “How can I execute my tests on remote Virtual Machines (VMs) with self-hosted agents without needing to maintain an active terminal session?”. Note: This document does not detail setting up the Azure DevOps pipeline or the self-hosted Azure agents. That process can be found in the TestComplete documentation here: Integration With Azure DevOps and Team Foundation Server via TestComplete Test Adapter | TestComplete Documentation There are some details in the TestComplete documentation on how to accomplish this type of configuration, but I’ll go through the full process and how to configure this solution with two options. That documentation can be found online: Disconnecting From Remote Desktop While Running Automated Tests | TestComplete Documentation The first option is to set up multiple virtual machines (VMs). You start by logging into one VM via Remote Desktop Protocol (RDP). From there, you connect to other Tester VMs running Microsoft Agents. After issuing a command to release the RDP session back to the Admin user, the Tester VMs remain active, allowing TestExecute to run tests triggered by the pipeline. The second option is to use a single, high-performance VM to host all remote sessions and agents. Here, multiple Tester sessions run on the same VM, each with its own agent handling pipeline requests. Each session runs its own TestExecute instance as long as enough floating licenses are available. The Admin session connects to the VM and then accesses each Tester session via RDP using the VM’s loopback address (e.g., 127.0.0.2). However, this method requires the VM to be part of a Microsoft Domain to support more than two simultaneous RDP sessions. Here are the commands we’ll be taking advantage of in this operation. To gracefully disconnect from an active RDP terminal session, converting it into a console session, open a Command Prompt (CMD) in the Admin user session and use the following: %windir%\System32\tscon.exe RDP-Tcp#NNN /dest:console where RDP-Tcp#NNN is the ID of your current Remote Desktop session, for example, RDP-Tcp#5. You can see it in the Windows Task Manager on the Users tab, in the Session column. The Session column is hidden by default. To show it, right-click somewhere within the row that displays CPU, Memory, and so on, then choose Session in the opened context menu. Our documentation also includes an easy-to-use batch file option that can be run as an Administrator to more easily disconnect from the remote Admin session. Create a batch file with this code: for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do ( %windir%\System32\tscon.exe %%s /dest:console ) Create a desktop shortcut to this file. To do this, right-click the batch file and select Send to > Desktop (create shortcut). In the shortcut properties, click Advanced and select Run as administrator. Double-click this shortcut on the remote computer (in the Remote Desktop Connection window) or call this batch file at the beginning of your tests (provided that the tests are run as an Administrator). To gracefully reconnect to a remote console session, use the following command in an open CMD prompt: mstsc -v: servername /F -console where the servername is the address of the remote VM hosting the Admin session. Option 1: Multiple VMs in the testing network. RDP connect to and set up the remote VMs to be used for the Tester Agents and have their self-hosted Microsoft agents active and listening for jobs, then disconnect the RDP sessions. RDP connect to the VM to be used as the “Admin” session. From the “Admin” VM, RDP connect to each Tester VM. (Connecting to more than 2 remote RDP sessions will require the VMs to be on a Domain with the appropriate settings configured to allow for more than 2 remote sessions.) Your Admin system should look something like this image where I am connected to 2 of my Tester VMs with their agents listening for jobs: Ensure that your Agents are active in the Azure DevOps Agent pool: Disconnect from the Admin user session using the prepared batch file or the direct command with the RDP session ID: Run the pipeline to validate that tests execute as expected: Reconnect to the Admin VM to see test results from the running agents using the command: mstsc -v: servername /F -console Option 2: Using a Single Virtual Machine RDP connect to the VM to be used for testing using the “Admin” account. I’m using my Tester01 account in this demonstration. RDP connect to the other users on the same VM using the 127.0.0.2 loopback address. Run the Microsoft self-hosted agents on these connected sessions. Disconnect from the Admin user session using the prepared batch file or the direct command with the RDP session ID. Prepare the pipeline. In my case, as I am not on a Domain so I am limited to ONE RDP session from my “Admin” user. I’m disabling the agent on Tester03 since we are using Tester02 for our pipeline. Execute the pipeline and validate successful test executions: Reconnect to the “Admin” session to make changes to the configuration as needed: mstsc -v: servername /F -console Conclusion In conclusion, these two methods provide testing options from Azure DevOps using VMs without requiring a dedicated terminal session from your development system. They still require that session, but the solutions provide options to workaround that “directly monitored” connection. These solutions also give you the security of running them on VMs in your environment; easily secured, controlled, and isolated by your firewall and security requirements. Full demonstration video link: Azure DevOps Pipelines - Remote "Headless" Testing1like0Comments
