top of page

Overview

 

The Test Case Template is a semi-structured document used as the basis for creating new test cases. It's assumed you have downloaded it from here along with the other two documents.

​

When downloaded, the first thing to do is update the styles to suit the documentation requirements of your organisation and the guidelines set out below. No pages headers or footers exist because those in the Solution document are used when a new test case is created.

 

Once that is done, there is value in tailoring the remainder of the template to suit the Solution. Appropriate tailoring will save typing when documenting new test cases. Note that you may take an iterative approach, tailoring it as you become more familiar with the characteristics of the test cases in the solution, and as you develop scripts.

 

Additional sections can be added if those described here don't cover all of your needs, but they will be ignored by DoxRunner's Test Case and Script operations.

 

Once you are happy with the template, save it and make sure it's still located in the same folder as the relevant Solution document (Configuration Item: Support Folder).

​

Also make sure the name remains Test Case Template.docx because that's the only name recognized by DoxRunner's Test Case and Script operations.

​

​

Bookmarks

 

Test Case Template bookmarks

 

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

​

The Test Case Template contains generic bookmarks - one per managed section. When it is converted into a test case, they are all changed to include the Test Case ID. For example if the Test Case ID is TC080, then bookmark P_BriefDescription is changed to P_TC080_BriefDescription. This is so that the DoxRunner's Test Case and Script operations can manage them when creating a test case. 

​

Summary

​

​

FormatAndStyle

 

Test Case Template format and styles

 

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

​

The styles used in the Test Case Template are listed here. They are the same as those in a Test Case and in the Solution document.

  • I_BodyText

  • I_Caption

  • I_Appendix 1 to I_Appendix_5

  • I_Heading_1 to I_Heading_5

  • I_Heading Not Numbered

  • I_TableText

  • I_TableHeading

​

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

​

Sections

 

Test Case Template Sections

 

A section is one of the building blocks of the documents described in this site.

​

Like those in the Test Cases and in the Solution document, the sections in the Test Case Template are semi-structured. They consist of a bookmark, a title, body text, and, often, a table.

​

Although the focus here will be on the sections in the Test Case Template, they are almost identical to those in the test case when a test case is created from the template.

 

The difference is that the contents of each section in the Test Case Template are expected to be empty (although that is not necessary), whereas those in the test case are expected to be fully populated.

 

Also the bookmarks are structured slightly different. When creating a test case, each bookmark will be updated to include the Test Case ID.

 

The title of any section can be any text up to 200 characters, but the Microsoft Word style should begin with I_Appendix or I_Heading.

​

The body text can be any text up to 1,000 characters. The Microsoft Word style should be I_BodyText.

 

All sections in the Test Case Template must be manually managed. That is, to delete a section, it must be done manually. To add a section, it must also be done manually. Follow the More details links for, well, more details.

​

The following paragraphs on this page describe each section in brief.

 

DesciptionSections

 

Description sections

 

These seven sections appear on the first page of a test case when it is created. Five of the sections are automatically copied into vuser_init of the script by the Process Raw operation.

 

Advice

​

  • Follow the More details link to better understand the sections as they will appear in a new test case;

  • Assess each one and delete any that aren't required (make sure its associated bookmark is deleted). If unsure, leave them in;

  • Pre-populate the sections with text that you think will reduce the amount of typing needed for any new test case;

  • Add sections as required (new sections will appear in new test cases, but will not be included in Script operations).

​

Example:

 

Timers

 

Timers section

​

Timers are very important for measuring response times during a load test. Hence this section is mandatory in every test case.

​

The bookmark in the template is P_Timers.

​

It is located at the end of a Test Case because it is best on a page oriented as landscape.

​

TestDataSections
Timers.gif

 

Test data sections

​

Test data is critical to the execution of scripts during a test. The test case documentation caters for three types of test data as shown in the illustration below. All of them are optional and can be deleted.

​

Description

 

All three sections are highly structured and consist of a bookmark, a title, body text, and a table.

​

The bookmarks are:

  • P_TextData;

  • P_LoadTestDatabase;

  • P_VTS.

​

The tables must contain at least two columns headed Parameter and Configuration. 

 

Additional columns are ignored by DoxRunner's Test Case and Script operations.

​

A Description column is optional but recommended.

 

Advice

 

  • Follow the green More details links above to familiarize yourself with each section;

  • Make sure bookmarks are visible;

  • Do not change the bookmarks;

  • Assess each of the three sections and decide whether you will ever need them in any test case. If unsure, leave them in;

  • Manually delete any that you know you will never need. Make sure the associated bookmark is also deleted;

  • Assess the title of each of the three sections and update the text if necessary - make sure you don't change the location of the bookmark that is placed in front of each title;

  • Assess the body text between the title and the table and update the text if necessary. Use generic text that you expect to apply to most test cases - you will most likely tailor it in the resulting test case;

  • Leave the table with the heading row and one empty data row - populate the rows only when the test case is created;

  • Add columns that you think may be necessary for any new test case;

  • The sections look better when on a page with portrait orientation, unless you have added columns and expect the table to be much wider than the default. 

