Share this page
GUI test creation overview
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.
Keyword-driven methodology
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 OpenText Functional Testing 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, OpenText Functional Testing 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. |
| Earlier start |
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. |
Recording
Let OpenText Functional Testing 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 OpenText Functional Testing 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 OpenText Functional Testing users learn how OpenText Functional Testing interprets the operations you perform on your application, and how it converts them to OpenText Functional Testing objects and built-in operations. |
| Better for new applications or features |
Recording can be useful for more advanced OpenText Functional Testing 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 OpenText Functional Testing 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. |
Importing tests from Sprinter
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 OpenText Functional Testing.
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 OpenText Functional Testing to convert it to an OpenText Functional Testing 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.
