Using Reserved Words
This section discusses how to use reserved words.
Reserved words enable you to access data available from the PTF program when a test is executed.
Reserved words are useful when data is not known before the test is executed. For example, suppose you have the following manual test instruction:
12. Enter the current date into the Voucher Creation Date field.
If, when you record the step, you enter the current date, then you will put specific, or static, data into the test, similar to the following example, which shows the data created by a test recorded on June 30, 2010:
Image: Example of a Test Step with Static Data
This example illustrates a test step with static data for the date.
However, the test instruction calls for the current date, which may be different each time you run the test. Data that can change is called dynamic data. To make the test data in PTF dynamic, replace the recorded data with the #TODAY reserved word, which represents the date at the moment of test execution, as shown in this example:
Image: Example of Test Step Using the #TODAY Reserved Word
This example illustrates a test step using the #TODAY reserved word.
Other reserved words enable you to define specific actions in the Value field of a step.
For example, suppose you are required to test two very similar test scenarios:
1. Create a new pension calculation using the following parameters. 2. Open the pension calculation created earlier and verify that the parameters entered into the application are the same as those specified in the previous scenario.
You can meet this requirement by using a single test step with two test cases. The first test case might be named CREATE and the second named VERIFY.
In the CREATE test case, a step that sets the Calculation Description field might look like this:
Image: Example of a Step that Sets a Value
This example illustrates a step that sets a value.
The VERIFY test case uses the reserved word #CHECK# in the Value field. Using the same step, the #CHECK# reserved word causes the Set_Value action to behave like a Verify action, which satisfies the second test scenario. Rather than setting the value of the object, the same step now verifies it, as shown in this example:
Image: Example of a Step that Verifies a Value
This example illustrates a step that verifies a value.