Document a Test Case

It may be identical to a business process, or it may be a subset of one, or it may consist of more than one business process. Regardless of that relationship, there is only one script per test case (although there can be multiple versions of that script).

It forms the heart of DoxRunner's Test Case and Script operations, so it must be semi-structured, using bookmarks and tables to balance the advantages of DoxRunner's Test Case and Script operations versus documentation flexibility. It is key to improving the efficiency of performance analysts by saving time during re-scripting.

The primary location for all test cases is within a Solution document. Each test case within a Solution document is the target of a bookmark, described below, and each test case has several bookmarks embedded within it.

It can be checked out as a standalone document which can be sent to individual team members, including offshore teams. It can then be checked back in if it was updated while checked out.

The following is a list of the Test Case operations that DoxRunner supports:

TestCaseNaming

Test case naming

Test case names are structured to enhance DoxRunner's Test Case and Script operations. As a side-effect, test case names across all solutions in an organisation become consistent.

All names are made up of a Test Case ID plus a Test Case Name separated by a mandatory space.

Example: TC001 My Test Case Name.

Test Case ID

The Test Case ID is designed to be short for unique reference to a test case and to any script related to that test case. It must be no longer than 6 characters, with the first characters between 1 and 3 letters (A-Z) and the last characters between 1 and 3 digits (0-9).

Spaces and other characters are not allowed. This is because the Test Case ID forms a critical component of the bookmarks used in all test cases, and bookmarks cannot contain spaces.

The name of all versions of the script that relate to the test case must also begin with the same ID.

TestCaseID

Test Case Name

The Test Case Name can be any alphanumeric text up to 30 characters.

TestCaseName

Bookmarks

Script Naming

One test case can describe one script or multiple versions of the same script.

The script names relating to a test case must consist of the Test Case ID, followed by an underscore, then followed by up to 30 alphanumeric characters. Underscores should be used instead of spaces because some versions of LoadRunner won't accept spaces.

The component of the script name following the Test Case ID component does not need to match the Test Case Name - only the IDs need to match.

For example, the following script names all relate to test case TC001 My Test Case Name:

TC001 My Test Case Name

TC001 My Test Case Name Version 4

TC001 Fred 2020-10-05

ScriptName

Test case bookmarks

Bookmarks are essential to DoxRunner's Test Case and Script operations. Unless they are faulty, or point to the wrong place, or you are deleting an optional section, there is no need to change them. Feel free to add more for internal documentation references once you have finished tailoring the document.

Because the test cases are normally embedded in the Solution document, the Solution document contains many that aren't related to test cases. Refer to the Solution document for more details on these.

All test case related bookmarks are prefixed by P_ followed by the Test Case ID, then followed by an underscore, then followed by text relevant to the purpose of the bookmark.

Examples and brief descriptions are listed below (Test Case ID TC001 is used for illustration):

P_TC001 - Critical - points to the title of the test case - do not delete (unless you're deleting the test case manually);
P_TC001_AdditionalAttributes - Optional - points to the Additional Attributes section if it exists;
P_TC001_BoundaryCorrelation - Optional - points to the Boundary Correlation Rules section if it exists;
P_TC001_BriefDescription - Optional - points to the Brief Description section if it exists;
P_TC001_Custom - Optional - points to the Custom Parameters section if it exists;
P_TC001_DateTime - Optional - points to the Date / Time section if it exists;
P_TC001_Headers - Optional - points to the Headers section if it exists;
P_TC001_Purpose - Optional - points to the Purpose section if it exists;
P_TC001_LoadTestDatabase - Optional - points to the LoadTest Database section if it exists;
P_TC001_RandomNumber - Optional - points to the Random Numbers section if it exists;
P_TC001_RegexCorrelation - Optional - points to the Regex Correlation Rules section if it exists;
P_TC001_ReleaseNotes - Optional - points to the Release Notes section if it exists;
P_TC001_SAPGUI - Optional - points to the SAP GUI section if it exists;
P_TC001_ScriptHistory - Optional - points to the Script History section if it exists;
P_TC001_Timers - Critical - points to the heading of the Transaction Timers section - do not delete (unless you intend to delete the test case manually);
P_TC001_SuccessCriteria - Optional - points to the Success Criteria section if it exists;
P_TC001_TextDataFile - Optional - points to the Text Data File section if it exists
P_TC001_VTS - Optional - points to the VTS section if it exists.

General Details

FormatAndStyles

Test case format and styles

The Test Case Template and the Solution document, when downloaded from this site, have a specific format and use specific Microsoft Word styles.

The styles used in the test case are the same as those in the Solution document and are listed here:

I_BodyText
I_Caption
I_Appendix 1 to I_Appendix_5
I_Heading_1 to I_Heading_5
I_TableText
I_TableHeading

Modify each of these styles to suit your organisation's document style guide.

Sections

Test case sections

The below is a summary of the managed sections that can be found in a test case.

These are semi-structured so that DoxRunner's Test Case and Script operations can manage them.

Other sections can be added if they contribute to understanding the test case, but the DoxRunner's Test Case and Script operations will ignore them.

This site divides the section descriptions into how they are documented and how the documentation is used by DoxRunner's Test Case and Script operations: