UFT Web Record & Test Experiences 1

Contents

Opening Remarks

UFT Prerequisites

Browser requirements

UFT Web Selectable Add-ins

Web App Recording in UFT

UI and AI integration

Web recording and testing using UFT

UFT Web Add-in Prerequisites

Opening Remarks

There is a new release of UFT available, and I have a chance to share a little with you. This is not a sales pitch article.  Quite the contrary. Stay with me and you will see some web demonstrations of the product and useful interactions with web technologies. Also, I have a video series so you can see my experiences with the tool and demo websites.

My last use of UFT was back when release 14.5 was the latest version of the software. I was just starting to get used to the name “UFT One” which I believe started with release 15. That is my recollection. Anyway, I don’t remember software prerequisites other than knowing what add-in UFT needed selected to record scripts.

Now people are surprised if they do like I did. Partially read the instructions for installing UFT, and then try out the record process to test the software. The surprise comes when you find out that UFT is not generating any script code. Maybe that’s the codeless script option. (okay it’s my little joke)

After several hours of challenging the search engine, I finally stumbled upon what I thought was the source of the problem. You may have heard me say or I may have written before, to be careful when you are trying to resolve issues. Some were talking about antivirus issues that corrupt the UFT installation. So, I performed a UFT install repair which took a long time. UFT Web record process still did nothing. Some were saying that Web 2.0 add-in was needed for all the latest web application support needs. I installed the UFT Web 2.0 add-in. That didn’t improve my situation.

I went back to searching. And after two days I thank God. I believe his wisdom opened my eyes to see that at the UFT ADMHELP website, it talked about browser extensions. The solution is to go to this site for the truth: UFT Help Site.

This is the Web add-in page for UFT. Here there is a section that is entitled “Prerequisites”. How did that get there? Well, it answers the question, “How do you fix UFT web recording?”.

While I am on this subject. I strongly recommend this URL: https://admhelp.microfocus.com/uft/en . There is a wealth of information about working with the product UFT. I find that I often reference this site to help answer my questions or solve my error situations. When you have some down time, it can be a good reading source to improve your functional test skills. Okay! I hope that was not too salesy.

UFT Prerequisites

Before you start recording web applications after you install the UFT software, there is something else required. Depending on which browser you intend to test with, there is an extension for it. There is one for each of the well-known browsers including legacy Edge or the old Internet Explorer browser.

Once the extension is activated on your browser, UFT recording starts to generate script code. And the fun begins!

Browser requirements

Depending on browser versions in use

I guess the browser extension required for each browser is like the web drivers that other tools require to interface and emulate browser interactions during recording and test script execution.

But be aware of the possibility that in the future as new features are added to the web add-ins and application software, the extension management may get complex keeping up with upgrade requirements.

Please make sure that the UFT Extension in Chrome, Edge, Safari, or Firefox is enabled. You may see this message appear more if new releases of the software are required for certain releases of the UFT software or certain web application upgrades. I am not trying to create a mess. I just think that application software upgrade demands are getting complicated and therefore may complicate the extensions.

Please check that zoom in chrome is at 100% before you click on record in UFT. If your browser is not at 100%, it may cause the recorder to be unable to detect objects near the edge of a page.

UFT Web Selectable Add-ins

In general, whenever you have a desire or need to test a web application it helps to know what is the primary web technology the application uses. It then helps to know what web test objects used by UFT meet the test requirements. It used to be simple web technology that did not put much demand on UFT scripting.

That has changed. Some web applications still make use of simple HTML, CSS, and JavaScript usage. However, the dynamic nature of web applications, coupled with evolving user requirements, market demands, and technological advancements, contributes to the need for flexibility in the application code to accommodate changes efficiently and effectively. This underscores the importance of using flexible frameworks, modular architectures, and best practices in web development to maintain and evolve complex web applications over time. This demand extends to test scripting tools like UFT. UFT has had to dramatically increase its test object interface capabilities. So, now we see a significant increase in the number of web-related add-ins in UFT. We also see its vendor has published a new version of UFT that is called UFT Developer. They are pushing it as there solution for Continuous Testing. However, I see it as a competitor to the new test kids on the block. Playwright, Selenium IDE, and there partner Python. These products are taking the software test market by leaps and bounds. They are not the only tools getting attention. But they get my attention. I started looking at UFT Developer but the price is a concern. Enough said.

Back to my UFT experiences. Even testing SAP applications has become more complex. The world of SAP has exploded into Netweaver, Fiori, and UI5 technologies that put a great demand on test requirements. UFT has responded and is doing much to keep up. I will talk more about this in this article. You can go to my videos and see what I am talking about too.

The Web 2.0 technology is essential for business applications to exist in the intranet and internet arenas and not be overwhelmed by the downsides. The dynamics that can be developed using web 2.0 protects business applications from unwanted attacks and high traffic need for stability and responsiveness. So, test tools like UFT must keep improving to support the interactive changing test requirements.

