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.

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 Licensing.

Yes and No. OpenText Functional Testing tests are written in VBScript, while OpenText Functional Testing for Developers tests are written in C#, Java, or JavaScript. However, you can convert your OpenText Functional Testing object repositories to OpenText Functional Testing for Developers application models.

For details, see Convert object repositories to application models.

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

See also:  OpenText Functional Testing terminology reference

Yes. You can manage and run OpenText Functional Testing for Developers tests from supported versions of ALM. For a list of supported versions, see the Support Matrix.

For more information, see Application Lifecycle Management (ALM).

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

OpenText Functional Testing for Developers assets are standard source files, for example, code files or xmls. You can use the same source control system for these 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 the 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 <Installdir> folder. For example, many important files are found in <Installdir>\bin or <Installdir>\Tools.

When you install OpenText Functional Testing for Developers 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 OpenText Functional Testing for Developers as part of the OpenText Functional Testing setup program, the folder you choose for installing OpenText Functional Testing is also used for OpenText Functional Testing for Developers files. Therefore, the OpenText Functional Testing for Developers files mentioned above are located in <OpenText Functional Testing_installdir>\bin or <OpenText Functional Testing_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.

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 the runtime engine settings.

Yes.  For details, see Modify the communication port number.

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 report.

For details, see Analyze run results.

Yes. The IDE plugin includes 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.

Example: Testing with Cucumber

Yes.

See Run tests in parallel.

• 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 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();