Solution Document

The Solution document is the central repository for one or more test cases.

It is central to all DoxRunner operations.

It is semi-structured and contains information such as:

The solution description;
Scripting tips, gotchas, and workarounds;
Performance oriented Non-Functional Requirements (NFRs);
Transaction rates;
Transaction volumes;
Scenarios;
DoxRunner Configuration Items;
Business Process descriptions;
Solution history;
Contacts;
Defect criteria and processes;
Test cases.
...and more.

Follow the getting started instructions below to set it up once you have downloaded it.

Getting Started

When downloaded, make sure it's saved into the Support folder and a copy is saved into an archive folder.

The first thing to do is update the styles to suit the documentation requirements of your organisation and the guidelines set out below. Update them, but don't delete them.

Once that is done, review the bookmarks. Follow any that point to items that you know will be irrelevant to any test case, then, carefully, manually delete the section that they point to.

Depending on the complexity of your organisation, you may decide to have one document for all solutions, or one document for each solution, or several documents containing one or more solutions.

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

Solution document format and styles

Like the Test Case Template, when downloaded from this site the solution document has a semi-structured format and uses specific Microsoft Word styles. It's unlikely that the styles match those used by your organisation. However, DoxRunner operations need to use them, so don't delete them. When editing the document, please only use these style names for all text managed by DoxRunner.

DoxRunner operations don't need to know anything about how those styles look, so it's worthwhile examining each of the below styles with a view to updating them to match those used by your organisation.

They are listed here. They are the same as those in the Test Case and the Test Case Template.

I_BodyText - used instead of Normal;
I_Heading_1 to I_Heading_5 - used as the heading text for all sections managed by DoxRunner;
I_TableHeading - used as the first row of all tables managed by DoxRunner;
I_TableText - used for all data rows in all tables managed by DoxRunner.

Solution document title page

DoxRunner doesn't use the title page, so it can be configured any way you want.

The following text and illustration is a suggestion only.

Since you will most likely be navigating between test cases, the link to the Test Case Summary section is very handy.

When downloaded, the document contains the text <Organisation Name> and <Solution Name>.

Change all occurrences of these to the names you want to use.

In the examples, organisation 'DoxRunner' and solution 'Cane View' are used.

Solution document page header

Scroll down to the page after the title page and double-click on the heading area.

The default page header consists of a one-row table with three cells. The table only has one border, and that is the bottom one, to clearly delineate the header from the main part of the page. The fact that it's a table isn't obvious and is irrelevant to a person reading the document. The DoxRunner operations ignore it.

You can organise the page header any way you want to suit your organisation and solution - the following is a guide only:

The first cell contains the organisation name - change it to suit yours. The example below uses 'DoxRunner';
The second cell contains the title and the solution name. Change both to suit your solution - 'Cane View' is used in the example;
The third cell contains - you guessed it - your logo. Replace the one there with yours.

Solution document page footer

The page footer contains the document's name. It's highly likely that you've saved the solution document to a different name. So it's useful to update the page footer.

Like the page header, it consists of a single-row table. Only the top has a border to delineate it from the main part of the page.

It has 5 cells. Double-click on it to edit it.

The first cell contains the name of the document. The remaining 4 cells contains page number details.

As with the other components, this is a guide only - you can organise it any way you want to suit your organisation and solution.

Solution document 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.

Refer to the bookmarks page for details on Microsoft Word bookmarks:

How to access bookmarks;
How to make bookmarks visible.

Bookmarks that are specific to test cases are prefixed by P_ and are described on the Test Case page. If you are reviewing the solution document for the first time, it's unlikely that you will find any that start with P_. They appear only when you create one or more test cases.

Bookmarks that are specific to the solution document are prefixed by V_. They are listed below in two groups.

The following lists those that don't belong to a test case:

V_TestCaseSummary - Critical - points to the heading of the Test Case Summary section - do not delete;
V_Configuration - Critical - points to the heading of the DoxRunner Configuration Items section - do not delete;
V_PerformanceSolutionDocument - Critical - located at the beginning of the embedded test cases - used to verify that the document that is open and in focus can be used to execute DoxRunner Test Case and Script operations - do not delete;
V_TestCases - Critical - points to the beginning of the embedded test cases. Needed to insert the first test case and those subsequent test cases that have a Test Case ID lower than existing ones. Do not delete.

The following also don't belong to an individual test case, but they augment equivalent sections in a test case. They are useful where a Managed Item exists across multiple test cases. That is, they contain Managed Items that are common across multiple test cases. They are all optional. If the section that any one points to is not required, then it can be manually deleted.

V_AdditionalAttributes - Optional - points to the Additional Attributes section if it exists;
V_CorrelationRules - Optional - points to the Correlation Rules section if it exists;
V_CustomParameters - Optional - points to the Custom Parameters section if it exists;
V_DateTimeRules - Optional - points to the Date / Time section if it exists;
V_Headers - Optional - points to the Headers section if it exists;
V_LoadTestDatabase - Optional - points to the LoadTest Database section if it exists;
V_NFRs - Optional - points to the Non Functional Requirements section if it exists;
V_RandomNumbers - Optional - points to the Random Numbers section if it exists;
V_RegexCorrelation - Optional - points to the Regex Correlation Rules section if it exists;
V_SAPGUI - Optional - points to the SAPGUI rules section if it exists;
V_TextDataFile - Optional - points to the Text Data Files section if it exists;
V_VTS - Optional - points to the Virtual Table Server (VTS) section if it exists.

