DevTest User Guide - TechExcelhelp.techexcel.com/knowledgewise/DocInfo.aspx?wtqxqxwoxq.pdf ·...

DevTest User Guide

DevTest User Guide

Chapter 1 DevTest Concepts

1 DevTest Concepts 1.1 Understanding DevTest Test Management 1.2 Understanding Test Management 1.3 Knowledge Management

1.3.1 Managing Project Knowledge 1.3.2 Leveraging Control Documents 1.3.3 Facilitating Task-level Communication

1.4 Test Planning and Organization 1.4.1 Test Case Organization 1.4.2 Test Case Definition and Standardization 1.4.3 Test Templates and Test Tasks

1.5 Scheduling and Assigning Testing 1.5.1 Planning Test Cycles

1.6 Running Tests and Tracking Results 1.6.1 Submitting Bug Reports 1.6.2 Linking Test Cases to Bug Reports 1.6.3 Researching Existing Bug Reports 1.6.4 Sharing Experiences and Information 1.6.5 Conclusion

Chapter 2 Managing DevTest Basics

2 Managing DevTest Basics 2.1 Accessing and Logging into the DevTest Clients

2.1.1 Logging Into the DevTest Windows Client 2.1.2 Logging into Another Project 2.1.3 Switching Projects 2.1.4 Switching Between DevTest Views 2.1.5 Saving Records 2.1.6 Refreshing the DevTest Windows Client 2.1.7 Reloading Record Information 2.1.8 Reloading Project Settings 2.1.9 Using Shortcut Menus 2.1.10 Using Keyboard Shortcuts

2.2 Managing List Panels 2.2.1 Understanding List Panel Filtering 2.2.2 Understanding Tree Panel Filtering 2.2.3 User List Dropdown List Filtering 2.2.4 Status Dropdown List Filtering 2.2.5 Selecting Multiple Records 2.2.6 Template Tree Panel Filtering 2.2.7 Sorting Records in List Panels 2.2.8 Sorting List Panels by Multiple Columns 2.2.9 Refreshing List Panels 2.2.10 Going To DevTest Records 2.2.11 Using the Record Bar 2.2.12 Understanding List Panel Customization

2.3 Managing Tree Panels 2.3.1 Displaying Archived Folders and Pages 2.3.2 Displaying All Descendent Records 2.3.3 Displaying the Template Tree Panel

2.4 Managing Team Communication 2.5 Using the PowerPad Text Editor

2.5.1 Defining PowerPad Page Properties 2.5.2 Creating Power Pad Files 2.5.3 Formatting PowerPad 2.5.4 Creating PowerPad Screen Captures 2.5.5 Embedding and Linking Objects in PowerPad Files

Chapter 3 Knowledge Management

3 Knowledge Management 3.1 Understanding DevTest Knowledge Management 3.2 Managing Knowledge Folders

3.2.1 Managing Knowledge Folders 3.2.2 Defining Knowledge Folder Build and Read Access Controls 3.2.3 Moving Folders

3.3 Managing Knowledge Items 3.3.1 Managing Document Knowledge Items 3.3.2 Managing HTML Link Knowledge Items 3.3.3 Managing Topic Knowledge Items

3.4 Managing Document and Attachment Versions 3.4.1 Checking Out and Checking In Document Knowledge Items 3.4.2 Checking Out and Checking In Document Knowledge Items

3.4.2.1 Opening File Attachments 3.4.2.2 Locking and Unlocking Documents 3.4.2.3 Locking and Unlocking Attachments

3.4.3 Tracking Knowledge Item History 3.5 Managing Knowledge Item Linking

Chapter 4 Test Template Management

4 Test Template Management 4.1 Managing Test Template Projects

4.1.1 Understanding Test Templates 4.1.2 Understanding the Test Template View Work Area 4.1.3 Understanding Template View Privileges 4.1.4 Understanding Test Template Access Controls

4.2 Managing Test Template Basics 4.2.1 Filtering Test Templates by Test Template Folder 4.2.2 Filtering Test Templates by Status 4.2.3 Filtering by Test Template Owner, Account Type, or Team Folder 4.2.4 Navigating the Test List Panel 4.2.5 Selecting Multiple Test Templates in the Test Template List Panel

4.3 Understanding Template Project Workflow 4.3.1 Understanding Template Project Workflow Rules

4.4 Managing Test Template Folders 4.4.1 Creating Template Folders 4.4.2 Editing Template Folders 4.4.3 Understanding Template Folder Properties 4.4.4 Defining Applicable Projects 4.4.5 Granting Write Access Privileges 4.4.6 Viewing Template Folder Changes 4.4.7 Managing Template Folder Notes 4.4.8 Viewing Template Folder Time Tracking Estimates 4.4.9 Deleting Template Folders 4.4.10 Dragging and Dropping Template Folders 4.4.11 Copying and Pasting Template Folders 4.4.12 Ordering Subfolders 4.4.13 Defining Template Order 4.4.14 Viewing Archived Template Folders

4.5 Managing Test Templates 4.5.1 Creating Test Templates

Chapter 5 Verification Point Manager

5 Verification Point Manager 5.1 Understanding Verification Points

5.1.1 Understanding Expected Results and Verification Points 5.1.2 Understanding VP Status Dependency Rules

5.2 Managing Expected Results 5.3 Managing Fixed Verification Points

5.3.1 Manually Adding Fixed Verification Points 5.3.2 Manually Editing Fixed Verification Points 5.3.3 Importing and Exporting Fixed Verification Points 5.3.4 Defining Applicable VP Statuses

5.4 Managing Dynamic Verification Points 5.4.1 Understanding Dynamic Verification Points 5.4.2 Creating Dynamic Verification Point Variables 5.4.3 Managing Dynamic Verification Point Variable Types 5.4.4 Manually Creating Dynamic Verification Point Values 5.4.5 Importing and Exporting Dynamic Verification Point Values 5.4.6 Managing Dynamic VP Variables in Test Templates 5.4.7 Managing Verification Point Statuses 5.4.8 Defining Dynamic VP Permutation Rules 5.4.9 Weighing Verification Point Permutations (Verification Points)

5.5 Managing the Verification Point Matrix 5.5.1 Understanding the VP Matrix 5.5.2 Defining Verification Point Matrix Controls in Test Templates

Chapter 6 Test Planning Management

6 Test Planning Management 6.1 Understanding Test Planning Management

6.1.1 Understanding Planning Wizards 6.1.2 Understanding Planning View Privileges

6.2 Managing Test Planning Structures 6.2.1 Creating Product Folders 6.2.2 Understanding Release Cycle Folders 6.2.3 Archiving Release Cycle Folders 6.2.4 Editing Test Cycle General Folder Properties

6.3 Managing Release Cycles 6.3.1 Creating and Defining Release Folders 6.3.2 Defining Applicable DevTrack Projects 6.3.3 Defining Applicable Release Cycle Teams Members 6.3.4 Defining Applicable Environmental Variables 6.3.5 Defining Applicable Environmental Variable Permutations 6.3.6 Defining Applicable Test Templates 6.3.7 Confirming Release Coverage 6.3.8 Overriding Test Coverage Settings 6.3.9 Defining Release Cycle Testing Objectives

6.4 Managing Test Cycles 6.4.1 Creating and Defining Test Cycle Folders 6.4.2 Defining General Test Cycle Properties 6.4.3 Selecting the Test Cycle Team Members 6.4.4 Selecting Environmental Variable Permutations 6.4.5 Selecting Test Templates 6.4.6 Updating Test Cycle Test Coverage 6.4.7 Overriding Test Cycle Properties 6.4.8 Regenerating Deleted Test Tasks 6.4.9 Editing Test Cycle Folder Properties 6.4.10 Updating Test Cycle Team Member Assignment 6.4.11 Editing Environmental Variable Permutations

6.5 Managing Summary Reports

Chapter 7 Test Task Management

7 Test Task Management 7.1 Understanding DevTest Test Management

7.1.1 Understanding the Test Task View Work Area 7.1.2 Understanding Test Task View Privileges 7.1.3 Understanding Test Tasks Access Controls

