Relevant for: GUI tests and components
You can create tests using the keyword-driven methodology, step recording, importing steps from Sprinter, or a combination of all of these methods.
This methodology requires an infrastructure for all of the required resources, including shared object repositories, function libraries, and recovery scenarios.
Setting up the infrastructure requires in-depth knowledge of your application and a high level of UFT One expertise.
Although setting up the infrastructure may initially require a longer time-investment in comparison to recording tests, using the keyword-driven methodology enables you to create tests that are more application-specific and have a more structured design.
This enables you to maintain your tests more efficiently and provides you with more flexibility than a recorded test.
Advantages of the keyword-driven methodology:
|Designed at the business level||
Keyword-driven testing enables you to design tests at a business level rather than at the object level.
For example, UFT One may recognize a single option selection in your application as several steps: a click on a button object, a mouse operation on a list object, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword.
|Easier to read||
Technical operations, such as a synchronization statement that waits for client-server communications to finish, are incorporated into higher level keywords.
This makes tests easier to read and easier for less technical application testers to maintain when the application changes.
|Separated resources and tests||
Keyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation experts to focus on maintaining objects and functions while application testers focus on maintaining the test structure and design.
Automation experts can add objects and functions based on detailed product specifications even before a feature has been added to a product. Using keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle.
Let UFT One generate test steps by recording the typical processes that you perform on your application.
As you navigate through your application, each step you perform is graphically displayed as a row in the Keyword View.
A step is anything a user does that changes the content of a page or object in your application, such as clicking a link or typing data into an edit box.
Recording may be easier for new UFT One users or when beginning to design tests for a new application or a new feature.
Advantages of recording
|Better for new users||
Recording helps novice UFT One users learn how UFT One interprets the operations you perform on your application, and how it converts them to UFT One objects and built-in operations.
|Better for new applications or features||
Recording can be useful for more advanced UFT One users when working with a new application or major new features of an existing application.
Recording is also helpful while developing functions that incorporate built-in UFT One keywords.
|Quick test creation||
Recording can be useful when you need to quickly create a test that tests the basic functionality of an application or feature, but does not require long-term maintenance.
Sprinter, OpenText's manual testing solution, enables the manual tester to perform operations (user actions) on an application while Sprinter captures and saves information about each user action in the background. This process is similar to recording steps on your application in UFT One.
After the Sprinter run session ends, the manual tester can export the captured user actions, test objects, and comments, to an automated test data file in XML format.
Import this file to UFT One to convert it to a UFT One GUI test with a local object repository.
This method helps to increase testing coverage for the application, as it creates a more seamless workflow between manual testers and automation experts that are testing the same application.