How to make bookmarks visible

How to follow a bookmark

Verify the bookmarks by pressing the Insert tab and then the Bookmark link on the Microsoft Word ribbon.

If the Bookmark link isn't displayed, the page may have been narrowed, in which case a Links drop-down will be visible instead. A Bookmark icon can be found there.

As mentioned above, the solution document contains two classes of bookmarks - refer to the two images below.

- those specific to the solution document - they start with V_;

- those specific to a test case - they start with P_.

Verify the targets of the bookmarks by selecting each and pressing the Go To button.

Solution document sections

Test case summary section

Glossary of terms

Managed items

For a generic description of Word sections and DoxRunner sections, refer to the following:

All of the test cases that are embedded in the solution document reside in their own Word sections, delimited by 'Next Page' section breaks. Within each test case there are DoxRunner sections, but they aren't discussed here - refer to the section discussion within the Test Case documentation.

Outside of the test cases, the solution document contains its own DoxRunner sections.

The most important of these is the Test Case Summary section and the DoxRunner Configuration Items section.

The glossary of terms is important also, but optional, and DoxRunner operations don't use it.

Finally, the solution document contains one Doxrunner section per Managed Item, all of which are optional except for the DoxRunner Configuration Items section.

If a Managed Item section is optional and not relevant to the solution, delete it. Sections in the solution document can only be deleted manually. If deleting a managed section, make sure you delete its referencing bookmark too. It helps to make bookmarks visible.

Other DoxRunner style sections can be added manually if they add value, but the DoxRunner Test Case and Script operations will ignore them.

Test case summary section

The Test Case Summary section is critical to the successful execution of all DoxRunner Test Case and Script operations.

Navigate to it using bookmark V_TestCaseSummary.

It contains a table. Each row in the table links to the details of a Test Case, which reside elsewhere in the solution document.

The rows and links are managed by the DocRunner Test Case operations: Create Test Case, Delete Test Case, Rename Test Case, and Copy Test Case, so there is little need to manually manipulate it unless you want to add additional columns or update the description column to enhance the details held in it.

Note that the contents of the description column are normally the same as the contents of the brief description in the test case.

The illustration below shows an example of a typical test case summary section.

The section title can be any text. The Word style should be I_Heading_2.

DoxRunner accesses the test case summary section using bookmark V_TestCaseSummary.

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

The first two column headings are mandatory. The Brief Description is optional.

The style is I_TableHeading. Do not change the text of these three column headings.

More columns can be manually added if necessary.

Each data row represents a summary of a test case.

the style is I_TableText.

The contents of the Test Case ID column is a link to the top of the full test case.

The contents of the Test Case Name column is, you guessed it - the test case name.

The Brief Description text is expected to be the same as the text in the Brief Description section of the full test case.

The table caption is optional.

Bookmark V_TestCases is placed at the heading that begins the test case documentation.

The style is I_Heading_1.

Glossary of Terms

This section is optional and is not managed by DoxRunner.

When the solution document is downloaded from the DoxRunner site, the Glossary contains performance testing terms only. You are encouraged to add terms that are appropriate to your organisation and that are applicable to the performance testing of your solution.

Why not call it Acronyms?

Many performance testers incorrectly call this section Acronyms.

An acronym is a sub-set of initializations - it is an initialization that spells a proper English word. For example the initialization for Mutually Assured Destruction (MAD) is an acronym because it is an initialization that spells a word (MAD), whereas VU, HTTPS, and NFR are initializations, not acronyms, because they don't spell a proper English word.

The Glossary should include initializations and performance testing terms, as well as acronyms.

Solution document managed items

The solution document contains sections that contain Managed Items. These sections complement equivalent sections in the test cases.

They are all optional and are useful if a Managed Item rule is used across multiple test cases. That is, they are used to simplify documenting those rules that span multiple test cases.

For example, if you use an additional attribute or custom parameter rule to parameterise the URL used by all test cases in a solution, that rule is best included in the appropriate solution document section, rather than duplicating it in all test cases.

If you know that you won't be using a managed item, feel free to manually delete the respective section. However, don't delete them immediately. Wait until you are sure you won't need them.

The sections containing Managed Items are listed below, each linked to a detailed explanation:

DoxRunner Configuration Items (mandatory)
Non-Functional Requirements;
Test Data:
- Text Data Files;
- LoadTest Database;
- Virtual Table Server (VTS) .
Correlation Rules:
- Correlation rules;
Other parameters:
Header rules;
SAPGUI rules.

Add a section

Delete a section

Test Cases

More details

The solution document is the default repository for all test cases. They are are summarized in the Test Case Summary section, with the full details of each embedded elsewhere in the solution document. The summary and full details are linked by bookmarks.

Bookmark V_TestCases is embedded at the beginning of the test cases so that DoxRunner can navigate reliably. Do not remove it, or change its location.

Creating a new test case uses the DoxRunner create test case operation, which manages all bookmarks associated with the new test case, as well as the link in the Test Case Summary section.

The illustration below shows how test cases fit into the solution document. Although the illustration shows Appendix F and heading text Test Cases, these are not important - the person documenting the solution can choose any text. The important component is the bookmark at the front of the test cases heading in the example below. It must be V_TestCases.

Immediately below the Test Cases title is the Test Case Summary section.

Between the Test Cases title and the Test Case Summary section can be anything you like, such as release information, as shown in th illustration below.

Finally the test cases. Each test case starts on a new page.