7.2 Managing Test Task Basics 7.2.1 Filtering Test Tasks by Test Task Folder 7.2.2 Displaying the Test Template Panel in the Test Task View 7.2.3 Filtering Test Tasks by Test Template Folder 7.2.4 Filtering Test Tasks by Status 7.2.5 Filtering by Test Task Owner, Account Type, or Team Folder 7.2.6 Navigating the Test List Panel 7.2.7 Selecting Multiple Test Tasks in the Test Task List Panel

7.3 Managing Test Tasks 7.3.1 Understanding Test Task Workflow 7.3.2 Editing Test Tasks 7.3.3 Understanding Workflow Field Restrictions 7.3.4 Understanding Defect Submission Triggers 7.3.5 Managing Test Task Group Actions 7.3.6 Forwarding Test Tasks 7.3.7 Adding Notes and Note Attachments to Test Tasks 7.3.8 Viewing Test Task History

Chapter 8 Product Defect Management

8 Product Defect Management 8.1 Managing Product Defects

8.1.1 Understanding Product Defect Management 8.1.1.1 DevTest-DevTrack Integration 8.1.1.2 Product Defect Submission

8.1.2 Submitting Product Defects to DevTrack 8.1.3 Associating Test Tasks with Linked DevTrack Product Defects 8.1.4 Searching for DevTrack Product Defect Issues 8.1.5 Managing Linked DevTrack Product Defect Issues

8.2 Managing Defect Submission Preferences 8.2.1 Defining Defect Submission Settings 8.2.2 Prepopulating New Defect Page Fields 8.2.3 Enabling Defect Template Selection

8.3 Managing the DevTrack View 8.3.1 Understanding DevTrack View Privileges 8.3.2 Submitting Product Defect Issues in the DevTrack View 8.3.3 Forwarding DevTrack Product Defects 8.3.4 Closing DevTrack Product Defects 8.3.5 Reopening DevTrack Product Defects 8.3.6 Editing DevTrack Product Defects

Chapter 9 Search And Query Management

9 Search And Query Management 9.1 Understanding DevTest Searches and Queries

9.1.1 Understanding Test Template Conditions 9.1.2 Understanding Test Task Conditions 9.1.3 Understanding the Search Manager

9.2 Managing Search Conditions 9.2.1 Test task properties 9.2.2 Test template properties 9.2.3 Defining Field Text Search Conditions 9.2.4 Logical operators 9.2.5 Defining Field Value Search Conditions 9.2.6 Defining Date and Time Search Conditions 9.2.7 Defining Keyword Search Conditions

9.3 Managing DevTest Search Logic 9.3.1 Logical operators

9.4 Managing Saved Queries 9.4.1 Running Queries 9.4.2 Saving Queries Based On Ad-Hoc Searches 9.4.3 Saving Queries Based on Existing Queries 9.4.4 Editing Queries 9.4.5 Deleting Queries

Chapter 10 Managing DevTest Personalization

10 Managing DevTest Personalization 10.1 Understanding Client Personalization 10.2 Managing Default Settings

10.2.1 Defining Default User List Options 10.2.2 Defining Default Status List Options 10.2.3 Defining Default Query List Options 10.2.4 Defining Archived Files Options 10.2.5 Defining Default Template Tree Options 10.2.6 Defining Default Template Descendents Options 10.2.7 Defining Default Folders Options 10.2.8 Defining Default Projects

10.3 Managing Date and Time Settings Preferences 10.3.1 Personalizing List Panel Columns 10.3.2 Reinstating Default List Panel Settings 10.3.3 Defining Records Per Page Settings 10.3.4 Personalizing the User List

10.4 Personalizing the History Report 10.4.1 Ordering History Report Columns 10.4.2 Reinstating Default History Report Settings

3 Knowledge Management

In this chapter:

Understanding DevTest Knowledge Management Managing Knowledge Folders Managing Knowledge Items Managing Document and Attachment Versions Managing Knowledge Item Linking

3.1 Understanding DevTest Knowledge Management In DevTest, all control knowledge items, business knowledge items, functional specifications, technical specifications, database schemas, and GUI design knowledge items are stored and managed in an integrated DevTest knowledge base. The DevTest knowledge base provides development organizations with a secure repository for all project control documents, facilitates collaboration between distributed development teams, and enables development organizations to enforce change management, security, and transparency to all project deliverables. A knowledge item may be a word processing document, a spreadsheet, a graphic, a link to a web page, a knowledge topic, or any other discreet piece of information that is managed separately in the knowledge base.

Document:A document is any file that is saved in the knowledge base and includes all of the files generated during the planning process: customer requirements, functional specifications, technical specifications, database schemas, GUI designs, and so on. Documents may be in any file format: word processing documents, spreadsheets, image files, scripts. HTML Link:An HTML link is a URL to a web page. HTML links enable development organizations to create a library of project-related web sites and provide project members with easy access to reference information. Topic:A knowledge topic is a database record stored in the knowledge base. Businesses may use topics to define and manage a library of resolutions to common problems.Each topic consists of a description page, a resolution page, and a links page. Topics enable developers to save the time needed to resolve common development issues. Attachment:An attachment is a file that has been linked to a development issue note in a DevTrack project. All attachments are stored in the Attachments root folder within the knowledge base.

3.2 Managing Knowledge Folders Knowledge folder management is the task of defining the structures that organize knowledge items in the knowledge base. All DevTest knowledge items are stored and managed in the knowledge folders that comprise the knowledge tree. The knowledge tree is a hierarchical structure composed of multiple folders and subfolders that organize knowledge items into distinct areas of work. The knowledge tree structure is displayed in the knowledge tree panel of the knowledge view.

Figure 3-1: Knowledge Tree Structure The knowledge tree panel organizes knowledge items into a hierarchical structure of folders and subfolders. At each level of the structure, access to knowledge items and knowledge folders are controlled by a knowledge folder type. The knowledge tree consists of two root folders: the knowledge root folder and the attachment root folder.The root knowledge items folder is the parent of every other folder in the hierarchy and cannot be deleted.

Knowledge Folders:A knowledge folder organizes the knowledge items (documents, HTML links, and topics) stored in the project knowledge base. Every knowledge folder is defined as a public or private folder and controlled by build and read access rights. Attachment Folders:An attachment folder organizes the documents that are attached to test tasks and test templates. The root attachment folder contains two subfolders: the template attachment folder and the test task attachment folder.

Every folder in the knowledge tree is defined by its relationship with the folders immediately above it (its parent) and below it (its child) in the hierarchy. A child folder may inherit all folder -level security settings from its parent folder. Project members with the appropriate privileges may create any number of nested knowledge folders and attachment folders to any level of depth. The knowledge tree bar displays control buttons that enable the user to manage the folders displayed in the knowledge tree.

3.2.1 Managing Knowledge Folders In DevTest, a knowledge folder is a folder that organizes and provides security for the the knowledge items (documents, HTML links, and topics) stored in the project knowledge base. The knowledge tree panel organizes knowledge items into a hierarchical structure of folders and subfolders. At each level of the structure, access to knowledge items and knowledge folders are controlled by a knowledge folder type. Every knowledge folder is defined by its type (public folder or protected folder), read access controls, and build access controls.

Public Folder:A public folder represents the least restrictive level of access. A knowledge folder type is an administrator-defined set of account type-based access rights that define which project members may create, edit, or delete knowledge item subfolders Protected Folder:A protected folder represents the more restrictive level of access. A knowledge folder type is an administrator-defined set of account type-based access rights that define which project members may create, edit, or delete knowledge item subfolders.

Every folder in the knowledge tree is defined by its relationship with the folders immediately above it (its parent) and below it(its child) in the hierarchy. A child folder may inherit all folder -level security settings from its parent folder. Folder-level Security The folder type (public or protected), build access rights, and read access rights may be defined on a folder-by-folder basis or child knowledge folders may inherit rules from their parent folder. Using controls in the Add Knowledge Folder window, project members may define knowledge folder properties and access controls. Read Access Build Access To add a knowledge folder:

1. Select a knowledge folder in the knowledge tree panel. The selected knowledge folder is the parent of the new knowledge folder.

2. Click the New Folder button in the knowledge tree bar. The Add Knowledge Folder window appears. The Add Knowledge Folder window may display one or more forms including the Folder Description page, the Read Access page, and the Build Access page.