It is safe to say that it used to be unnecessary to support multiple or cross browser testing. And it used to not be a necessary test requirement to test in a parallel mode. Continuous testing demand coupled with CI/CD and the cross-browser testing demands are driving the need for test tools like UFT to step up with the right software offerings.

Web App Recording in UFT

So, bear with me while I step into software demonstration mode. I plan to give a short overview of the UFT software in terms of what you can do with it today since its latest offering – UFT 23.4. I am going to take you through several UFT recording and testing scenarios to demonstrate some of its capability to support web application testing.

The traditional approach to testing using a tool like UFT included only a few steps. You installed the product, identified what browser to use, identified a URL for the target test application, proceeded through the record process and then executed the generated script. The record and playback testing approach was popular. Any time objects changed, or page changes were presented, the script had to be re-recorded to extend the life of the script. UFT scripts need to have an extended life to help with controlling test costs.

Well. After UFT installation and setup for web testing there is more now to consider. First, the software has changed enough to include a browser interface. The vendor calls it an Agent. It must support the right dialog between UFT and the target browser. The next thing is that you cannot rely on just recording and running scripts. Scripts must be designed to have a useful life.

After recording and generating a script in UFT, the designer in you must come forward with understanding how to modify the script to handle error conditions, how to manage reusability, how to support multiple combinations of input data, and how to report what was tested effectively. The script may need to have external input data to guide the test scenarios. It may also need to be flexible on reporting to produce output that meets the need of business analysts. Test requirements are continually getting complex. So, scripts need features that accommodate the demand.

UFT Web app recording and playback is just the start for today’s web application testing. Especially, with web technology growth. The list of web technologies has grown much. In this article I am just touching on the surface with Web, Web 2.0, SAPUI5, AI, and SAPWebExt. There is much more to support. So, coding is a must after recording a script. As some might say, “You have to take the script development to the next level.” You also must take the web test results to the next level too.

At this point in the article, I think you would gain some good insight into the UFT One tool. My first two videos of the UFT One Web Recording and Testing Series will help solidify what I have been communicating here so far. The videos will give you a good demonstration of how the UFT tool works and a useful look and feel of the tool. Take a break from reading and view the videos, and then come back.

• UFT One Web Recording & Testing (Part 1)
• UFT One Web Recording & Testing (Part 2)

UI and AI integration

UFT 23.4 is now providing support for innovative technology that improves recording and script development. There are two new features of UFT One that I think takes UFT recording and development processes to a new level. One is called UI Automation, and the other is called AI or Object Identification Center (OIC). I was impressed with what the AI functionality does, and I want to talk about it more later. The UI Automation feature is also something special, but I failed to fully check out its strength. The UI Automation tool uses another group of methods and properties to support web application object interfaces. It is turned on in the UFT add-ins selection – UI Automation.

I turned it on for one of my scripts and it did generate one statement that started with “UIA”. I mistakenly took it for an AI statement. The AI statements start with “AI”, not “UIA”. My mistake. I think I would have been impressed to make use of this feature in my code. The next time I have a chance to write some UFT code, I will try out the UI Automation feature.

If you have a chance now, you can read all about it here: UFT UI AUTOMATION Feature.

In this article I am not going to traverse through all the add-ins UFT uses to support Web application testing. I only want to proceed with a discussion on traditional web and SAPUI5 recording and testing. I am going to give a mention on the SAPWebEXT add-in. But at this URL, you can find much more detail about all the possible add-ins that can be selected and utilized for web application testing. Select this page for more detail: UFT Web add-ins. Be sure to look on the side panel for more web-related add-ins.

Web recording and testing using UFT

Once you have selected the right combination of add-ins during the launch process of UFT you are ready to begin a record process for some Web application. The application launch URL can be specified in UFT Record and Run settings. An alternative is to set the radio button on the settings to record on any open browser. If you choose the latter, then after you click the record button in the UFT IDE it is on you to launch your browser and enter a URL to begin the recording process. It is normal for UFT to record your navigation steps through the target application. Ending the recording process requires clicking the close button on the browser and stop button on record popup menu.

The resulting recorded code in the UFT IDE is not always immediately ready for test execution. It is possible that the recording session did not record all navigation events. It is also possible that the code generated is not sufficient to execute without failing conditions. Of course, one way to know if the code is operational is to start the run process. However, it is worth allowing a few minutes to review the code before execution.

Consider the code in figure 1. It represents code that was recorded by UFT for a web application known as Advantage Online Shopping. It is a demo web application. I have highlighted the lines of code that for various reasons failed to execute successfully. That shoots down the record and playback idea from the start. It looks simple enough that it should execute without raising error conditions. Now, I am not going to get into details about what each error condition was encountered. My point here is about setting expectations on what it takes to record, debug, and test UFT web application test scripts.

The objectives for this script were to locate the website, select an image to display details, click a button to place it into the shopping cart, open the shopping cart and confirm the status, and then remove the cart entry and return to the home page.

