DoxRunner
Macquarie University Student Accommodation
Document the Solution
Overview
The Solution document is semi-structured, designed with two purposes:
1. to document all aspects of a solution from a performance test point of view;
2. to document Test Cases;
3. to act as a base for DoxRunner's Test Case and Script operations.
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.
​
It should contain any tips and tricks that may be relevant to future performance testers, plus all Test Cases relevant to the solution. The Test Cases embedded in it are also semi-structured.
To make full use of it, download the version from this www.doxrunner.com site and tailor it for your organisation and solution. Refer to the page titled Review the Solution Document for guidelines on how to tailor it.
The structured components of the document are:
-
Test cases;
-
Sections;
-
Bookmarks;
-
Word styles.
The person documenting the solution has a lot of freedom in how it is documented. The restrictions required to use the Test Case and Script operations are designed to be minimal.
​
Sections
​
The Test Cases embedded in the document contain sections relevant for parameters and other scripting artifacts, but there are also sections in the Solution document that are external to those in the test cases and are also relevant for parameters and other scripting artifacts.
Refer to the page titled Solution Document Sections for more details on each section.
​
Content
​
The paragraphs below provide an overview of the sections within the Solution document, then an overview of how the Test Cases fit into it.
​
Sections
​
All Microsoft Word documents are divided into sections. DoxRunner also uses the concept of sections, but there is a difference between Microsoft Word sections and DoxRunner sections. Refer to the page that describes this difference.
Solution document content is divided into managed sections and unmanaged sections. Each managed section consists of a Title, Body Text, a Bookmark, and, optionally, a Table. Any unmanaged sections can be added manually if required.
​
The Solution document also contains Test Cases, the content of which is also divided into managed sections by default, each consisting of a Title, Body Text, a bookmark, and, optionally, a Table. Unmanaged sections can be added manually if required.
​
The managed sections in the Solution document that are not within a Test Case can be categorized into two types:
1. Those that overlap and complement the sections in the Test Cases;
-
These are listed under Other Sections below;
2. Those that apply to the Solution document only, or are highly relevant to it;
-
These three are described separately in the paragraphs below.
​
If a 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.
​
Unmanaged sections can be added if they add value, but the DoxRunner Test Case and Script operations will ignore them.
If a managed section is relevant, or you are not sure, don't delete it, but review its title and body text and update if necessary, making sure its referencing bookmark remains in place. It helps to make bookmarks visible.
​
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 the section using bookmark V_TestCaseSummary.
​
The section 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 two DocRunner operations: Create Test Case and Delete 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.
​
Configuration section
The Configuration section is critical to the successful execution of all DoxRunner Test Case and Script operations.
​
You must review all Configuration Items (CIs) in the section and update them as appropriate.
​
Navigate to the section using bookmark V_Configuration.
​
Tip: Don't delete any CIs until you are sure you won't need them.
Other sections
The Solution document contains sections that complement equivalent sections in the Test Cases.
​
They are all optional and are useful if a 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 section listed below, rather than duplicating it in all test cases.
​
-
Test Data:
-
Correlation Rules:
-
Other parameters:
- SAPGUI​ rules.
​
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 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.
Avoid calling this section Acronyms because the table in this section should include initializations, performance testing terms, as well as acronyms.
​
Test Cases
​
Test cases 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.
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.
​
Structure
​
Bookmarks
Bookmarks are essential to DoxRunner Test Case and Script operations. Unless they are faulty or you are deleting an optional section, there is no need to change them. If appropriate, feel free to add more for internal document linking once you have finished tailoring the document.
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 Configuration section - do not delete;
-
V_PerformanceSolutionDocument - Critical - 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. That are useful where a parameter exists across multiple test cases. That is, they contain rules that are common across multiple test cases. They are all optional:
-
V_AdditionalAttributes - Optional - points to the Additional Attributes section if it exists;
-
V_BoundaryCorrelation - Optional - points to the Boundary Correlation Rules section if it exists;
-
V_Custom - Optional - points to the Custom Parameters section if it exists;
-
V_DateTime - 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_RandomNumber - 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.
​
Verify the bookmarks by pressing the Insert tab on the Microsoft Word ribbon and then the Bookmark link. 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 then be found there.
Unselect hidden bookmarks.
​
There are two classes of bookmarks - refer to the two images below.
- those specific to the Solution document
- those specific to a test case
​
Verify the targets of the bookmarks by selecting each and pressing the Go To button.
​
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. They are used by DoxRunner.
​​
The styles used in the Solution document are listed here. They are the same as those in the Test Case and the Test Case Template.
-
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, but do not delete them or chage their names.
​
Title page
Most organizations use a title page. The one that comes with the DoxRunner Solution document is a good starting point.
​
You are advised to review it and tailor it to your needs.
​
A link to the Test Case Summary section appears near the bottom of the title page. It is very handy when navigating to the test cases.
​
Organisation DoxRunner and solution Cane View are used in the example.
Page headers
​
The page header appears at the top of every page after the title page. To access it, double-click it.
It 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 processes ignore it.
You can organize 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 it 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.
Page footers
If you've saved the Solution document to a different document name, then it's useful to update the page footer.
​
It also 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.
​