3. Define knowledge folder properties in the Folder Description page. 4. Define the knowledge folder type in the Folder Type area of the Description tab.

To define the folder as a public folder, select the Public Folder option button. To define the folder as a protected folder, select the Public Folder option button.

5. Define folder-level build access rights in the Build Access tab. Build access rights determine which project team members may add knowledge items to that folder based on account type.

6. Define folder-level read access rights in the Build Access tab. Read access rights determine which project team members may view knowledge items to that folder based on account type.

7. Click the OK button. The knowledge folder is added to the knowledge tree as the child of the selected knowledge folder.

To delete a knowledge folder: 1. Select a knowledge folder in the knowledge tree panel. 2. Click the Delete Folder button in the knowledge tree bar. A confirmation dialog box appears.

Note:Folders that contain knowledge items cannot be deleted. To delete a folder that contains items, delete all items in that folder.

3. Click the Yes button.

3.2.2 Defining Knowledge Folder Build and Read Access Controls In DevTest, knowledge folder access controls determine which project members may add, edit, and delete knowledge items in the knowledge tree panel. The Access Control tab enables the user to define folder access controls and knowledge item access controls for each knowledge folder. The knowledge tree panel organizes knowledge items into a hierarchical structure of folders and subfolders. At each level of the structure, access to knowledge items and knowledge folders are controlled by a knowledge folder type. A knowledge folder type is an administrator-defined set of account type-based access rights. The folder types define which project members may create, edit, or delete knowledge item subfolders. A knowledge folder may be defined as a public folder or protected folder.

Public Folder:A public folder represents the least restrictive level of access. A knowledge folder type is an administrator-defined set of account type-based access rights that define which project members may create, edit, or delete knowledge item subfolders. Protected Folder:A protected folder represents the more restrictive level of access. A knowledge folder type is an -defined set of account type-based access rights that define which project members may create, edit, or delete knowledge item subfolders. Change managers may define knowledge item access rights whenever they create or edit a knowledge folder.

To define knowledge folder build access rights: 1. Select a knowledge folder in the knowledge tree panel. 2. Select the Properties button in the knowledge tree bar. The Edit Knowledge Folder window appears. 3. Select the Build Access tab. 4. Define the folder type of the knowledge folder.

A knowledge folder may be a public folder, a protected folder, or a secured folder: To apply build access across projects, select the All option button. To define build access project-by-project, select the Selected option button and select one or more projects in the projects list.

5. Click the OK button. To define knowledge folder read access rights:

1. Select a knowledge folder in the knowledge tree panel. 2. Select the Properties button in the knowledge tree bar.

The Edit Knowledge Folder window appears. 3. Select the Read Access tab. 4. Define the folder type of the knowledge folder.

A knowledge folder may be a public folder, a protected folder, or a secured folder: To apply read access across projects, select the All option button. To define read access project-by-project, select the Selected option button and select one or more projects in the projects list.

5. Click the OK button.

3.2.3 Moving Folders To move folders:

1. Select a knowledge folder in the knowledge tree panel. 2. Click the Move button in the knowledge tree bar.

The Move Knowledge Folder window appears. 3. Select a target folder in the Move Knowledge Folder tree. 4. Click the OK button.

5. Optional: To view changes, click the Refresh button.

3.3 Managing Knowledge Items A knowledge item is any file that is saved in the knowledge base and includes all of the files generated during the planning process: customer knowledge items, functional specifications,

technical specifications, database schemas, GUI designs, and so on.

Knowledge Items may be in any file format: word processing knowledge items, spreadsheets, image files, scripts. Knowledge items fall into four categories: documents, HTML links,

topics, and attachments.

Document:A document is any file that is saved in the knowledge base and includes all of the files generated during the planning process: customer requirements, functional

specifications, technical specifications, database schemas, GUI designs, and so on. Documents may be in any file format: word processing documents, spreadsheets, image files,

scripts.

HTML Link:An HTML link is a URL to a web page. HTML links enable development organizations to create a library of project-related web sites and provide project members with easy

access to reference information.

Topic:A knowledge topic is a database record stored in the knowledge base. Businesses may use topics to define and manage a library of resolutions to common problems. Each

topic consists of a description page, a resolution page, and a links page. Topics enable developers to save the time needed to resolve common development issues.

Every knowledge item is defined by a unique ID number, description, workflow state, owner, and other dynamic properties. Basic knowledge item properties may be managed and tracked

in one or more custom pages in the DevTest client.

The knowledge list bar displays control buttons that enable the user to manage the knowledge items displayed in the knowledge list.

3.3.1 Managing Document Knowledge Items In DevTest, a document knowledge item is any file (word processing file, worksheet, or image file) that is saved in the DevTest database and managed using tools in the knowledge view. A document is any file that is saved in the knowledge base and includes all of the files generated during the planning process: customer requirements, functional specifications, technical specifications, database schemas, GUI designs, and so on. Documents may be in any file format: word processing documents, spreadsheets, image files, scripts. Using controls in the knowledge list bar, project team members may submit and manage document knowledge items in the knowledge view. To submit a document knowledge item:

1. Select a knowledge folder in the knowledge tree panel. 2. Click the New Document button in the knowledge list bar.

The New Document window appears. 3. Define knowledge item properties in the Description page. 4.Optional: Attach a file or HTML path to the knowledge item file attachments in the Description tab.

Control managers may manage knowledge item attachments in the Description page whenever they create a knowledge item. 5. Click the OK button.

The New Knowledge Item window closes. The document knowledge item is displayed in the knowledge item list panel. To edit a document knowledge item:

1. Select a knowledge in the knowledge list panel. 2. Click the Edit button in the knowledge list bar.

The Edit Knowledge Item manager appears. The Edit Knowledge Item managers is a multiple-page form that may display all custom pages and the History, Versions, Linked Knowledge, All Links, and Events system pages.

3.Optional:Update knowledge item properties in the Description page. 4.Optional:Add, remove, delete, check out, or lock knowledge item file attachments in the Description tab. 5. Click the OK button.

The New Knowledge Item window closes. The document knowledge item is displayed in the knowledge item list panel. To delete a knowledge item:

1. Select a knowledge in the knowledge list panel. 2. Click the Delete button in the knowledge list bar.

The confirmation dialog box appears. 3. Click the Yes button.

The knowledge item is deleted.

3.3.2 Managing HTML Link Knowledge Items An HTML link is a URL to a web page. HTML links enable development organizations to create a library of project-related web sites and provide project members with easy access to reference information. Using controls in the knowledge list bar, project team members may submit and manage document knowledge items in the knowledge view. To submit an HTML link knowledge item:


The New Document window appears. 3. Define knowledge item properties in the Description page. 4.Optional:Attach a file or HTML path to the knowledge item file attachments in the Description tab.


The New Knowledge Item window closes. The document knowledge item is displayed in the knowledge item list panel. To edit an HTML link knowledge item:




The New Knowledge Item window closes. The document knowledge item is displayed in the knowledge item list panel. To delete an HTML link knowledge item:

1. Select a knowledge in the knowledge list panel. 2. Click the Delete button in the knowledge list bar.

The confirmation dialog box appears. 3. Click the Yes button.

3.3.3 Managing Topic Knowledge Items A knowledge topic is a database record stored in the knowledge base. Businesses may use topics to define and manage a library of resolutions to common problems. Each topic consists of a description page, a resolution page, and a links page. Topics enable developers to save the time needed to resolve common development issues. Using controls in the knowledge list bar, project team members may submit and manage document knowledge items in the knowledge view To submit a topic knowledge item:


The New Document window appears. 3. Define knowledge item properties in the Description page. 4.Optional:Attach a file or HTML path to the knowledge item file attachments in the Description tab.


The New Knowledge Item window closes. The document knowledge item is displayed in the knowledge item list panel To edit a topic knowledge item:




The New Knowledge Item window closes. The document knowledge item is displayed in the knowledge item list panel.. To delete a topic knowledge item:

1. Select a knowledge in the knowledge list panel. 2. Click the Delete button in the knowledge list bar. The confirmation dialog box appears. 3. Click the Yes button.