For the scenario if all lines of code were executed without error, only eight of the ten lines of code were needed. Lines 1 and 2 are not necessary and often don’t always execute successfully. Now we are down to eight lines of code – 3 through 10. But lines 5, 8, and 9 were not able to run without error. Thus, the code as-is cannot be considered reusable code.

Figure 1

Can the code be made reusable. My response is, yes. But there are likely multiple ways to solve this challenge. I am going to share my method. There is a comment function at the end of this article that can be used to tell the readers what you would do, and I appreciate the comments.

I must give some credit to the vendor. They have supplied several mechanisms to solve test code issues for web applications. There is no shortage of tools. My solution made use of several ways to code. Before I get into talking about the solution in figure 2, I want to mention several thoughts regarding reviewing a UFT script with debugging in mind.

1. After a while of recording and testing UFT scripts, you become familiar with certain statements that will probably fail, so they should be commented out immediately. That is my thought about statements 1 and 2. I know they may work sometimes but come back to them for benefit analysis after you have a reusable script.
2. For web scripts, there is usually a timing issue navigating between web pages. This means a delay can occur with your code identifying objects on the new page. At least the first object. So, a wait or a synchronization process is needed. Without it the code will move ahead of the application and be out of sync with the application navigation.
3. Some objects on a page may not be visible for detection by the code execution. This can occur due to parts of the logical page window not appearing on the physical page. This can require needing to scroll in some direction to have the object visible for detection by your code execution.
4. Sometimes the recording process detects an object and generates a statement that is not reusable or reliable.
5. When your code execution is out of sync with application navigation, more error conditions occur than what is valid. So, some statements may be reusable. It may require that you run in debug mode until you are comfortable with the results. This means execute a statement at a time to verify that each statement is functioning correctly.
6. Once you know where errors are possible you can place breakpoints before the line of code. This allows you to better control the process and make use of UFT’s Object Spy and AI support which is known as Object Identification Center (OIC). These tools can help you add alternative code that handles processing a difficult object.
7. One of the best additions to UFT code is existence tests. You can either use IF statements or EXIST methods for the page, or page objects. Then if the object is not found you can design the script to do error handling and better manage the testing. That is usually my last major change to a reusable script.

I am ready to turn your attention to what is my solution for a reusable script to accomplish the scenario I described earlier in this article. The solution includes the use of a callable subroutine. It includes synchronization statements instead of hard waits. It includes the use of UI, AI, and Object Spy inserts. The solution resulted in a code increase from 8 lines to over 40 lines.

Before I forget to mention, there is a descriptive code insert on lines 17 and 18. However, I had to disable those lines. They did not work as I expected. Descriptive coding in UFT is another option that uses the “:=” designation with XPATH. It’s possible that I did not get the XPATH value correctly. This is totally a manual approach to fixing an object detection error.

Another unexpected event was with line 22. That was a generated statement from the AI tool. It usually works when generated by the tool. But for some unknown reason it failed. So, I disabled it and since line 21 worked to remove the shopping cart invoice, the checkout button was no longer visible and unnecessary.

I mentioned line 21. This was totally unexpected. I must have selected an option in the OIC that caused a generation of a UI Automation statement instead of an AI statement. That is my best guess response. I thought it would only happen during a recording session. But that statement occurred during OIC processing.

My apology for how the subroutine appears in the table. I could not find a way to display it with proper indentation and still have line numbers. That is my segway into talking about adding a subroutine to support the checkbox in the application. When you don’t check the checkbox status first you can cause an error to be raised. So, the subroutine checks the status first and resets the status based on the request.

Please notice all the lines highlighted in yellow. Especially the ones I have yet to mention. There are several SYNC statements that provide waits in the code execution to allow the code to remain synchronized with the application navigation. And there are several REPORTER statements that provide status reporting for the test results output. This provides green check marks in the output report to easily see what tests passed during the script execution.

Figure 2

I mention in my videos that the UFT vendor is doing a good job of keeping up with all the innovations that are being added to the web technologies used by the applications today. Web application development is continuing to be more complex. Thus, having a tool with multiple options to detect page objects is important. It is advantageous to be able to efficiently detect and manipulate the page objects.

I have another big subject matter to share with you. But I will treat it as a subject for a follow-up article. It will be part 2 of this article.

Let me close this part of the article with this. UFT is a powerful tool in the SAP and Web test tool market. I know and have used some open-source test tools that provide good application test support. And they are free unlike UFT. But when it comes to the fortune 500 market, I believe it is necessary to have a test tool that supports good security measures and stays current with the growth pace of the SAP and Web markets. UFT one is still ahead in the test market. Don’t count it out because of the price.

Please join me in my follow-up article where I continue to share my experiences with UFT 23.4 recording and testing activities. I will tell you and show you what I learned in a few days of evaluating the use of the tool for web and SAP application testing. Click here to go directly to part 2 of this article.