Yes. Many technologies are supported.

The .NET, Java, and JavaScript SDKs include support for technologies such as Standard Windows, Web, Mobile, .NET Windows Forms, WPF, Java, SAP GUI and SAPUI5.

For a complete list of supported technologies, see the .NET SDK Reference, Java SDK Reference, or JavaScript SDK Reference

To see supported versions of each technology, see the Support Matrix.  

Windows, Linux, and Mac environments are supported.

For more details, see the Support Matrix.

For a list of supported features on these environments, see Cross-platform feature support.

You can program your tests in C# using Visual Studio, or in Java using Eclipse, Spring Tool Suite, JBoss Developer Studio, IntelliJ IDEA, or Android Studio.

You can also program in JavaScript in any supported IDE.

For details on the supported IDE versions, see the Support Matrix.

Yes. A variety of license editions is supported, providing different sets of functionality.

For details, see UFT Developer licensing.

Yes and No. UFT One tests are written in VBScript, while UFT Developer tests are written in C#, Java, or JavaScript. However, you can convert your UFT One object repositories to UFT Developer application models.

For details, see Convert UFT One object repositories to UFT Developer application models.

In addition, the UFT Developer SDK provides a similar set of objects and methods to that provided by the UFT One object model, and the UFT Developer Application Model editor and Object Identification Center (OIC) provide a superset of the functionalities you are familiar with from the UFT One Object Repository editor and Object Spy.

See also: UFT Developer reference for UFT One experts

Yes. You can manage and run UFT Developer tests from supported versions of ALM. For a list of supported versions, see the Support Matrix.

For more information, see Integrate UFT Developer and ALM.

Yes. For details, see Run tests using a CI system.

UFT Developer assets are standard source files, for example, code files or xmls. You can use the same source control system for UFT Developer assets as you use for all other code files.

By default, snapshot images are not added to the HTML run results report, but you can modify the settings for your test so that it captures snapshots on errors or even for every step.  You can also change this setting programmatically at any point in your test.

Additionally, you can use the TestObject.GetSnapshot method to capture an image of a test object at any point in your test and then pass the captured image to a Reporter.ReportEvent step to include it in the report.

For details, see Analyze run results and the .NET SDK Reference, Java SDK Reference, or JavaScript SDK Reference.

Yes.  You can create a central application model and reference it from all relevant testing projects.

When you create an instance of your application model class, you can pass any defined Browser, Device, or GuiSession test object as the constructor.

For details, see Application models and Test-object hierarchy in the object application model.

Support for testing standard windows applications is always loaded.

For all other technologies, you can modify which add-ins (technology support) to load on the computer where the runtime engine is installed.

You should load only the add-in technologies you need.

The changes you make affect the technologies supported in the Object Identification Center (OIC) as well as for tests that you run on that computer.

For more details on modifying runtime settings, see: Customize UFT Developer runtime engine settings.

Yes.  You can run your Web tests on any supported browser or version.

For details on supported versions, see the Support Matrix.

As long as your application behaves the same in different browsers, you can run the test in different browsers.

To do this, use the BrowserFactory.Attach method to run on a browser that is already open, or change the browser type specified in a BrowserFactory.Launch step to specify the browser type you want for your run. All other test objects in your test, whether created using programmatic descriptions or using the application model, are independent of the browser type.

For more details, see the .NET SDK Reference, Java SDK Reference, or JavaScript SDK Reference.
See also: Test-object hierarchy in the object application model

Throughout this Help Center, many instructions tell you to open files from the <UFT_Developer_installdir> folder. For example, many important files are found in <UFT_Developer_installdir>\bin or <UFT_Developer_installdir>\Tools.

When you install UFT Developer on its own, you can specify the folder where you want to it. By default, C:\Program Files (x86)\OpenText\UFT Developer.

When you install UFT Developer as part of the UFT One setup program, the folder you choose for installing UFT One is also used for UFT Developer files. Therefore, the UFT Developer files mentioned above are located in <UFT_One_installdir>\bin or <UFT_One_installdir>\Tools.

For some of these upgrades, no action is required. For others you need to re-run the installation in Change mode, as shown below:

For details, see Change or uninstall UFT Developer.

Yes. You can set up your environment to run tests in a configuration where your test is located on a different computer than the AUT. For details see Run tests remotely.

Yes. You enter the user name and encrypted password credentials in the runtime engine settings on the computer where the test is running so that the test can continue to run when the connection is locked or disconnected. For details, see Customize UFT Developer runtime engine settings.

Yes.  For details, see Modify the port used by UFT Developer.

Use Excel data as input and take advantage of standard looping functionality available in the NUnit or JUnit frameworks or implement on your own.

When an error occurs in a step that the runtime engine tries to perform on your application, it throws an exception. You can catch the exception in your code and handle it as needed.

All such errors are also included in the UFT Developer report.

For details, see Analyze run results.

Yes. The UFT Developer IDE plugins include templates that are based on leading frameworks like NUnit and MSTest (Visual Studio), and JUnit and TestNG (Eclipse, Spring Tool Suite, JBoss Developer Studio, IntelliJ IDEA, and Android Studio). Using these templates helps you get started working quickly and enable you to take advantage of their built-in functionality.

You can also build on top of the provided templates or create tests from scratch with your own framework. Doing this requires some extra configuration.

For details, see Use your own frameworks with UFT Developer.

Example: UFT Developer with Cucumber

Yes.

See Run parallel tests in UFT Developer.

• FireEvent. For Web, Java, and Windows Forms technologies, you can use a FireEvent method to perform events supported for that technology and object type.  
• SendKeys. Many of the UFT Developer SDK technologies offer the SendKeys method for all interfaces. You can use this method to type text or activate special keyboard modifiers on an object in your application.

• Mouse and Keyboard classes. (Windows only.) These classes provide methods that enable you to send a variety of mouse and keyboard events to your application. For example, you can use these methods to move the mouse to a particular coordinate and then perform a DoubleClick. Or you can use a normal test object method to bring a particular object into focus on your application, and then use a Keyboard.PressKey method to send the keyboard scan code for the Enter key.

  Keep in mind that unlike the FireEvent and SendKeys methods, the Mouse and Keyboard classes work at the device level and not within the context of a test object. You can use them for any technology, but they rely on coordinates relative to the screen, which can be tricky to maintain over time.

• NativeObject. You can use NativeObject to access and run the native methods and properties of the run-time object in your application. For guidelines and usage details, see Access native objects, methods, and properties.

For more information on all of these methods, see the see the .NET SDK Reference, Java SDK Reference, or JavaScript SDK Reference.

WPF toggle buttons are a special type of Button test object.

Create a WPF Button test object, and then use the ToggleButton property (C#) or getToggleButton method (Java) to return a ToggleButton instance.

For example:

C#:

var window = Desktop.Describe<HP.LFT.SDK.WPF.IWindow>(new HP.LFT.SDK.WPF.WindowDescription { Text = "MyWindow" });
var toggle = window.Describe<HP.LFT.SDK.WPF.IButton>(new HP.LFT.SDK.WPF.ButtonDescription { ObjectName = "Button4" });
toggle.ToggleButton.Set(CheckedState.Checked);

Java:

Window appMainWindow = Desktop.describe(Window.class, new WindowDescription.Builder().objectName("MainWindow").fullType("window").windowTitleRegExp("MainWindow").build());				
Button buttonWithToggleButtonSupport = appMainWindow.describe(Button.class, new ButtonDescription.Builder().text("Toggle Button").objectName("Button4").build());
ToggleButton toggleButton = buttonWithToggleButtonSupport.getToggleButton();