Moving Knowledge Items To move a knowledge item:

1. Select a knowledge item in the knowledge list panel. 2. Select the Move button in the knowledge list bar.

The Move Knowledge Item dialog box appears. 3. Select a knowledge folder in the Knowledge Folder tree.

The Knowledge Folder tree in the Move Knowledge Item dialog box displays the hierarchical folder structure used to organize knowledge items in the project. 4. Click the OK button.

The knowledge item is moved to the selected knowledge folder.

3.4 Managing Document and Attachment Versions DevTest features built-in version control system that provides distributed development teams with access to the most up-to-date control documents and enables project managersand stakeholders to protect and control multiple versions of control documents. The knowledge base enables developers to manage common and local copies of project control documents. To make changes to a document, a project manager must check outthe server version to their local machine, make the desired changes, and check the document back into the knowledge base. DevTest provides development organizations with three methods for managing and controlling project documentation.

Thecheck out-check in methodenables project stakeholders to check out the documents stored in the knowledge base (server versions), store and modify copies of those documents (local versions) on their local machines, and check in the modified documents to the knowledge base. Checking in a document propagates the changes made to the local version and makes that document available to all developers.

Thelock-unlock methodenables project stakeholders to lock and unlock server versions of documents. Locked documents may not be checked out by other project members.

DevTest features built-in version control that employs alock-modify-unlock modelto manage different versions of documents.

Figure 3-2: Common Knowledge Base for DevPlan, DevTrack, and DevTest

3.4.1 Checking Out and Checking In Document Knowledge Items The DevTest knowledge base uses acheck out-modify-check inmodel to control access to documents and manage document versioning. Checking out a file enables the project member to make changes to the document stored in the DevTest database. A lock is automatically placed on the file as long as the file is checked out. A locked file cannot be checked out by another project member and therefore cannot be updated. Checking in a file releases the lock on the file. Any changes made to the file while it was checked out are saved in the DevTest database. Once a file is checked back into DevTest project members may once again check out and make changes to the file. Checking out a file (the server version) enables project stakeholders to create a local copy of that file (the local version) on their local machine and places a lock on the server version of that file in the knowledge base.

Figure 3-3: Check Out-Modify-Check In Work Cycle Model To check out document knowledge items:

1. Select a document knowledge item in the list panel. 2. Click the Check Out/Check In button in the knowledge list bar.

The Check Out dialog box appears. 3. Select a version of the document to be checked out. 4. Click the OK button.

To check in document knowledge items: 1. Select a document knowledge item in the list panel. 2. Click the Check Out/Check In button in the knowledge list bar.

The Check In dialog box appears. 3. Click the OK button.

3.4.2 Checking Out and Checking In Document Knowledge Items In DevTest, an attachment is a file that is ?ttached?to test task or test template enabling project team members to communicate information that isspecificto that work item. All attachments are stored in the project knowledge base. Using controls in the list panel, project team members may check out and modify and check in files that are attached to test templates and test tasks. A lock is automatically placed on the file while it is checked out. Locked files cannot be checked out by other project members in the Notes page or in the Attachments folder in the knowledge view. To check out an attachment:

1. Select an attachment in the list panel. 2. Click the Check Out/Check In button in the knowledge list bar.

The Check Out dialog box appears. 3. Select a version of the document to be checked out. 4. Click the OK button.

To check in an attachment: 1. Select a document knowledge item in the list panel. 2. Click the Check Out/Check In button in the knowledge list bar.

The Check In dialog box appears.

3.4.2.1 Opening File Attachments

To open an attachment:

1. Select a note in the Notes List area of the Notes page.

2. Select a note attachment in the Attachment list.

3. Click the Open button.

The Open File dialog box appears.

4. To get the latest version of the attachment select the Get the Latest Version of this File from the Document Server check box.

5. To open the attachment select the Open this File Now check box.


3.4.2.2 Locking and Unlocking Documents

To lock a document knowledge item:

1. Select a document knowledge item in the list panel.

2. Click the Lock/Unlock button in the knowledge list bar.

The Lock dialog box appears.


To unlock a document knowledge item:

1. Select a document knowledge item in the list panel.


The Unlock dialog box appears.


3.4.2.3 Locking and Unlocking Attachments

In DevTest, an attachment is a file that is ?ttached?to test task or test template enabling project team members to communicate information that isspecificto that work item.

All attachments are stored in the project knowledge base. Using controls in the list panel, project team members may place locks on the files that are attached to test templates

and test tasks.

Locked files cannot be checked out by other project members in the Notes page or in the Attachments folder in the knowledge view.

To lock an attachment:

1. Select an attachment in the list panel.


The Lock dialog box appears.


To unlock an attachment:

1. Select an attachment in the list panel.


The Unlock dialog box appears.


3.4.3 Tracking Knowledge Item History Using controls in the History page, project team members may view the history of changes made to documents managed in the knowledge view. The History page displays the complete history of changes made to the file in the knowledge, template, and test task views. Every time a knowledge item is created or checked into the DevTest knowledge view, the History page logs the changes made to the document. The History page is divided into two areas: the History list and the Notes area:

History:The History list displays each change to the document in a tabular format. Each row represents a version of the knowledge item (document, topic, HTML link, or attachment) that was checked into the DevTest system. For each version of a knowledge item, the History list shows the version number, the user name of the person who made the change, the time the change was made, and the action taken. Notes:The Notes area displays any notes made by a project members when he or she makes changes to a document.

The History page appears in the knowledge detail panel for documents and attachments.

3.5 Managing Knowledge Item Linking Project members may use the Related Knowledge page to link documents, HTML links, and topics to multiple related knowledge items. The Related Knowledge Selection manager enables project members identify and link multiple knowledge items (documents, HTML links, and other topics) to a document, HTML link, or topic.

Figure 3-4: Related Knowledge Selection Manager The Related Knowledge Selection manager consists of two tabs.

The Explore tab enables project members to find knowledge items stored in folders in the knowledge tree panel. The Search tab enables project members to search for files stored in the DevTest knowledge base using keyword searches.

The Related Knowledge Selection manager may not be used to attach documents, topics, or HTML links that are not already managed in the knowledge view. Project members may not use the Related Knowledge Selection manager to link new files or knowledge items stored in the Attachments folder. To link to related knowledge items using the Explore tab:

1. Click the Select button in the Document Links page of the knowledge detail panel. The Related Knowledge Selection manager appears.

2. Select the Explore tab. 3. Select a project option from the Project dropdown list. 4. Locate the file and folder in the Knowledge tree menu. 5. Highlight the files that you want to attach to the note.

Chapter 4 Test Template Management

4 Test Template Management

Test Template Management

4.1 Managing Test Template Projects

Test Templates Projects are used to manage an organization's test library. A test library in DevTest is made up of Test Templates. Template project management consists of managing the activities required to develop, manage, and distribute test templates before they are used to create test tasks.

4.1.1 Understanding Test Templates Template projects enable project members to create and manage the test templates that are used to generate test tasks. Testtemplates are the blueprints for test tasks. Test templates are used tocreate a library of tests that can be assigned out and executed. Eachtest template may be used to create multiple test tasks which inherittest template properties. Each test template allows users to create atest task for each test cycle they generate. When using environmentalvariables users can use DevTest to generate many different test tasksfrom a single test template in each test cycle. Template project members are responsible for managing test templates in the template tree panel and for defining the properties of each test template: test template properties environmental variables verification points Test template properties are the properties that define a test template and which drive template base project workflow rules. Test template properties may be defined in the Template Description page in the Submission pages, Editing pages, or the template detail panel. Test template properties include the title, template state, template owner, and the test procedure. Environmental variables are system properties that a project member may define for each test template folder or test template. The environmental variables selected for each test template represent the valid environments that a child test task can be use to test. When scheduling releases and test cycles in the DevTest planning view only the test templates that match the environments selected. For the purposes for selected test coverage environment variables act as a filter for what test coverage a test planner will see. Once selected if test template is valid for more than one environment in a single test cycle DevTest will be a separate test task for each valid environment. Verification points provide test teams with a method for creating multiple items that need to be verified within a single test task. Verification points can be used when a test has multiple steps that need to be performed or for tests that require that multiple items are confirmed. Verification points can be created on an item by item basis or users can create dynamic verification point variables that can be used over and over to create new test coverage. During a test cycle testers may indicate the success or failure of application tested by two methods: If verification points are not enabled testers may indicate success or failure of the test task by changing the workflow state of the test task. This method works well if a single checkpoint is being tested. If verification points are enabled testers may measure the success or failure of an application against multiple criteria (verification points). The overall success or failure of the testtask is based on administrator-defined dependency rules.