​

CorrelatonSectons

 

Correlation Rules

 

Correlation is critical to the execution of scripts during a test. The test case caters for two types of correlation as shown in the illustration below. Both of them are optional and can be deleted.

​

Description

 

Both sections are highly structured and consist of a bookmark, a title, body text, and a table.

​

The bookmarks are:​

  • P_BoundaryCorrelation;

  • P_RegexCorrelation.

​

The table must contain at least three columns headed Parameter, Role, and Configuration. 

 

Additional columns are ignored by DoxRunner's Test Case and Script operations.

​

The Role column can only contain Request or Response.

​

A Description column is optional but recommended.

 

Advice

 

  • Follow the green More details links above to familiarize yourself with the purpose of each section;

  • Make sure bookmarks are visible;

  • Do not change the bookmarks;

  • Assess each of the three sections and decide whether you will ever need them in any test case. If unsure, leave them in;

  • Manually delete any that you know you will never need. Make sure the associated bookmark is also deleted;

  • Assess the heading of each of the three sections and update the text if necessary - make sure you don't change the location of the bookmark that is placed in front of each heading;

  • Assess the body text between the heading and the table and update the text if necessary. Use generic text that you expect to apply to most test cases - you will most likely tailor it in the test case that is created from the template;

  • Leave the table with the heading row and one empty data row - populate the rows only when the test case is created;

  • The sections look better when on a page with portrait orientation. 

​

OtherParameterSections

 

Other parameters

 

In addition to the parameterization of test data as shown in the three Test Data sections above, DoxRunner's Test Case and Script operations recognize another four types of parameter as shown in the illustration below.

​

The Process Raw operation uses these four sections to enhance raw script parameterization. 

 

All of them are optional and can be deleted.

​

Description

 

All four sections are highly structured and consist of a bookmark, a title, body text, and a table.

​

The bookmarks are:

  • P_Custom;

  • P_DateTime;

  • P_Random;

  • P_AdditAttr.

​

The table must contain at least two columns headed Parameter and Configuration. 

 

Additional columns are ignored by DoxRunner's Test Case and Script operations.

 

A Description column is optional but recommended.

 

Advice

 

  • Follow the green More details links above to familiarize yourself with the purpose of each section;

  • Make sure bookmarks are visible;

  • Do not change the bookmarks;

  • Assess each of the four sections and decide whether you will ever need them in any test case. If unsure, leave them in;

  • Manually delete any that you know you will never need. Make sure the associated bookmark is also deleted;

  • Assess the title of each of the remaining sections and update the text if necessary - make sure you don't change the location of the bookmark that is placed in front of each title;

  • Assess the body text between the title and the table and update the text if necessary. Use generic text that you expect to apply to most test cases - you will most likely tailor it in the test case that is created from the template;

  • Leave the table with the heading row and one empty data row - populate the rows only when the test case is created;

  • The sections look better when on a page with portrait orientation. 

​

OtherSections
OtherParameters.gif

 

Other sections

 

In addition to the parameter sections as shown above, above, DoxRunner's Test Case and Script operations recognize another two rule types as shown in the illustration below.

 

Both of them are optional and can be deleted.

​

If they are relevant, the Process Raw operation uses them to enhance raw scripts. 

​

Description

 

Both sections are highly structured and consist of a bookmark, a title, body text, and a table.

​

The bookmarks are:

  • P_Headers;

  • P_SAPGUI.

​

Additional columns are ignored by DoxRunner's Test Case and Script operations.

 

A Description column is optional but recommended.

 

Advice

 

  • Follow the green More details links above to familiarize yourself with each section and the rules they are expected to contain when incorporated into new test cases;

  • Make sure bookmarks are visible;

  • Do not change the bookmarks;

  • Assess each section and decide whether you will ever need them in any test case. If unsure, leave them in;

  • Manually delete any that you know you will never need. Make sure the associated bookmark is also deleted;

  • Assess the title of each of the remaining section and update the text if necessary - make sure you don't change the location of the bookmark that is placed in front of the title;

  • Assess the body text between the title and the table and update the text if necessary. Use generic text that you expect to apply to most test cases - you will most likely tailor it in the test case that is created from the template;

  • Leave the table with the heading row and one empty data row - populate the rows only when the test case is created;

  • The sections look better when on a page with portrait orientation. 

​

Headers.gif
SAPGUI.gif
bottom of page