Incorporating PTF Best Practices
This section discusses how to incorporate PTF best practices.
Close all programs other than PTF and the PeopleSoft application browser during recording and execution of PTF tests. Other applications – especially those that alert the user with spontaneous notifications, such as email and instant messaging programs – can interfere with PTF and the PeopleSoft application browser and thus cause unexpected results during record and playback.
You 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
A 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 set or verify 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, it is best to explicitly enter the date value in the edit box.
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 pause the recording, deselect the check box, restart the recording, and then select the check box. Alternatively, you could click the check box twice and then delete the extra step from 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.
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.
Step 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.
You can add comments in RTF format to the test, test case, and steps to document your tests. Comments can include application snapshots.
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.
Employ configuration options and 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 setting configuration options to use Browser.Start_Login (it automatically inactivates the sequence of steps that records logging in (Steps 2 through 4) and replaces those steps with the single action, Browser.Start_Login) and using execution options for the user ID and password at the login page:
Image: Example of using Browser.Start_Login
This example illustrates inactivating the sequence of steps that record logging in (Steps 2 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:
Use of 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 instead directly access 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.
PTF can be configured to insert page prompt constructs automatically during recording. The default behavior is set by the PTF adminstrator on the Define Configuration Options page and can be overridden during recording using the recorder utility tools.
See the Page type actions Prompt and PromptOK for more details.
The Process step type with a Run action is useful for running processes through Process Scheduler.
When you select the Use Process Run check box before you record a process request, all actions in the run request standard page will be replaced by the step action Process.Run and any Process Monitor actions that are recorded will be ignored.
You can set the Use Process Run check box using PeopleSoft Internet Architecture (select ) for all tests, or you can select the check box from the Toolbar when you are ready to record a test (Configure Recording Settings icon).
The Process.Run step will handle the execution and return the process status. You can modify the parameters on the Process.Run step to indicate the expected results.
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.
The Process.Run step will capture all of the process information and you can modify the step parameters in PTF.
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 test scenarios show examples of how to 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 take advantage of the appropriate dynamic construct that will ensure that the test will work at execution time.
Avoid 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.
Follow these recommendations 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.
Verify the Internet Explorer Startup section has the Start with homepage selected. Otherwise, it may get difficult to record and playback.