4.1.2 Understanding the Test Template View Work Area

In DevTest, all test templates are managed and tracked in the test templates view of the DevTest client. The test template view is organized into four panels: the test template tree panel, the test template list panel, the test template detail panel, and, optionally, the test template tree panel.

Figure 4-1: Test Template View DevTest panels enable project members to organize and manage test templates in the DevTest client.

Test Template Tree Panel:The test template tree panel organizes test templates into a hierarchical structure of template folders. Test Template List Panel:The test template list panel shows highlevel information about multiple test templates in a tabular format of rows and columns. Controls in the toolbar enable users to filter and sort the test templates displayed in the list panel by ownership, work status, test template status, or user-defined query. Test Template Detail Panel:The test template detail panel displays detailed information about a single test template in multiple tabbed pages.

4.1.3 Understanding Template View Privileges DevTest uses account type-based access rights and privilege controls to manage access, implement security, and coordinate project members in workflow. In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Every project member is assigned an account type when they join a project. Project member roles, responsibilities, access rights, and privileges are defined by their account type. Test template view privileges enable project members to manage test template, test template folders, folder-level and test template-level access rights, and other features in the test template view of the DevTest client. Template view privileges include:

Can Submit Template:The Can Submit Template privilege enables an account type to submit a test template. Can Edit Own Template:The Can Edit Own Template privilege enables an account type to edit test templates they have submitted. Can Edit Template Within Own Group:The Can Edit Template Within Own Group privilege enables project members to edit test templates created by other members of the same group. Can Edit All Templates:The Can Edit All Templates privilege enables an account type to edit any test template in the project. Can Edit Other Users Notes:The Can Edit Other User? Notes privilege enables project members to edit notes created by other users. Can Perform Group Change:he Can Perform Group Change privilege enables an account type to submit a test template. Can Define Public Query:The Can Define Public Query privilege enables project members to create queries in a template base project. Can Create Template Snapshot:The Can Create Template Snapshot privilege enables an account type to take a snapshot of a test template. Can Create Template Snapshot:The Can Create Template Snapshot privilege enables an account type to delete a snapshot of a test template. Can Create Template Snapshot:The Can Create Template Snapshot privilege enables an account type to rollback a test template back to a snapshot taken of that test template. Can Create Default Value Template:The Can Create Default Value Template privilege enables an account type to create a default value template. Can Create Template Folder:The Can Create Template Folder privilege enables an account type to create template folders in the Template tree menu. Can Edit Template Folder:The Can Edit Template Folder privilege enables an account type to edit test template folder properties. Can Delete/Move Template Folder:The Can Delete/Move Template Folder privilege enables an account type to delete or move test templates. Can Import Template:The Can Import Template (Including Template Folder) privilege enables an account type to import test templates and template folders from another project. Can Delete Template:The Can Delete Template privilege enables an account type to delete test templates. Can Define Template Folder Write Access Control:The Can Define Template Folder Write Access Control privilege enables an account type to define write access controls for a template folder.

Can Access User Preference:The Can Access User Preference privilege allows the account type to access the User Preference option under System (for the Windows Client) and Settings (for the Web Client).

Can Push User Preference Settings to Other User:The Can Push User Preference Settings to Other User allows the account type to push out their User Preference settings from the Client (via the Push button under the User Preference Settings) to other users.

4.1.4 Understanding Test Template Access Controls

Work project workflow is based on workflow rules defined by a project administrator in DevTest Admin. Workflow rules determine the sequence of workflow states that a test template may go through during a test creation and the updates that project members may make to a test template during a particular workflow state. The template state of test template drive template project workflow rules. Template project workflow rules are based on the templates states of test templates. Workflow rules may determine which project members may own a test template based on its template state, what changes may be made to test template properties, or even which fields are visible in the test template itself.

Administrators may restrict the ownership of test template based on either the current template state or the transition state of the test template. Administrators may define workflow field restrictions based on the template state of test templates that limit the changes that may be made to test template in that

template state. Work project administrators may define up to six different rules for managing test template development:

State Transition:Rules State transition rules enable the administrator to define test task workflow. For each workflow state, the administrator may define all possible subsequent workflow states. Applicable Owner Rules:Applicable Owner rules enable the administrator to define which project members may own a test task in each workflow state. This rule may limit the range of project members to whom a test task may be forwarded based on its workflow state. Invisible Fields:Invisible Field rules enable the administrator to make certain fields invisible to all project members when the test task is in a particular workflow state. Mandatory Fields:Mandatory Field rules enable the administrator to make certain fields mandatory to all project members when the test task is in a particular workflow state. Read-Only Fields:Read-only Field rules enable the administrator to make certain fields editable to all project members when the test task is in a particular workflow state. Read-only fields cannot be updated. Who Can Change Rules:Who Can Change rules enable the administrator to define which project members may edit test task properties the test template is in a particular workflow state. Who Can Change rules may be based on the current workflow state of the test template, or they may be based on state transitions.

4.2 Managing Test Template Basics

In DevTest, a test template filter is a simple query that returns every test template that matches a set of user-defined criteria.Test templates that match the criteria are displayed in the list panel while those that do not match are filtered out and are not shown. Test template filters are the fastest way to view subsets of test templates based on test template properties: the test template owner, status, or status group.

Team List:The Team List enables project members to view a subset of test templates based on the current owner. Test templates may be filtered by user account, account type, or team folder. Status List:The Status List enables project members to view a subset of test templates based on the work status (open or closed), test template status, or status group. Query List:The Query List enables project members to view a subset of test templates based on a predefined query

4.2.1 Filtering Test Templates by Test Template Folder The test template tree panel organizes test templates into a hierarchical structure of folders and subfolders. Every folder in the test template tree structure defines the environmental variables that may be added to the test templates contained in that folder and restricts access to those templates on a project-by-project basis. By selecting a test template folder in the test template panel, project members may view test templates based on the test templates contained in the folder in the test template panel. To filter test templates by test template folder:

To filter test templates by test template folder, select a test template folder in the test template tree panel. The test template list panel displays only test templates that have been generated from test templates contained in the selected test template folder.

4.2.2 Filtering Test Templates by Status In DevTest, test templates may be defined by a work status (open or closed) and a test template status (Pass, Fail, Blocked, In Progress, or Did Not Run). Using the Status List, a project member may filter the test templates displayed in the test template list panel by work status, test template status, or status group. The Status List dropdown list in the search bar displays all statuses and status groups.

Figure 4-2: Status List in Test Template View Every test template status is defined as an open or closed state.

{Open only}:The {Open only} work status displays only those test templates that are open. {Closed only}:The {Closed only} work status displays only those test templates that are closed. {Open and closed}:The {Open and closed} work status displays all open and closed test templates. {Unspecified}:The {Unspecified} work status displays test templates that have no test template status. Test Template Status:A test template may be defined by one of five test template statuses: Pass, Fail, Blocked, In Progress, or Did Not Run Status Group:A status group is an administrator-defined grouping of test template statuses.

Test template status filtering may be used in conjunction with test template folder filtering, test template folder filtering, or any other test template filter.

4.2.3 Filtering by Test Template Owner, Account Type, or Team Folder

In DevTest, every test template is at all times owned by one-and-only-one project team member or team folder. Using the Team List, a project member may filter the test templates displayed in the test template list panel based on the current owner. The Team List dropdown list in the search bar displays every project members, account types, and team folders.

Figure 4-3: Team List in Test Template View The All Members selection enables the user to view test templates owned by any project member regardless of their account type or team folder. Account types and team folders are distinguished in DevTest by asterisks and plus signs. * The asterisk designates an account type. + The plus sign designates a team folder. Test template owner filtering may be used in conjunction with test template folder filtering, test template folder filtering, or any other test template filter.

