top of page

Overview

 

A section is one of the building blocks of the documents described in this site. Although the focus of this page 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. The difference is the bookmarks and the content in the Test Case Template is expected to be empty (although that is not necessary), whereas those in the test case are expected to be fully populated.

 

Like those in the test cases and the Solution document, they are semi-structured. They consist of a bookmark, a heading, body text, and, often, a table.

​

When creating a test case, each bookmark will be updated to include the Test Case ID.

​

Each heading can be any text, but the Microsoft Word style should begin with I_Appendix.

​

Each 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.

​

The following paragraphs on this page describe each section in brief. Follow the More details links for, well, more details.

 

Description

 

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;

  • In the Test Case Template, 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 (any new sections won't appear in the script);

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

 

TestData

 

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 heading, body text, and a table.

  • The bookmarks are:

    • P_TextData;

    • P_LoadTestDatabase;

    • P_VTS.

  • The table must contain at least two columns headed Parameter and Configuration. Additional columns are ignored by DoxRunner 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 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. 

​

CorrrelationRules

 

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 heading, body text, and a table.

  • The bookmarks are:

    • P_RegexCorrelation;

    • P_BoundaryCorrelation.

  • The table must contain at least three columns headed Parameter, Role, and Configuration. Additional columns are ignored by DoxRunner operations. A Description column is optional but recommended;

  • The Role column can only contain Request or Response.

 

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. 

​

AdditionalAttributes

 

Additional Attributes

​

Additional attributes are very handy, especially for URLs. The documentation is treated in a manner similar to other parameters, but the Process Raw operation goes the extra mile and configures the runtime settings appropriately.

​

Description 

 

The section is highly structured and consists of a bookmark, a heading, body text, and a table.

  • The bookmark is:

    • P_AdditionalAttribute.

  • The table must contain at least two columns headed Parameter and Configuration. Additional columns are ignored by DoxRunner operations. A Description column is optional but recommended;

​

Advice

​

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

  • Make sure bookmarks are visible;

  • Do not change the bookmark;

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

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

  • Assess the heading and update the text if necessary - make sure you don't change the location of the bookmark that is placed in front of the 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 section looks better when on a page with portrait orientation. 

​

OtherParameters

 

Other parameters

 

In addition to the parameterisation of test data shown in the three Test Data sections above, DoxRunner operations recognize another three types of parameter as shown in the illustration below. The Process Raw operation uses these three sections to enhance raw script parameterisation.  All of them are optional and can be deleted.

​

Description

 

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

  • The bookmarks are:

    • P_Custom;

    • P_DateTime;

    • P_Random.

  • The table must contain at least two columns headed Parameter and Configuration. Additional columns are ignored by DoxRunner 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 three sections and decide whether you will ever need them in any test case;

  • 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. 

​

Headers

​

Headers section

​

Most sites don't require special documentation for headers. This section caters for those sites that do use headers extensively.

No DoxRunner operation uses this section - it only exists for documentation.

​

Description 

 

The section is highly structured and consists of a bookmark, a heading, body text, and a table.

  • The bookmark is:

    • P_Header.

  • The table must contain at least two columns headed Parameter and Value. Additional columns can be added. A Description column is optional but recommended;

​

Advice

​

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

  • Make sure bookmarks are visible;

  • Assess it and decide whether you will ever need it in any test case;

  • If you believe that it is relevant in the Test Case Template:

    • Manually add it to the Test Case Template;

    • Type in a heading that is appropriate to the solution - see the illustration below for the standard heading;

    • Make sure the bookmark P_Heading is placed in front of the heading;

    • Type in generic body 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;

    • The section looks better when on a page with portrait orientation. 

​

​

SAPGUI section tba

​

Most sites don't require special documentation for headers. This section caters for those sites that do use headers extensively.

No DoxRunner operation uses this section - it only exists for documentation.

​

Description 

 

The section is highly structured and consists of a bookmark, a heading, body text, and a table.

  • The bookmark is:

    • P_Header.

  • The table must contain at least two columns headed Parameter and Value. Additional columns can be added. A Description column is optional but recommended;

​

Advice

​

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

  • Make sure bookmarks are visible;

  • Assess it and decide whether you will ever need it in any test case;

  • If you believe that it is relevant in the Test Case Template:

    • Manually add it to the Test Case Template;

    • Type in a heading that is appropriate to the solution - see the illustration below for the standard heading;

    • Make sure the bookmark P_Heading is placed in front of the heading;

    • Type in generic body 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;

    • The section looks better when on a page with portrait orientation. 

​

SAPGUI
Configuration

 

Configuration section

 

This section is expected to be used rarely within a test case, so it does not appear in the downloaded template.

 

An abbreviated instance can reside within a test case where a test case needs to use a configuration item that is different to the one in the Solution document.

​

If it is expected that most test cases require a separate Configuration section, it can be manually added to the Test Case Template.

​

The Configuration section that resides within the Solution document is the one that is normally used and the CIs it contains are applied globally across all test cases.

​

Description

 

If used, it is highly structured and consists of a bookmark, a heading, body text, and a table.

  • The bookmarks are:

    • P_Configuration.

  • The table must contain at least two columns headed Type and Value. Additional columns are ignored by DoxRunner 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;

  • Assess it and decide whether you will ever need it in any test case;

  • If you believe that it is relevant in the Test Case Template:

    • Manually add it to the Test Case Template;

    • Type in a heading that is appropriate to the solution - see the illustration below for the standard heading;

    • Make sure the bookmark P_Configuration is placed in front of the heading;

    • Type in generic body 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;

    • Populate the rows with the CIs that are expected to be unique to the test cases - they will override the corresponding CIs from the Solution document instance;

    • The section looks better when on a page with portrait orientation. 

​

The illustration below shows an example where three CIs are configured in the template. These three CIs will be included in all new test cases created from the template. During the Process Raw operation they will override the corresponding three from the Configuration section in the Solution document.

​

Timers

 

Transaction Timers section

 

The focus of the Transaction Timers section is the configuration of the start and end timers.

​

Description 

 

The section is mandatory and is highly structured. It consists of a bookmark, a heading, body text, and a table.

  • The bookmark is:

    • P_Steps.

  • The table must contain  at least eight columns with the following headings:

    • Step, Notes, Step Name, Expected Result, Think Time, Response Time NFR, Phase, Validation;

  • A Description column is not necessary because the Notes and Expected Results columns should provide sufficient information.

​

Advice

​

  • Do not delete this section;

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

  • Do not change the bookmark;

  • Assess the heading and update the text if necessary - make sure you don't change the location of the bookmark that is placed in front of the 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 in place;

  • Decide whether to populate some rows with data such as login and logout that may be repeated across multiple test cases;

  • The section looks better when on a page with landscape orientation. 

​

TestCaseTemplateSectionOperations

 

Test Case Template section operations

 

Sections in the Test Case Template can only be added or deleted manually.

​

Delete section manually
Add section manually
bottom of page