Incorporating PTF Best Practices
This chapter discusses PeopleSoft Test Framework (PTF) best practices, which can help you create more robust, efficient, and maintainable tests, and will help to ensure that PTF tests the specific application functionality that you want tested.
Incorporating PTF Best Practices
This section discusses how to incorporate these PTF best practices:
Record first.
Document tests.
Clean up tests.
Use execution options.
Use page prompting.
Use the Process object type.
Make tests dynamic.
Adopt Naming ConventionsYou should understand these PTF test asset naming limitations:
Test names and test case names must be unique.
Tests and test case are PeopleTools managed objects, a very important type of PeopleSoft metadata. As a result, test names must be unique to a database and test case names must be unique to a test.
Test and test case names are limited to letters, numbers, and underscore characters.
The first character of any test or test case name must be a letter.
Test and test case names are limited to 30 characters.
You will find it easier to manage test assets if you adopt a systematic naming convention that reflects important characteristics of the tests and test cases you create. Here are a few suggested test characteristics that you can incorporate in your PTF test names:
Functionality being tested.
Include a brief indication of the functional area or business process validated by the test.
Priority. A short code, such as “P1,” to indicate priority can help testers more easily locate the tests that are critical or likely to be run most often.
Execution order.
PTF Explorer sorts tests alphabetically within each folder. It is sometimes useful to view tests in order of intended execution, especially if some tests depend on other tests having been run previously in the same database. Include a numeric component early in the name of the test to make alphabetic order equal to execution order.
It may seem simpler to use folders to categorize tests by the above characteristics. However, folder names are often not visible to the tester and do not appear on some PTF reports, such as the Test Maintenance Report. So, regardless of whether you categorize tests by folder, it is helpful to build test characteristics into the names of your tests.
The following three test names are examples of a naming convention that reflects functionality, priority, and intended execution order:
WRKFRC_P1_01_HIRE_REQD_FLDS
WRKFRC_P1_02_PERSON_CHNG 21
WRKFRC_P1_03_JOB_DATA_UPDAT
Record FirstA critical best practice when automating with PTF is to record first, and record whenever possible, to drive as much information, including PeopleTools metadata, into the recorded test as possible.
You must assertively record every test step from the test. That is, even if the input fields are already set to the expected value, you must explicitly enter or set that value when recording. The recorder only captures actions that you take against objects during record time. If you skip an object during recording because it is already set to the desired value, the test will ignore it and fail if the default value of the same object is different during execution.
When you record a date field that includes a calendar object that enables the user to select a date, you must explicitly enter the date value in the edit box. Do not use the calendar to select a date.
You may need to perform two actions instead of one. For instance, if the test instructions say to select a check box but the check box is already selected, then you will need to deselect it first, and then select it. Then delete the extra step in your test.
If you need to add a new step to a test, select the spot in the test where the new step will occur and record the step at the insertion point. Recording a step is more likely to drive accurate information into your test than trying to construct the entire step by editing the fields through the Test Editor.
See Also
Document Tests Make it part of your automation routine to take advantage of the description fields in PTF tests and test cases as often as possible. PTF test and test case names tend to be short and abstract, so longer descriptions will help you and future testers understand the functional purpose of available PTF tests and test data.
You can find description fields in:
Test description
Test properties
Test case description
Test case properties
Line information
Use the Log actions to make your tests self-documenting. For instance, you can add a Log.Message before a Test.Exec step to describe the test you are calling, and you can put a Log.Message in the called test to document what the test does.
Clean Up Tests Immediately after recording a test, review the recorded test data in the Test Editor and correct actions taken inadvertently during recording, such as:
Unnecessary or extra clicks on a clickable item, such as a check box.
Clicks on the wrong objects, such as links and images.
Incorrect text entered into text boxes.
Revise the recorded values in the Value field (for editable fields) and delete unneeded steps.
This might be a good time to evaluate whether you should incorporate reserved words and variables to replace static values that may be different when the test is executed.
See Also
Use Execution Options Employ execution options to take login information out of the test whenever appropriate. Suppose you have the following manual test step:
1. Log into your database as a user with the PeopleSoft User role.
Coding user-specific information into many tests may make future updates difficult if user IDs in the test environment are changed.
The following example shows how to make a recorded test easier to maintain by inactivating the sequence of steps that was recorded logging in (Steps 1 through 4) and replacing those steps with the single action, Browser.Start_Login, which takes the user ID and password from the execution options and enters them at the login page:
Example of using Browser.Start_Login
See Also
Use Page Prompting PTF page prompting steps make tests more robust and repeatable by simplifying test data and replacing it with intelligence built into the step.
Page prompting functions replace explicit navigation in the test and take the user directly to the component search page by URL manipulation. A test with the navigation explicitly defined can break when the navigation changes, even though the application is working fine. Page prompting avoids this problem.
Tests that use page prompting are more repeatable. Consider the following test instruction:
1. At the Define Calculation search page, add a calculation with the name KUSPTEST or, if it already exists, update it.
Using page prompting, a single step can navigate directly to the search page and either update or add a key, whichever is needed.
See the Page type actions Prompt and PromptOK for more details.
See Also
Use the Process Object TypeThe Process object type with a Run action is useful for running processes through Process Scheduler.
Suppose you have the following test scenario:
From the Request Calculation page, click the Process Monitor link. In Process Monitor, click the Refresh button until either Success or Error appears in the Run Status column for your process instance.
Replacing a recorded sequence of steps with the Process.Run step will make your test more robust. It will be less likely to fail if a change in performance affects processing time or if a PeopleTools enhancement modifies the structure of the Process Monitor page.
See Also
Make Tests Dynamic Many tests involve values and conditions that are not known until a test runs. Advanced functionality in PTF enables you to build tests that adapt to the application when necessary.
These examples of test scenarios can exploit the dynamic test features of PTF:
Variables
Requirement: A test that creates an entry in the application with a system-generated ID number and later has to verify that same ID number elsewhere in the application.
Solution: Store the system-generated ID to a variable in one step, and then reference that variable to verify the value in another step.
Conditional logic
Requirement: A test that specifies that the user click an icon to expand a section of a page, but only if that section is not already expanded.
Solution: Place the step in an If_Then construct that evaluates whether the section is expanded.
Scroll handling
Requirement: A test that updates an item in a grid regardless of the position of the item in the grid.
Solution: Use a Scroll action to identify the row by key rather than by position.
Reserved words
Requirement: A test that instructs the user to enter the date the test is executed into the application.
Solution: Use the #TODAY reserved word to enter the current date.
Dynamic steps improve the reusability and maintainability of tests.
As you are recording, be sure to make a note of situations that require dynamic handling so you can replace the recorded steps values with the appropriate dynamic construct that will ensure that the test will work at execution time.
See Also
Reduce DuplicationAvoid creating tests and test steps that are duplicated elsewhere. When multiple tests validate similar functionality, it increases the complexity of test maintenance and the amount of manual work necessary to add or change test functionality later.
Take these steps to help keep test duplication to a minimum:
Drive similar tests into test cases.
Do this any time multiple tests have the same logic and where the only difference among the tests is the data entered or validated. A test to hire two employees or to create ten new vouchers would be a good candidate for taking advantage of test cases.
Isolate sequences of test steps into called tests or libraries whenever the steps are identical.
A procedure that verifies or sets the same setting on an installation table would be a good candidate for putting into a library if multiple products or tests modify the same setting.
See Also