4.2.4 Navigating the Test List Panel

The test template list panel displays high-level information about multiple test templates in a of rows and intersecting columns.

Project members may quickly browse for items in the list panel use control buttons in the test template list scroll bar. The status control. displays the number of items displayed

in the list panel and the sequence number of the selected item.

Figure 4-4: Test Template Scroll Control

Using scroll bar control buttons, project members may view the first item, previous item, next item, and last item in the list.

4.2.5 Selecting Multiple Test Templates in the Test Template List Panel DevTest enables project members with the appropriate privileges to manage multiple test templates simultaneously using group actions. A group action is a test template management task that enable the user to update multiple test templates simultaneously. DevTest supports two group actions: group editing andgroup forwarding. The steps required to select multiple test templates are different in the Windows and web-based clients: To select multiple test templates in the Windows client: The DevTest Windows client provides project members with three methods of selecting multiple items in the test template list panel:

To select all test templates in the test template list panel, press CTRL + A. To select a sequential range of test templates, press the SHIFT key and select two test templates in the test template list panel. Every within the range of the starting and

ending test template is selected. To select a random range of test templates, press the CTRL key and select test templates in the test template list panel.

To select multiple test templates in the Web client: The DevTest Web client provides project members with two methods of selecting multiple items in the test template list panel:

To select all test templates select the check box in the heading row of the test template list. To select individual test templates select the check box in the corresponding rows of the test template list.

4.3 Understanding Template Project Workflow

Workflow is a business process used to manage the tasks that compose a project. Workflow rules enable project managers to define and track the flow of work between individuals and teams. A well-defined set of workflow rules enable an organization to perform tasks in an efficient and repeatable manner. In a DevTest, template project workflow rules define the life cycle of test templates. Each test template may go through several workflow states during its development life cycle. Workflow rules determine the order in which a test template goes through workflow states and how the test template is managed in the DevTest client. Each template project is

managed by a project administrator in DevTest Admin.

4.3.1 Understanding Template Project Workflow Rules Template project workflow is based on workflow rules defined by a project administrator in DevTest Admin. Workflow rules determine the sequence of workflow workflow states that a template must go through during the development life cycle and which template project members may manage test templates in each workflow workflow state. Template project administrators may define up to six different rules for managing test template development:

State transition rules:State transition rules enable the administrator to define test template workflow. For each workflow state, the administrator may define all possible subsequent workflow states. Applicable Owner rules:Applicable Owner rules enable the administrator to define which project members may own a test template in each workflow state. This rule may limit the range of project members to whom a test template may be forwarded based on its workflow state. Invisible Field rules:Invisible Field rules enable the administrator to make certain fields invisible to all project members when the test template is in a particular workflow state. Mandatory Field rules:Mandatory Field rules enable the administrator to make certain fields mandatory to all project members when the test template is in a particular workflow state. Read-only Field rules:Read-only Field rules enable the administrator to make certain fields editable to all project members when the test template is in a particular workflowstate. Read-only fields cannot be updated. Who Can Change rules:Who Can Change rules enable the administrator to define which project members may edit test template properties the test template is in a particular workflow state. Who Can Change rules may be based on the current workflow state of the test template, or they may be based on state transitions.

4.4 Managing Test Template Folders Project members may use commands in the Template Tree shortcut menu to create, edit, delete, and organize template folders in the template tree panel of the template view. User-defined template folder properties determine how DevTest manages the test template contained in that folder. Inherited template folder properties include environmental variables and applicable project settings:

Template folders determine which environmental variables may be applied to the test templates contained within them. Template folders determine which work projects may access the test templates contained within them. Only those projects designated as applicable projects by a template

folder can use the test templates contained in that folder. Template folders determine the default value templates used to create the test templates contained with each template folder.

4.4.1 Creating Template Folders Project members may use controls in the Template Folder Submission page to create new template folders in the template tree panel and define template folder properties.

Figure 4-5: Sample Project Template Folder Submission Pages The Template Folder Submission pages is a multiple-page tabbed form comprised of custom pages and system pages. Project administrators may choose to add or remove pages from this function page. Each page in the Template Folder Submission page enables project members to define a different set of template folder properties.

The Folder Description page enables project members to define basic template folder properties. The Environment Variable page enables project members to define which environmental variables may be used in test templates contained within the template folder. The Applicable Project page enables project members to define which work projects may access the test templates contained in a template folder. The Write Access Control page enables project members to define which project members may add, edit, or delete subfolders or test templates to a template folder.

To create template folders: 1. Right-click a template folder in the template tree panel. The Template Folder shortcut menu appears. 2. Select the Insert Folder command.

The Submission Pages tabbed form appears. 3. Define template folder properties in the Folder Description page. 4. Define the environmental variables in the Environmental Variables page. 5. Define the applicable projects in the Applicable Projects page.. 6. Grant write access privileges in the Write Access page. 7. Click the OK button. The template folder appears in the test template tree menu.

Project members must be granted the Can Create Template Folder privilege by a project administrator to create template folders.

4.4.2 Editing Template Folders Project members may use the Template Folder Editing page to update template folder properties. Using tools in the Template Folder Editing page, project members may edit template folder properties, environmental variables, applicable project settings, and other settings in the Template Folder Editing pages. The Template Folder Editing pages is a multiple-page tabbed form comprised of custom pages and system pages. Each page in the Template Folder Editing pages enables project members to define a different set of template folder properties.

The Folder Description page enables project members to define basic template folder properties. The Environment Variable page enables project members to define which environmental variables may be used in test templates contained within the template folder. The Applicable Project page enables project members to define which work projects may access the test templates contained in a template folder. The Write Access Control page enables project members to define which project members may add, edit, or delete subfolders or test templates to a template folder. The Change Log system page enables project members to view changes made to template folders. The Time Report system page enables project members to view the total estimated effective time, estimated ineffective time, and estimated total time for all test templates

contained in a template folder. The Notes Page system page enables project members to add notes to template folders.

Editing pages are customizable and project administrators may choose to include or exclude any number of pages in the tabbed form. The more pages that are added to the Template Folder function page by an administrator, the more powerful the page. To edit template folders:

1. Right-click a template folder in the template tree panel. The Template Tree shortcut menu appears.

2. Select the Properties command. The Editing Pages tabbed form appears.

3. Define template folder properties in the Folder Description page. 4. Define the environmental variables in the Environmental Variables page.

Environmental variables may be defined on a folder-by-folder basis or a template-by-template basis. 5. Review changes made to the template folder in the Change Log page. 6. Define the estimated effective time, estimated ineffective time, and estimated total time for the test template in the Time Report page.

The properties defined in the Time Report page determine the estimated effective time, estimated ineffective time, and estimated total time for all test templates contained in the template folder.

7. Add notes or attachments in the Notes page. 8. Define the work projects that may access the test templates contained in this folder in the Applicable Projects page. 9. Click the OK button.

The Confirm Setting Changes dialog box appears. Any changes to the environmental variable or applicable projects settings for a folder may be applied to any subfolders contained in the current folder.

10. Define the Environmental Variable settings: To apply the environmental variable settings to subfolders, click the Apply Changes to this Folder Only radio button. To not apply the environmental variable settings to subfolders, click the Apply Changes to this Folder and Its Subfolders radio button. 11. Define the Applicable Project settings: If you do not want the applicable project settings to apply to subfolders, click the Apply Changes to this Folder Only radio button. If you do not want the applicable project settings to apply to subfolders, click the Apply Changes to this Folder and Its Subfolders radio button.

12. Click the OK button. The test template folder properties are updated.

Project members must be granted the Can Edit Template Folder privilege by a project administrator to edit template folder properties.

4.4.3 Understanding Template Folder Properties Project members may use controls in the Folder Description page to define template folder properties whenever they create or edit a template folder.

The Folder Name field enables project members to define the title of each template folder displayed in the template tree panel. The Folder Description field enables project members to describe a template folder and its contents. The Folder Status control enables project members to define the state of the template folder. In the sample project a folder may have three statuses: Active, Inactive, and

Archived. Project administrators may define template folder states that are appropriate to project workflow. The Default Value dropdown list enables project members to choose the default value template used to create the test templates contained in each template folder. The Is Read-Only control enables project members to make the contents of the folder read-only to users who do not have privileges.

