DoxRunner
​
Transaction Timers
​​​ Recording Timers
Timers in the Test Case Template
Timer Section Structure
Components of a Timer
​
Overview
​
LoadRunner measures the response time of each step in a business process via the use of lr_start_transaction() and lr_end_transaction() Timers, which are inserted into a script at appropriate places.​
​
The way DoxRunner uses Timers makes recording a raw script much faster. Script development is also much faster. The resulting script is much cleaner.
​
With the Timers already documented, rescripting is much faster!
​
​​The Timer Long Name is designed with the LoadRunner Analysis Report in mind, as are the three Timer Types, and the use of the Phase concept.
​
The structure of the documentation makes the flow of a Business Process much easier to understand for those who need to read and understand Test Cases.
​
​​​​​​Timers have no presence in the Solution Document other than within Test Cases. That is, they are only documented in Test Cases.
Scripting​
​​​
Recording Transaction Timers
​
If you have taken the time and effort to document the Transaction Timers in a Test Case and intend to use the Process Raw operation, then recording a LoadRunner script is much easier than the traditional way.
Instead of typing in full timer names as you record, all you need to type in are the Timer IDs.
Also lr_end_transaction(), lr_think_time(), and web_reg_find() functions need not be recorded. DoxRunner automatically adds them into the script from the information in the documented Transaction Timers Section.
​​
Although it is normal to record transactions into at least three files (vuser_init.c, Action.c, and vuser_end.c), recording the DoxRunner way means that all transactions are recorded only into Action.c. This also speeds up recording.
Using the Phase column in the Timer table, the DoxRunner Process Raw operation will automatically move transactions from Action.c to vuser_init.c and vuser_end.c as required.
The Process Raw operation will also automatically replace the recorded Timer IDs with the full Timer Name, and insert the lr_think_time(), web_reg_find(), and lr_end_transaction() functions into the raw script at the correct place.
​
Rescripting is super-fast!
​​
Recording the traditional way
​
Recording the DoxRunner way
​
As you can see from the diagram below, there is a big difference when recording a script using the DoxRunner way. Because only the Timer ID is used, it is much faster than the traditional way.
The assumption is that you have created the relevant Test Case and documented all Timers as specified in the Documentation section below.
It is also advisable to have the Test Case open with the Timers table in view so that you can refer to any notes in the Notes column and maybe update the documented Timer as required.
Process Raw Operation
​
The DoxRunner Process Raw operation uses the documentation to convert a Raw Script to one that is often immediately useable in a test.
This section explains what happens with Timers when you initiate the Process Raw operation.
​
How Timers are configured by the Process Raw Operation​
If you follow the advice in the Recording page above, then VUGen will have only recorded a lr_start_transaction() at the beginning of each business process step. The lr_start_transaction() will only contain the Timer ID only. No lr_end_transaction() will be recorded.
For example, at the beginning of Timer ID '8', only the following will be recorded:
Timer Long Names
​
The Process Raw operation will replace the recorded Timer ID in the lr_start_transaction() function with the Timer Long Name. ​​This process starts with the Timer Name Template documented in the Configuration Section.
​
An example of a typical template is shown here:
​​
​
​
Using this example template and assuming a Test Case ID of 'CEP001' and Timer Name of 'Enter Details', the recorded Timer '8' will be updated by DoxRunner as shown here:
​
​
​
The advantage of this format is that the list of transactions in the LoadRunner Analysis Report is ordered by Timer ID within Test Case ID, making it easy to see how response times relate to the business process.
​
Note also that if there are less than 10 Timers, then the Timer ID of 8 will remain 8.
However, if there are any 2-digit Timers, then DoxRunner will change the Timer 8 to 08.
Further, if there are any 3-digit Timers, then DoxRunner will change the Timer 8 to 008.
​
Once again, this is for the LoadRunner Analysis Report is ordering.
​​​
Think Time
​​
When recording a raw script, the Think Time that LoadRunner records is not necessarily valid in a production environment. The scripter may be interrupted, or paused while figuring out the next step, or may go faster than a typical user. It is often more valid to look at each step and assess a reasonable time, then document that in the Think Time column.
The Process Raw operation will replace all lr_think_time() functions that LoadRunner recorded, with one using the value in the Think Time column as shown here:
​
Validation
​​
LoadRunner can be configured in the advanced recording options to influence whether to record web_reg_find() functions as shown here:
​
​
​
However those web_reg_find() functions are only configured for the text between the <title> tags.
​​
​
​
​
All recorded web_reg_find() functions are kept by Doxrunner. In this example, LoadRunner is configured to record xxx, and xxx is encountered in the response.
​
​
If the Validation column contains text, the Process Raw operation will insert a web_reg_find() function containing that text. In the example below, Timer 8 has "Estimate displayed" documented in the Validation column.
​
In addition, DoxRunner will compare the Validation Template CIs with the response and, if a match, insert the appropriate web_reg_find() function.
If the Validation column is empty, then validation text may be sourced elsewhere. Refer to here for more details.
Readability Comments
​
The Process Raw operation will make all functions associated with each Timer easy to identify by inserting an easy to see line and the Timer ID / Timer Name at the beginning of each step:
​
​
​
​
​
​
The Process Raw operation will insert the Expected Result just below the visual cue:
​
The Process Raw operation will add the End Transaction function just after the last request associated with the business process step:
If the Add Common Timers option was selected, the Process Raw operation will wrap the normal timers described above with another timer designed to accumulate all steps with the same name, irrespective of the Timer ID or Test Case they belong to (so long as all scripts are in the same test). This improves the statistics reported in the LoadRunner Analysis report for those common transactions:
If the Transfer Steps option was pressed, the Process Raw operation will identify steps with phase LI, TI, and LO and move them from Action.c to another action file depending on where specific text is located. Refer to here for more details.
​
How Timers are configured by the Process Raw Operation​
If you follow the advice in the Recording page above, then VUGen will have only recorded a lr_start_transaction() at the beginning of each business process step. The lr_start_transaction() will only contain the Timer ID only. No lr_end_transaction() will be recorded.
For example, at the beginning of Timer ID 8, only the following will be recorded:
The Process Raw operation will replace the Timer ID in the lr_start_transaction() function with the Timer Long Name in accordance with the Timer Template CI.
​
For example, a Timer Template of <Test Case ID> <Timer ID> <Timer Name> with Test Case ID of CEP001 and Timer Name of 'Enter Details' will result in a Timer Long Name shown here:
The Process Raw operation will also replace any recorded lr_think_time() functions with one using the value in the Think Time column as shown here:
​
All recorded web_reg_find() functions are kept. In this example, LoadRunner is configured to record xxx, and xxx is encountered in the response.
​
​
If the Validation column contains text, the Process Raw operation will insert a web_reg_find() function containing that text. In the example below, Timer 8 has "Estimate displayed" documented in the Validation column.
In addition, DoxRunner will compare the Validation Template CIs with the response and, if a match, insert the appropriate web_reg_find() function.
If the Validation column is empty, then validation text may be sourced elsewhere. Refer to here for more details.
The Process Raw operation will make all functions associated with each Timer easy to identify by inserting an easy to see line and the Timer ID / Timer Name at the beginning of each step:
The Process Raw operation will insert the Expected Result just below the visual cue:
The Process Raw operation will add the End Transaction function just after the last request associated with the business process step:
If the Add Common Timers option was selected, the Process Raw operation will wrap the normal timers described above with another timer designed to accumulate all steps with the same name, irrespective of the Timer ID or Test Case they belong to (so long as all scripts are in the same test). This improves the statistics reported in the LoadRunner Analysis report for those common transactions:
If the Transfer Steps option was pressed, the Process Raw operation will identify steps with phase LI, TI, and LO and move them from Action.c to another action file depending on where specific text is located. Refer to here for more details.
​
Setting the Think Time Options
​
Think Times for each business process step are documented in the Transaction Timers section.
When initiating the Process Raw operation, the dialog box illustrated on the right is presented, with the Think Time options.
​
You can choose whether to source the Think Times from the Think Time column of the Transaction Timers section of the test case document, or set it to a fixed value.
​
You can also specify the Think Time range if you want to randomize them. The Runtime Settings will be configured accordingly. However, the Process Raw operation sets the Think Time option in the Runtime Settings to be "Ignore think time", as shown below. This is to facilitate initial shakeout testing, where Think Time may slow down shakeout testing. Once shakeout testing is complete, you must review these options and set the one that is appropriate for your test.
​
Setting the Timer Options
​
DoxRunner supports three types of Transaction Timer:
​
-
Step - wrapped around all requests associated with one business process step;
-
Common - also wrapped around one business process step, but with any context such as the Test Case ID and Timer ID removed - only the Timer Name remains *;
-
End to End - wrapped around all requests in Action.c.
When initiating the Process Raw option, the dialog box on the right is presented, with several Timer options. The Add common timers and Add 'End to End' timer options are self-explanatory.
​
The Timer Name Template allows you to tailor the format of the Long Timer Name wherever it is used. The default is shown in the illustration on the right. The default can be changed using the Timer Name Template CI in the Configuration section, or you can alter it in the dialog box illustrated on the right. Some testers prefer underscores instead of spaces between the components.
​
* The Common timer names begin with an underscore so that when the Analysis Summary is prepared, they appear altogether at the top. In this way you can decide whether to delete them all, or delete all except a sub-set that may be of interest. For example, if a Timer Name of "Press Cane Estimate Button" appears in several scripts, their response times are grouped together in the one report summary line as "_Press Cane Estimate Button".
​
Example:
​
If all three timer types are configured as shown in the illustration above, then the following three transaction timers are inserted at the top of Action.c:
lr_start_transaction("CEP001 Cane Volume Estimation Process_End_To_End");
lr_start_transaction("_Enter Lot Number");
lr_start_transaction("CEP001 05 Enter Lot Number");
​
Points to note about the above example:
-
The Test Case ID is CEP001;
-
The Test Case Name is Cane Volume Estimation Process;
-
The Timer ID is 05;
-
The Timer Name is Enter Lot Number.
​
Validation Overview
​
There are three levels of validation covered here. DoxRunner supports two of them.
Standard VUGen
​
When recording, the setting in the illustration below allows VUGen to identify text between the title tags, and configure the script with web_reg_find() accordingly. This setting is compatible with the DoxRunner method.
​
Advantages:
1. All responses are examined and the web_reg_find() function is placed prior to the relevant request;
2. It's easy to set up and seamless when recording and replaying.
​
Disadvantages:
1. The LB and RB tags are not flexible - they are always <title> and </title>;
2. The tags aren't included in the web_reg_find() function.
For example, if <title>Create Purchase Order</title> is detected in a response, then the following is placed just prior to the relevant request:
web_reg_find("Text=Create Purchase Order", LAST);
​
Documenting Transaction Timers​
​​
​Overview
Timer Long Name
Timer Long Name Template
Timer Types
Standard
Common
End to End
Timer Section
Timer Section Title
Timer Section Description
Timer Table
Timer Table Column Headings
Timer ID
Notes
Timer Name
Expected Results
Think Time
Response Time NFR
Phase
Validation
Configuration Items
Timer Long Name Template
Validation Template
​​​
​
Overview​
​
This section is mandatory for all Test Cases.
​
It is mandatory in DoxRunner to include at least one Transaction Timer. ​​​​If the script doesn't require a Transaction Timer (it may be a part of background load, where measuring response times may not be important), a dummy Transaction Timer can be documented.
​
Assess the Section Title and update it if necessary.
​
Make sure the table has the two mandatory columns (ID and Configuration), each with the specified heading text.
​
Assess the table to see whether more columns are appropriate, especially a Description column.
​
Assess the Body Text between the Section Title and the Table and update it if necessary.
​
Make sure its bookmark is visible and located immediately before the first character of the Section Title (see each of the examples further down this page).
​
Do not change the bookmark.
​
If all ideal columns are included, then the section looks better when on a page with landscape orientation.
​
Getting Started
​​
Items 1 and 2 are typically only done once, with the occasional review and tweaking if necessary.
Item 3 is where all the action takes place.
​
1. Test Case Template
-
When the Test Case Template is downloaded from this site, tailor the Transaction Timer section using the guidelines in the Test Case Template instructions below.
​
2. When the Solution Document is downloaded:
-
tailor the Configuration Section for:
-
the default Timer Long Name template;
-
the default Validation template;
-
-
​review the NFR Section and update it with any NFRs that the business may require.
​
3. Create the Test Case(s).
For each Test Case:
-
manually step through the business process that the Test Case is meant to simulate;
-
add Timer rows in the table of the Transaction Timer Section - one Timer per Business Process step;
-
review the following components of each Timer:
-
the Expected Results;
-
the Think Time;
-
the NFR;
-
the Phase;
-
the Validation.
-
​​​​
Timer Long Name​
​
The Timer Long Name is constructed by the Process Raw operation from the Timer ID and Timer Name in accordance with a template specified as a CI in the Configuration section.
​
At a minimum it should consist of the ID and Timer Name, but ideally it should be prefixed by the Test Case ID so that it appears in the LoadRunner Analysis Report in a logical order.
​
For example, Timer ID 5 in the example above should ideally appear as "CEP001 05 Enter Lot Number'" in the analysis report, using the Timer Template that is the default when the DoxRunner Solution Document is initially downloaded. That default template is reproduced here:
<Test Case ID> <Timer ID> <Timer Name>
​​
Timer Types
​
Standard
​​
This is the standard timer type, and is the one documented in the Transaction Timers section. It is the one that is generated when recording the script. It is designed to time steps in a business process.
​
​Common
​
This timer type is not documented - it is generated automatically if selected when executing the Process Raw operation. It is simply wrapped around the standard Step timer type, but without any reference to the Test Case ID or the Timer ID.
​
It is designed to aggregate the response times across all scripts with the same Timer Name so that a test-wide view of these timers is reported in the Analysis report.
​
End to End
​
This timer type is not documented - it is generated automatically if selected when executing the Process Raw operation. It is simply wrapped around all steps in Action.c so that the total response time for all steps in all iterations is reported.
​
​​Timer Section
​​
As with most Managed Items, Transaction Timers are documented within a Microsoft Word section, as shown in the example below.
Due to the number of columns in the Timer Table, the Timer Section must be in a page that is oriented as Landscape.
​
A Transaction Timer section is mandatory, is semi-structured, and may appear in two places:​​
-
Any Test Case;
-
The Test Case Template document.
Each instance of the Transaction Timer section consists of:
-
a Section Title;
-
a Bookmark;
-
free-form Body Text;
-
a Table with, ideally, eight columns (ID, Notes, Timer Name, Expected Results, Think Time, Response Time NFR, Phase, and Validation);
-
Only the ID and Timer Name columns are mandatory, but the remaining six are highly recommended;
-
More columns can be added.
​
Because of the number of columns, it is recommended that the page is landscape oriented.
​​
​Timer Section Title​​​​
​
In the example above, notice the title and its three components:
​​​​​
​1. The Bookmark:​
-
It's Mandatory;
-
Located immediately before the Title Text;
-
Indicated by the small vertical bar located immediately before the Title Text;
-
If you cannot see the vertical bookmark bar, it's a good idea to configure Word so that bookmarks are visible;
-
The bookmark is created by the Process Raw operation when the Test Case is created;
-
Do not move it or change it. DoxRunner depends on it during its many operations;
-
Structure: Depends on which document it is embedded in:
- Test Case: P_APP056_Timers (where APP056 is the Test Case ID)
-
Test Case Template: P_Timers
-
Style: I_BodyText;
-
Length: Cannot be longer than 30 characters.
​
2. The Title Text is copied from the Test Case Template when the Test Case is created. It can be manually modified to any text desired, but it is best .
-
It's mandatory;
-
Located immediately after the bookmark and above the Description;
-
Structure: Free-format text;
-
Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5;
-
Length: Cannot be longer than 200 characters.
​
3. The triangle following the Title Text is a link to the top of the Test Case. It is useful for navigating around the Test Case.
It is useful, but not critical to any DoxRunner operation, so it can be deleted if it annoys you.​​​
​​​​​
Timer Section Description
​​​
-
It's optional;
-
Location: between the Timer Title and the Timer Table;
-
Structure: free-format text;
-
Style: I_BodyText;
-
Length: Cannot be longer than 1,000 characters.
​
When the Test Case is created, DoxRunner uses the Timer Description from the Test Case Template. It can then be updated to any text you like. DoxRunner operations do not use this text.
​​​
Timer Table Overview
​​​
The Timer Table is the heart of Test Case documentation and many DoxRunner operations.
​
-
It's mandatory;
-
Located: immediately below the Timer Description (or Timer Title if there is no Timer Description):
-
A minimum of two rows:
-
A Heading row and a Data row (one data row per Timer);
-
If there are no timers, the last Data row can contain empty cells;
-
-
Ideally eight columns:
-
ID, Notes, Timer Name, Expected Results, Think Time, Response Time NFR, Phase, and Validation;
-
More columns can be added;​
-
-
All cells must conform to specific rules, as described in the Column Headings below.​
​​​​​​​​​
Timer ID Column
​
DoxRunner identifies Transaction Timers by a
numeric ID followed by the Timer Name.
​
The ID is mandatory and is designed to ensure
that timers are reported sequentially.
​
The underlying assumption is that the steps in a business process are executed sequentially, hence the name of each timer is prefixed by a sequential integer so that the LoadRunner Analysis report also lists them sequentially, facilitating the understanding of the test by the report recipients.
​
The integer must be sequential but there is some
flexibility. It can have gaps which allows steps to increment by, say, 10 (ie. 10, 20, 30,...) or if a script has more than one stream, a longer gap can be utilized (ie. 1, 2, 3, 25, 26...etc).
When recording a script, use this number and only this number, as described in the recording section. That is, don't use the Timer Name when recording.
​
Do not leave the ID blank, and only use integers.
​
Notes Column
​
This column is designed purely to assist the scripter when recording a raw script. It does not appear in any script or report and is optional.
Use this column to enter notes that are useful to the person recording and debugging the script. When recording the script keep these notes visible to ensure you record correctly and/or update the notes if it's helpful.
​
Although some notes can be written when defining the test case, it is expected that most updates will occur when recording the first script. Update this column so that future scripters will find it easier to re-record it (including yourself). Include any gotchas, preparation, etc that is relevant to recording the step. Consider it a replacement for screenshots.
​
If the cell is insufficient to describe what is required, add a paragraph to the Scripting Notes section, and provide a link to it in the Notes cell. This is particularly useful if a screenshot is necessary.
​
Timer Name Column​
​
The Timer Name forms a part of the Full Timer Name. It is mandatory and should be a very brief alphanumeric description of the business process step so that it can be better identified by anybody who is the recipient of the analysis report. For example "Press Next", when reported in the Analysis, is meaningless. Consider "Accept Details Of Cane Estimate".
​
Make the Timer Name consistent across all scripts that use the same business process step. This way the Common Timer will represent all instances across all scripts in the Analysis report.
When all components of the full timer name are combined, it must conform to LoadRunner rules.
​
When recording a script, do not use it - use the Timer ID only, as described in the Recording section.
​
Expected Results Column
​
This is optional text description of what is expected when the step is executed in a LoadRunner test. The Process Raw operation includes it in the script as documentation (refer to the script illustration above).
​
Think Time Column
​
Although Think Time is entered by VUGen during recording, it is often unrealistic.
​
By including them in the Transaction Timer table, the scripter has the opportunity to tailor them based on a more appropriate value that represents how long it would take for a competent user to execute that step.
​
For example, if a tab or button is to be pressed, the think time would be short, whereas if text such as a description or a name is required, then the think time should be much longer
The ​Process Raw operation will (optionally) replace all think time functions that LoadRunner may have inserted, with the value from the Transaction Timer table, and places them immediately prior to the relevant start transaction timer (refer to the script illustration above).
​
Response Time NFR Column
​
This column is optional and documents the Response Time NFR in two possible ways:
-
As a value in seconds (example: 5.9 secs);
-
As a link to the NFR section when the NFR is more complex.
​
Since NFRs can be more complex than just pinning it down to a single response time, the latter option is recommended. It is easier when liaising with a Business Analyst - each step can then be categorized depending on its task, and each category can then be placed into the NFRs section and described at length.
​
Phase Column
​
The Phase is useful if you choose the easy way of recording a raw script. That is, if you choose to record ALL actions in Action.c rather than attempting to record the log-in sequence in vuser_init.c and the log-out sequence in vuser_end.c.
The Phase tells the Process Raw operation to move the appropriate steps from Action.c into the appropriate file.
​
There are four phases recognized by the Process Raw operation, and they must appear in the same order as the description of each here:
LI - Log In - optional - the step(s) needed to log in.
These are normally moved to vuser_init.c, or a function that is called from vuser_init.c
TI - To Iteration - optional - the step(s) needed to move the session from the login or home page to the first step of the iteration.
These are normally moved tovuser_init.c, or a function that is called from vuser_init.c.
I - Iteration - mandatory - the steps executed during each iteration. These are normally left in Action.c.
LO - Log Out - optional - the step(s) used after all iterations are complete.
These are normally moved to vuser_end.c, or a function that is called from vuser_end.c.
By default, when recording a script, VUGen will place all steps into Action.c (unless you configured it otherwise, which is not recommended here). Also by default, the Process Raw operation automatically moves steps from Action.c into another script file. Intuitively the LI and TI steps would be moved to vuser_init.c and LO steps moved to vuser_end.c, but it is more flexible than that. It actually moves the steps into any file that has the following signature(s):
// <Transfer phase LI to here>;
// <Transfer phase TI to here>;
// <Transfer phase LO to here>;
This allows one or more files to be placed in the _Included Files folder that allows better management of the session. Refer to <TBA> for more details.
​
Validation Column
​
When recording a script, VUGen provides the option of entering a value used by web_reg_find, but it limits the LB and RB to <title> and </title> respectively, and some applications do not include these tags in some responses. In addition, the web_reg_find function prepared by VUGen does not include the tags, so there is a risk that the page is wrong but the text is still in the response.
The options described here are more flexible. If you enter text into the Validation column, the Process Raw operation will automatically prepare web_reg_find functions using that text, and place it immediately prior to the first request of the step. Note that if the Transaction Timer includes multiple requests, the Process Raw operation only applies the web_reg_find() function to the first one. If any others are required, then they must be manually configured.
​
If the Validation cell is left empty for one or more steps, the Process Raw operation will attempt to determine a value using the Validation Template LB and Validation Template RB CIs defined in the Configuration section, if they are found in the appropriate response. By choosing appropriate LB and RB values, more cells in the Validation column will be empty and typing is reduced, enhancing the efficiency of re-recording the script. Even if you just emulate VUGen's rule and use <title> and </title>, these tags will be included in the web_reg_find function, improving accuracy.
If the Validation cell for a step is empty and either there is no Validation Template CIs, or the Process Raw operation could not find a value, then the following is placed into the script (where nnn is the snapshot event number):
​
// web_reg_find("Text=<update manually from response to snapshot event tnnn>", LAST);
In this case, even if a value cannot be found, typing is reduced because the function skeleton is prepared for you, but commented out. You can either do nothing (and take the risk that the wrong page is returned), or manually find a value in the response and update it manually (don't forget to un-comment it). If the latter, don't forget to also copy the text into the Validation cell so that it is automatically updated the next time you record the script.
Refer also to the Validation Template CIs in the Configuration section.
​​​
Validation Column in the Transaction Timer Section
​
Specific text can be specified for any business process step by inserting it into the validation column of the Transaction Timer section.
This is useful if no LB and RB can be identified, or if it is different to that specified in the Configuration section.
​
Example:
The illustration below shows that User Management is expected in the response.
This function is inserted immediately prior to the appropriate request whether the text is in the response when recording or not:
web_reg_find("Text=User Management", LAST);
Advantages:
1. The text can be tailored to a specific business process step.
​
Disadvantages:
1. After recording, the response must be manually examined for unique text then manually added to the cell in the Transaction Timer section.
​
Validation Template in the Configuration Section
​
The LB and RB can be specified as CIs in the Configuration section of the document. The Process Raw operation will search all responses and, if the LB and RB are identified, a web_reg_find() function is placed immediately prior to the relevant request. The LB and RB text is included in the web_reg_find() function.
​
Example:
The illustration below shows the boundaries to be <ins and </ins>.
If this text is found in the response: <ins>Create Purchase Order</ins> ...
...then this function is inserted immediately prior to the appropriate request:
web_reg_find("Text=<ins>Create Purchase Order</ins>", LAST);
Advantages:
1. The boundaries can be different to the VUGen default;
2. The tags are included.
​
Disadvantages:
1. May not apply to all responses.
​
Transaction Timers in the Test Case Template​
​​​
If the Test Case Template was downloaded into the same folder as the Solution Document folder, and updated to suit the organisation, then there is no more to do except create Test Cases from it. Further documentation must then be done within the Test Cases.
The Test Case Template is a Microsoft Word document that is downloaded from the DoxRunner website and placed on your PC into the same folder as the Solution Document.
The Transaction Timers exist in the Test Case Template as a Microsoft Word section.
​
When downloaded, the Test Case Template will have a skeleton Transaction Timer section.
​
It is assumed here that the skeleton Transaction Timer section will be manually updated to suit the documentation format of your organisation.​
​
That manual update must ensure that the following attributes remain in place:
-
​​​The Microsoft Word section is in a page oriented as landscape and is the only Managed Item in that page;
-
The title must be in place and must be formatted as Microsoft Word style named "I_Heading 3";
-
Other than that, the title can consist of any text - usually "Transaction Timers".​
-
-
The title must be immediately preceded by a bookmark named "P_Timers";
-
A generic description follows the title, must be formatted as Microsoft Word style named "I_BodyText";
-
The generic description is followed by a Microsoft Word table with a minimum of 8 columns and a minimum of 2 rows.
-
The first row consists of the column headings;
-
The second row is used for the first Timer. Subsequent Timers occupy subsequent rows (one Timer per row).
-
​
​​​​