The Folder Description page may be displayed in both the Template Folder Submission page and the Template Folder Editing page.

4.4.4 Defining Applicable Projects The Applicable Projects page enables project members to define which work projects may access and use the test templates contained in a test template folder. An applicable project is any work project that may use the test templates contained in a template folder to generate test tasks. Project members may define Applicable Project properties whenever the add or edit a template folder provided that the project administrator has added this page to the Template Folder Submission page or the Template Folder Editing page. To define applicable projects:

1. Click the Applicable Projects tab in either the Template Folder Submission pages or the Template Folder Editing page. 2. Choose a project selection option:

To select all available work projects, select the All radio button. To manually select work projects from the list, select the Selected radio button.

3. If you choose the manual option, select work projects in the Working Projects area. Only those projects with a check mark next to their name may use test templates contained in this folder.

4. To apply applicable project settings to all subfolders contained within the current template folder, click the Apply to Child Folder check box. 5. Click the OK button.

4.4.5 Granting Write Access Privileges Project members may use the Write Access page to grant write privileges to other project members whenever they create or edit a template folder. The Write Access page may be added to the Template Folder Submission page or Template Folder Editing page by a project administration in DevTest Admin.

4.4.6 Viewing Template Folder Changes

Project members may view a read-only audit trail of all changes made to template folders in the Change Log page. The Change Log page displays every change made to controls displayed in the Template Folder Editing page. The Change Log page may be displayed in the Template Folder Editing pages and may be accessed whenever a project members updates template folder properties.

4.4.7 Managing Template Folder Notes Project members may use the tools in the Notes page of the Template Folder Editing pages to manage notes and note attachments for each template folder.

4.4.8 Viewing Template Folder Time Tracking Estimates Project members may use the Time Report page to view the estimated effective time, estimate ineffective time, and estimated total time for every test template stored in a template folder. The data displayed in the Time Report page enables project members to gauge the time required for work project members to complete the test tasks based on test template contained in a particular template folder.

The Estimated Effective Time represents the estimated time needed to perform a test task based on the test procedure defined in the parent test template. The Estimated Ineffective Time represents a combination of the estimated time needed to set up an application for testing and the estimated processing time. The Total time represents the combination of the estimated effective time and the estimated ineffective time.

Project members may select the Include All Child Folders check box to view the total time tracking estimates for every test template contained in the current template folder, including those in all subfolders. Project members may define test procedures, estimated effective times, and estimated ineffective times whenever they create or edit test templates in the template view.

4.4.9 Deleting Template Folders Project members may use the Delete Folder command in the Template Tree shortcut menu to delete test template folders in the template tree panel. Project members may only delete a template folder if that template folder does not contain any test templates. To delete template folders:

1. Right-click a template folder in the template tree panel. The Template Tree shortcut menu appears.

2. Select the Delete Folder command. The Are You Sure You Want to Delete the Selected Folder dialog box appears.

3. Click the Yes button. The template folder is immediately removed from template tree panel.

Project members must be granted the Can Delete/Move Template Folder privilege by a project administrator to delete or move template folders.

4.4.10 Dragging and Dropping Template Folders Project members may use two methods of organizing template folders in the template tree panel:

Moving test template folders Copying and pasting test template folders

The easiest way to reorganized test template folders in the template tree panel is to select a template folder and then drag it to a new location. The selected template folder and all of its contents (subfolders and test templates) immediately move to the new directory.

Moved template folders maintain their original Template Folder ID numbers. Moved test template records maintain their original Test Template ID numbers.

Project members must be granted the Can Delete/Move Template Folder privilege by a project administrator to delete or move template folders.

4.4.11 Copying and Pasting Template Folders Project members may the Copy command and Paste command in the Template Tree shortcut menu, to move test template folders from one directory to another directory in the template tree panel. Moving template folders is a two step process:

Copying a template folder saves all folder contents (including subfolders and test templates) to the clipboard. Pasting a template folder inserts the template folder and all folder contents to the selected directory or folder.

Whenever a template folder is pasted to a new directory, the template folder and all subfolders are immediately assigned a new Template Folder ID numbers and all test templates are also immediately issued new Test Template ID numbers. To copy test template folders:

Author: TechExcel co.Ltd

Date:

Table of Content

DevTest User Guide

Key Benefits Gain control over product quality with real-time test results reporting, tracking and analysis that let's you know what has been tested and what still needs to be done. Improve test standardization, re-use, and revision control using a centralized test library. Increase your team's productivity with reduced data entry, definable test interfaces, and process automation. Ensure ultimate accountability for all test phases with detailed histories of test cases, data and test results. Features Overview Defect tracking Track each issue through a definable workflow SCM integration track fixes against their source code deliverables Deploy a resolution across multiple releases, versions and products Reporting and metrics to illustrate the entire defect lifecycle Test management and execution Create a central repository for your test cases, knowledge items and automation scripts Schedule releases and test cycles using a wizard-driven interface Execute test assignments and submit defects from the same interface Track results with real-time dashboards and reports Test automation Out-of the-box integration with TestComplete Add automated tests to the DevTest test library Schedule automated tests along with manual tests Launch automated tests from the DevTest interface Track automation results with real-time dashboards and reports

Chapter 1 DevTest Concepts

1 DevTest Concepts

In this chapter: Understanding DevTest Test Management Understanding Test Management Knowledge Management Test Planning and Organization Scheduling and Assigning Testing Running Tests and Tracking Results

1.1 Understanding DevTest Test Management Product testing is more complicated, labor-intensive, and time-consuming than ever before. Businesses are demanding greater openness, transparency, and scalability from their software investments they are looking for versatile solutions that enable them connect users and resources worldwide while leveraging their existing investments. As a result, contemporary business applications run on many different platforms and in many different environments, support integration with emerging technologies and legacy systems, and feature add-on modules that support every imaginable business process. All this versatility has multiplied the number of variables that may affect the performance application making the task of testing software more complicated and time-consuming than over before. But the same forces that drive the demand for these applications also require that these products be delivered to market as quickly as possibleif not sooner. QA organizations are under increasing pressure to complete their testing in ever-shorter time frames. And, as if this were not enough, these challenges are compounded by hectic development schedules that introduce problems all their ownnew features may suddenly appear or disappear, the design and functionality of product features often change to meet the demands of the marketplace or to accommodate tight schedules. To meet these challenges, QA organizations are pursuing several different strategies beginning their test planning earlier in the development life cycle, leveraging the results of previous test efforts, improving the management of testing data, and reusing existing test coverage. And increasingly, many testing organizations are abandoning outmoded paper-based systems and turning to software test management solutions to organize, plan, and analyze their testing efforts.

1.2 Understanding Test Management In the past, testing organizations could rely onpaper-based solutionsto plan, design, manage, and track their testing projects. Older technologies did not require the same degreeof planning and organization as do contemporary software suitesthey lacked the portability, the versatility, and extensibility. But even with simple applications, paper-based systems aremerely adequate. The lack of organization, poor planning, and inefficient communication that are inherit in paper-based systems regularly jeopardize delivery schedules and, ultimately, jeopardize the quality of the product itself. In a paper-based system all testing activities are recorded and tracked in static lists, tables, outlines, and matrices created in word processing documents or spreadsheets. Paper-based solutions are difficult to maintain, update, and track. As a result, testing strategies are necessarily straight forward and limited, because testing teams are straitjacketed from the very start of the process. Poor or inaccessible documentation and inadequate channels for communication make it difficult for QA organizations to adjust to sudden changes in product design. Test plans are frequently based on out-dated requirements documents, and this can lead to test cases that do not adequately test product features and functionality. Understandably, test planning is frequently left to late in the development life cycle when the product approachessomekind of stasis. But delaying test planning creates a whole new set of hurdles. Time pressures mean that QA organizations must focus on testing the application at hand and have little time to plan ahead for future release cycles. Hastily created test cases are generally not reusable. Test planning efficiency can be improved when the test planners can base future test assignments on previous results and an analysis or test or defect data. But tight schedules mean there is little time for reflection or future planning. And even if there were time, traditional models make it difficult to review previous test data or defect data because it is often inaccessiblelost or misplaced in a stack of paper, buried in someones inbox, or stored away somewhere in different files or applications. Why test management? Because test management solutions enable businesses to work more intelligently and efficiently. Test management solutions provide following benefits:

Manage knowledge and facilitate communication:A test management solution provides testers with a centralized and secure tool through which they may review control documents and research previously reported bugs. Knowledge collected by the testing group is accessible to all project members at all times.

Enforce the standardization of test cases: A test management solution enables the testing group to define the data they wish to track and to design a standard interfacefor collecting and tracking that data. Standards increase efficiency.

Promote the creation of reusable test cases: A test management solution makes it easy for testing groups to save, manage, and reuse their most effective test cases. Leverage previous results in test planning: A test management solution enables testing groups to plan future test assignments based on the analysis previous test

results. Instant access to summary reports enables test planner to improve test efficiency. Respond to issues quicker:A test management solution provides real-time access to all testing data so that testing groups can immediately respond to critical test

blockers or and other issues. The faster the team is able to address the critical issues the sooner the test team may resume their testing. Make information accessible: A test management solution provides a test planners with a complete picture of their testing project so that they better manage their

project and they can make the necessary adjustments to meet testing objectives and deadlines.

1.3 Knowledge Management One key factor to meeting the demands of contemporary software development is to ensure that all project stakeholdersmanagement, developers, and testers have access tothe most up-to-date control documents and may effectively communicate with others both within and outside their organizations and teamsin short, everyone must beon the same pageat all times. To address this issue, TechExcel DevTest takes a knowledge-centricapproach to test management that places the collection, management, and distribution of information at the core of all development and quality assurance processes. Knowledge management enables all stakeholders to access, manage, and share information so that QA may make informed decisions throughout the testing process, leverage the information collected and generated by development, and learn from their past successes and failures so that they may implement more efficient and intelligent processes. Key components of the DevTest approach to knowledge management include a centralized knowledge base, instant access to quality reports, and tools for communicating information relevant to individual test cases and the project as a whole.

1.3.1 Managing Project Knowledge In DevTest, all testers may access a centralized repository of information from within the DevTest client. The DevTest knowledge view, powered by TechExcel KnowledgeWise, provides development and QA organizations with a tool for collecting and organizing the ideas that drive product development and testing. All ideas, both formal and informal are collected and managed in the same, centralized knowledge base. TechExcel KnowledgeWise is a key component in the TechExcel DevSuite of application life cycle management products. KnowledgeWise provides project managers, designers,developers, testing groups, and sales and marketing departments with a secure repository for all project documentsthe project plan, business requirements, functional and technical specifications, risk management documents, and corporate standards and guidelines may be managed in one knowledge base that is shared by the entire business.

A centralized knowledge base increases efficiency, prevents the loss of information, helps to reduce system and maintenance costs, and facilitates collaboration by distributed teams.

Access to knowledge items is protected by privilege-based access controls. The ability of project members to view, edit, lock, check out, and check in protected files is defined by their role in the project.

Built-in version control tools ensure that all project development and testing teams (no matter where they are in world) always have access to the most up-to-date documents.

1.3.2 Leveraging Control Documents A common knowledge base ensures that the QA organization always has access to the latest project control documents business requirements, functional and technical specifications and enables them to leverage this information to plan and organize their test plans early in the development processes. In DevTest, QA organizations may access project control documents as soon as those documents are uploaded to the knowledge baseat the same time they are available to the developers themselves. Access enables the QA organization to jump-start test planning and develop testing strategies and test cases in parallel with the implementation of the designs. Using these control documents, testing groups may estimate the scope of the project, allocate resources, and plan appropriate strategies for testing the functionality and performance of those features. Testing groups need not wait forallof the control documents to be approved before they begin their test planning. They can create test cases and build test planning structures in a piecemeal fashion as thedesigned productis realized in the knowledge base. With each new control document that is added to the knowledge base they can create appropriate test cases. Ideally, project control documents are complete and approved at the beginning of the test planning stage. However, the specifications and designs that are approved at the beginning of the development process may be sketchy, inadequate, or change significantly over time due to changes in the marketplace, technical problems, or time constraints. DevTest provides testing groups with the flexibility they need to adjust to changes in design or schedule. QA organizations may take anevolutionaryapproach to test planning. By organizing their test cases by product features, they can readily adjust to changes in product design or changes to the schedule. They may create appropriate structures and test cases as the requirements and specifications are completed and update the list to accommodate changes to the application. DevTest planning structures and test cases may be easily edited and updated so that QA organizations need not pay the penalty for changes in design.

1.3.3 Facilitating Task-level Communication By placing knowledge management at the core of all development processes, DevTest facilitates all project-level and task-level communication. Just as the centralized knowledge base ensures that all stakeholders have access to project information, the complete history of every test case and all background information is always right at hand. All communication is recorded and tracked with the test case so that test task itself is the vehicle for communication. Key information cannot be lost in e-mail exchanges or buried in user inboxes. Good notes from the prior testing enables test team members to pick up testing where others have left off. Any testing team member may pick up the work of another tester, and with a little research understand the test in its entirety. Every test case may be directly linked to supporting materialstest plans, business requirements, schedules, and so on that enable testers to run successful tests. Testers may read all business requirements and specifications and compare product functionality against those control documents.

1.4 Test Planning and Organization Test planning begins with the identification and definition of product features in a feature list: a simple list of the visible functions, subfunctions, commands, menu choices, reports, and so on that needs to be tested. Whereas a feature list begins as simple list of all of the product features that need to be tested, it is ultimately an outline of the testingproject in which product features categorized and prioritized. In DevTest, the feature list is articulated as a hierarchical tree structure that both organizes test cases and represents the product to be tested. DevTest transforms the information that previously captured in static lists into a dynamic structure called atest librarythat helps testing groups to manage their testing project, improve team efficiency, and find bugs.

1.4.1 Test Case Organization The TechExcel DevSuite of applications conceptualizes the product under development as afully designed product that is articulated, managed,and communicated in DevTest project structuresprior toits actual implementation product features define the structure that is used to organize and manage the implementation and testing of those features. The DevTest test library is sometimes called the functional treebecause it organizes test cases by product functions. The tree structure enables the testing group to visualize the entire application and understand the relationship between every area under development. Every product feature may be represented by a unique branch and contain multiple subfolders representing feature subfunctions. Every dialog box, command, report, error message, menu option, and so on may be represented by a subfolder in the test library. The test library defines the scope of the project, shows the relationship between product features, and manages the test templates that will be used to test those features.

The test template tree manages the test library: The template tree structure enables testing groups to manage test templates in a hierarchical tree structure. Test templates may be organized by product, functional area, test type, or any other categories that is useful to their business.

The template tree defines project scope: The test template tree may represent the product being tested organized into functional areas and enables testing groups to better provide full test coverage of all product features. Organizing the test library by product, feature, and function shows every area under development. Project managers may use the test template tree to estimate the resources needed for the testing project.

The test template tree helps test designers to create better tests:Representing the product enables testing groups to visualize the designed productdescribed in the control documents, analyze its design, and identify good tests for its feature. Understanding how the program features work together enables testers to develop test cases that are more likely to find bugs and combine or eliminate redundant tests.

The test template tree makes test templates accessible: A library of tests is only useful if the test cases are accessible. The template structure enables project teams to define hierarchical structures for organizing templates and making them accessible to users.

The test template tree shows all areas of development.Testing groups may ensure that every feature is properly tested and prioritize test coverage by module, component, or feature. The test template tree shows which functional areas have been tested and which areas have not so that testing groups can make sure that they don't do duplicate work.

1.4.2 Test Case Definition and Standardization DevTest enables organizations to define custom test cases and enforce standardization throughtest templates. A test template is a blueprint for creating test cases that may be used to test product features and performance across multiple builds, platforms, and

DevTest User Guide - TechExcelhelp.techexcel.com/knowledgewise/DocInfo.aspx?wtqxqxwoxq.pdf ·...

Documents

Transcript of DevTest User Guide - TechExcelhelp.techexcel.com/knowledgewise/DocInfo.aspx?wtqxqxwoxq.pdf ·...