DevTest Admin Guide

80 Pages·2012·1.44 MB·English

DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide 5
Chapter 1 DevTest Concepts 5
1 Chapter 1- DevTest Concepts 5
1.1 Understanding DevTest Test Management 5
1.2 Understanding Test Management 5
1.3 Knowledge Management 5
1.4 Test Planning and Organization 6
1.5 Scheduling and Assigning Testing 7
1.6 Running Tests and Tracking Results 7
Chapter 2 DevTest Admin Basics 8
2 Chapter 2- DevTest Admin Basics 8
2.1 Understanding the DevTest Administration 8
2.2 Understanding the DevTest Admin Workspace 8
2.3 Accessing DevTest Projects 9
2.4 Understanding the DevTest Administration 10
2.5 Understanding the DevTest Admin Workspace 10
2.6 Accessing DevTest Projects 11
Chapter 3 Site and System Administration 11
3 Chapter 3- Site and System Administration 11
3.1 Understanding DevTest Site Administration 11
3.2 Administering DevTest Database Servers 12
3.3 Administering DevTest Application Servers 12
3.4 Administering the DevTest Document Server 13
3.5 Administering System Date and Time Settings 14
3.6 Administering System Messages and Help 14
3.7 Administering DevTest Admin Reports 15
3.8 Administering DevTest Web 16
3.9 Administering DevSuite Integration 17
3.10 Administering Multiple Sites 18
Chapter 4 System Level User Administration 19
4 Chapter 4- System Level User Administration 20
4.1 Understanding System-Level User Administration 20
4.2 Administering User Licenses 22
4.3 Administering User Accounts 22
4.4 Administering LDAP Directory Server Integration 25
4.5 Administering User Logins 25
4.6 Administering System and Project Administrators 27
Chapter 5 Project Administration 28
5 Chapter 5- Project Administration 28
5.1 Administering DevTest Projects 28
5.2 Administering General Project Settings 31
5.3 Administering DevTest Projects 32
5.4 Administering General Project Settings 34
Chapter 6 Team Administration 35
6 Chapter 6- Team Administration 35
6.1 Administering Work Project Privileges and Access Controls 35
6.2 Administering Team Groups 36
6.3 Understanding Team Administration 37
6.4 Administering Account Types, Access Controls, and Privileges 37
6.5 Administering Template Project Privileges and Access Controls 38
6.6 Administering Project Members 39
6.7 Administering Group Folders 40
Chapter 7 Template Project Administration 41
7 Chapter 7- Template Project Administration 41
7.1 Administrating Template Projects 41
7.2 Administrating Test Template Folders 41
7.3 Administering Test Templates 42
7.4 Administering Template Project Workflow 43
7.5 Administrating Environment Variables 46
Chapter 8 Test Planning Administration 47
8 Chapter 8- Test Planning Administration 47
8.1 Understanding DevTest Test Planning 47
8.2 Administering Planning Folders 47
8.2.1 Customizing the Planning Folder Notes Page 47
8.3 Administering Planning Wizards 48
8.3.1 Understanding the Release Wizard 48
8.3.2 Understanding the Test Cycle Wizard 48
8.3.3 Defining Wizard Page Titles and Descriptions 48
8.3.4 Defining Coverage Update Warning Messages 49
8.3.5 Displaying the Notes Page in Planning Folders 49
8.3.6 Displaying Target Data in the Release Folder Editing Page 49
8.3.7 Displaying Target Data in the Release Wizard 49
8.3.8 Enabling Target Data Reporting 49
8.4 Administering Summary Reports
Page 2 of 80
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports 49
8.4.1 Understanding Summary Report Columns 50
8.4.2 Adding or Removing Summary Reports 50
8.4.3 Defining Planning Summary Report Refresh Options 50
8.4.4 Defining Display Names for Summary Report Columns 50
8.4.5 Customizing the Summary Report 50
8.4.6 Customizing the Test Coverage Summary Report 51
Chapter 9 Test Task Administration 51
9 Chapter 9- Test Task Administration 51
9.1 Understanding Test Task Management 51
9.2 Customizing Test Task Function Pages 51
9.2.1 Customizing the Test Task Editing Function Page 51
9.2.2 Customizing the Test Task Detail Function Page 51
9.2.3 Customizing Test Task Forward Function Page 51
9.2.4 Customizing Test Task Override Function Page 52
9.2.5 Customizing the Test Task Group Change Function Page 52
9.2.6 Customizing the Test Task Group Forward Function Page 52
9.3 Customizing the Test Task List Panel 52
9.3.1 Adding or Removing List Columns 52
9.3.2 Defining Test Task List Indicator Icons 53
9.3.3 Defining Test Task List Text Formatting 53
9.4 Administering Test Task Workflow 53
9.4.1 Understanding Task States 53
9.4.2 Understanding Verification Points and Test Task Workflow 54
9.4.3 Enabling State-to-State Transition Workflow Rules 54
9.4.4 Enabling Applicable Owner Workflow Rules 54
9.4.5 Enabling Read-only Field Workflow Rules 54
9.4.6 Enabling Invisible Field Workflow Rules 54
9.4.7 Enabling Mandatory Field Workflow Rules 54
9.4.8 Enabling Access Control Workflow Rules 54
9.4.9 Enabling Product Defect Submission Triggers 54
9.4.10 Defining State-to-State Transition Workflow Rules 54
9.4.11 Defining Applicable Owner Workflow Rules 54
9.4.12 Defining Applicable Owners in the User Manager 55
9.4.13 Defining Task State Access Controls 55
9.4.14 Defining Read-Only Field Workflow Rules 55
9.4.15 Defining Invisible Fields Workflow Rules 55
9.4.16 Defining Mandatory Fields Workflow Rules 55
9.4.17 Defining Defect Submission Trigger Workflow Rules 56
Chapter 10 GUI Customization 56
10 Chapter 10- GUI Customization 56
10.1 Understanding the DevTest Clients 56
10.1.1 Understanding DevTest Admin 56
10.1.2 Understanding the DevTest Clients 56
10.2 Understanding Projects 57
10.2.1 Understanding Project Hierarchy 57
10.2.2 Understanding Knowledge Projects 58
10.2.3 Understanding Template Projects 58
10.2.4 Understanding Work Projects 58
10.3 Understanding Views 58
10.3.1 Understanding the Knowledge View 59
10.3.2 Understanding the Template View 59
10.3.3 Understanding the Planning View 60
10.3.4 Understanding the Task View 60
10.3.5 Understanding the Report View 60
10.3.6 Understanding the DevTrack View 61
10.4 Understanding Panels 61
10.4.1 Understanding Tree Windows 61
10.4.2 Understanding List Windows 62
10.4.3 Understanding Detail Windows 62
10.5 Understanding Pages 62
10.5.1 Understanding Function Pages 62
10.5.2 Understanding System Pages 63
10.5.3 Understanding Custom Pages 63
10.5.4 Understanding Planning Wizard Pages 63
10.6 Administering Page Customization 63
10.7 Understanding Function Pages 63
10.7.1 Understanding Applicable System Pages 64
Chapter 11 DevTrack Integration 64
11 Chapter 11- DevTrack Integration 64
11.1 Understanding DevTest-DevTrack Integration 64
11.1.1 Understanding System-Level Integration 65
11.1.2 Understanding the DevTrack View 65
11.2 Administering DevTest-DevTrack System-Level Integration 65
11.2.1 Enabling DevTest-DevTrack Site Integration 65
11.2.2 Integrating DevTest with DevTrack Sites 66
11.3 Administering DevTest-DevTrack User Mapping and Privileges 66
11.3.1 Manually Mapping DevTest Users to DevTrack Users 67
11.3.2 Automatically Mapping DevTest Users to DevTrack Users 67
11.3.3 Exporting Users from DevTest to DevTrack Sites 67
11.3.4 Importing User Accounts from DevTrack to DevTest 68
11.3.5 Administering DevTrack View Privileges 68
11.4 Administering DevTrack Issue Submission Settings 69
11.4.1 Defining DevTrack Issue Submission Settings Page 3 of 80
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings 69
11.4.2 Mapping DevTest Fields to DevTrack Fields 69
11.4.3 Mapping DevTest and DevTrack Field Choices 70
11.5 Administering DevTest-DevTrack Interproject Searching 70
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields 71
Chapter 12 Knowledge Administration 72
12 Chapter 12- Knowledge Administration 72
12.1 Understanding DevTest Knowledge Management 72
12.2 Administrating Project-Level Knowledge 72
12.2.1 Creating Knowledge Folders 72
12.2.2 Editing Knowledge Folders 73
12.2.3 Defining Knowledge Folder Access Privileges 73
12.2.4 Defining Knowledge Folder Build Privileges 73
12.2.5 Defining Knowledge Project Field Labels 73
12.2.6 Defining Knowledge Topic Page 74
12.3 Administrating Task-Level Knowledge 74
Chapter 13 Email Notification Administration 74
13 Chapter 13- Email Notification Administration 74
13.1 Administering E-mail Notification 74
13.1.1 Enabling E-mail Notification 74
13.2 Administering E-mail Notification Triggers 74
13.2.1 Understanding E-mail Notification Triggers 75
13.2.2 System triggers 75
13.2.3 Custom triggers 75
13.2.4 Defining E-mail Notification State Change Triggers 75
13.2.5 Defining E-mail Notification Field Change Triggers 75
13.3 Administering E-mail Notification Recipients 75
13.3.1 Understanding E-mail Notification Recipients 75
13.3.2 Defining E-mail Notification Recipients 75
13.3.3 Defining User Defined Address Lists 76
13.4 Administering E-mail Notification Conditions 76
13.4.1 Defining Task State E-mail Notification Conditions 76
13.4.2 Defining Keyword E-mail Notification Conditions 76
13.5 Customizing E-mail Message Templates 76
13.5.1 Understanding E-mail Message Template Variables 76
13.5.2 Subject line field content variables 76
13.5.3 Body field name variables 77
13.5.4 Body field content variables 77
13.5.5 Defining Auto E-mail Message Templates 77
13.5.6 Defining Manual E-mail Message Templates 77
13.5.7 Defining New Test Cycle E-mail Message Templates 77
13.5.8 Defining E-mail Subject Line Prefixes 78
13.6 Administering E-mail Integration 78
13.6.1 Defining General E-mail Properties 78
13.6.2 E-mail Authentication 78
13.6.3 Character Sets 78
13.6.4 Defining the Incoming Mail Server 78
13.7 Administering E-mail Escalation 78
13.7.1 Enabling E-mail Escalation 79
13.7.2 Understanding Escalation Rules 79
13.7.3 Defining E-mail Escalation Rules 79
13.7.4 Understanding Escalation Actions 79
13.7.5 Defining Escalation Actions 79
DevTest Admin Guide

Chapter 1 DevTest Concepts
Page 4 of 80
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
Managing Project Knowledge Page 5 of 80

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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently. Page 6 of 80
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not questPioan gine w 7hi coh fv e8rs0ion
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Page 8 of 80
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
Page 9 of 80
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.
DevTest Admin Guide
Author: TechExcel co.Ltd

Date:

Table of Content
DevTest Admin Guide
Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
1.1 Understanding DevTest Test Management
1.2 Understanding Test Management
1.3 Knowledge Management
1.4 Test Planning and Organization
1.5 Scheduling and Assigning Testing
1.6 Running Tests and Tracking Results
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
2.1 Understanding the DevTest Administration
2.2 Understanding the DevTest Admin Workspace
2.3 Accessing DevTest Projects
2.4 Understanding the DevTest Administration
2.5 Understanding the DevTest Admin Workspace
2.6 Accessing DevTest Projects
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
3.1 Understanding DevTest Site Administration
3.2 Administering DevTest Database Servers
3.3 Administering DevTest Application Servers
3.4 Administering the DevTest Document Server
3.5 Administering System Date and Time Settings
3.6 Administering System Messages and Help
3.7 Administering DevTest Admin Reports
3.8 Administering DevTest Web
3.9 Administering DevSuite Integration
3.10 Administering Multiple Sites
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
4.1 Understanding System-Level User Administration
4.2 Administering User Licenses
4.3 Administering User Accounts
4.4 Administering LDAP Directory Server Integration
4.5 Administering User Logins
4.6 Administering System and Project Administrators
Chapter 5 Project Administration
5 Chapter 5- Project Administration
5.1 Administering DevTest Projects
5.2 Administering General Project Settings
5.3 Administering DevTest Projects
5.4 Administering General Project Settings
Chapter 6 Team Administration
6 Chapter 6- Team Administration
6.1 Administering Work Project Privileges and Access Controls
6.2 Administering Team Groups
6.3 Understanding Team Administration
6.4 Administering Account Types, Access Controls, and Privileges
6.5 Administering Template Project Privileges and Access Controls
6.6 Administering Project Members
6.7 Administering Group Folders
Chapter 7 Template Project Administration
7 Chapter 7- Template Project Administration
7.1 Administrating Template Projects
7.2 Administrating Test Template Folders
7.3 Administering Test Templates
7.4 Administering Template Project Workflow
7.5 Administrating Environment Variables
Chapter 8 Test Planning Administration
8 Chapter 8- Test Planning Administration
8.1 Understanding DevTest Test Planning
8.2 Administering Planning Folders
8.2.1 Customizing the Planning Folder Notes Page
8.3 Administering Planning Wizards
8.3.1 Understanding the Release Wizard
8.3.2 Understanding the Test Cycle Wizard
8.3.3 Defining Wizard Page Titles and Descriptions
8.3.4 Defining Coverage Update Warning Messages
8.3.5 Displaying the Notes Page in Planning Folders
8.3.6 Displaying Target Data in the Release Folder Editing Page
8.3.7 Displaying Target Data in the Release Wizard
8.3.8 Enabling Target Data Reporting
8.4 Administering Summary Reports
8.4.1 Understanding Summary Report Columns
8.4.2 Adding or Removing Summary Reports
8.4.3 Defining Planning Summary Report Refresh Options
8.4.4 Defining Display Names for Summary Report Columns
8.4.5 Customizing the Summary Report
8.4.6 Customizing the Test Coverage Summary Report
Chapter 9 Test Task Administration
9 Chapter 9- Test Task Administration
9.1 Understanding Test Task Management
9.2 Customizing Test Task Function Pages
9.2.1 Customizing the Test Task Editing Function Page
9.2.2 Customizing the Test Task Detail Function Page
9.2.3 Customizing Test Task Forward Function Page
9.2.4 Customizing Test Task Override Function Page
9.2.5 Customizing the Test Task Group Change Function Page
9.2.6 Customizing the Test Task Group Forward Function Page
9.3 Customizing the Test Task List Panel
9.3.1 Adding or Removing List Columns
9.3.2 Defining Test Task List Indicator Icons
9.3.3 Defining Test Task List Text Formatting
9.4 Administering Test Task Workflow
9.4.1 Understanding Task States
9.4.2 Understanding Verification Points and Test Task Workflow
9.4.3 Enabling State-to-State Transition Workflow Rules
9.4.4 Enabling Applicable Owner Workflow Rules
9.4.5 Enabling Read-only Field Workflow Rules
9.4.6 Enabling Invisible Field Workflow Rules
9.4.7 Enabling Mandatory Field Workflow Rules
9.4.8 Enabling Access Control Workflow Rules
9.4.9 Enabling Product Defect Submission Triggers
9.4.10 Defining State-to-State Transition Workflow Rules
9.4.11 Defining Applicable Owner Workflow Rules
9.4.12 Defining Applicable Owners in the User Manager
9.4.13 Defining Task State Access Controls
9.4.14 Defining Read-Only Field Workflow Rules
9.4.15 Defining Invisible Fields Workflow Rules
9.4.16 Defining Mandatory Fields Workflow Rules
9.4.17 Defining Defect Submission Trigger Workflow Rules
Chapter 10 GUI Customization
10 Chapter 10- GUI Customization
10.1 Understanding the DevTest Clients
10.1.1 Understanding DevTest Admin
10.1.2 Understanding the DevTest Clients
10.2 Understanding Projects
10.2.1 Understanding Project Hierarchy
10.2.2 Understanding Knowledge Projects
10.2.3 Understanding Template Projects
10.2.4 Understanding Work Projects
10.3 Understanding Views
10.3.1 Understanding the Knowledge View
10.3.2 Understanding the Template View
10.3.3 Understanding the Planning View
10.3.4 Understanding the Task View
10.3.5 Understanding the Report View
10.3.6 Understanding the DevTrack View
10.4 Understanding Panels
10.4.1 Understanding Tree Windows
10.4.2 Understanding List Windows
10.4.3 Understanding Detail Windows
10.5 Understanding Pages
10.5.1 Understanding Function Pages
10.5.2 Understanding System Pages
10.5.3 Understanding Custom Pages
10.5.4 Understanding Planning Wizard Pages
10.6 Administering Page Customization
10.7 Understanding Function Pages
10.7.1 Understanding Applicable System Pages
Chapter 11 DevTrack Integration
11 Chapter 11- DevTrack Integration
11.1 Understanding DevTest-DevTrack Integration
11.1.1 Understanding System-Level Integration
11.1.2 Understanding the DevTrack View
11.2 Administering DevTest-DevTrack System-Level Integration
11.2.1 Enabling DevTest-DevTrack Site Integration
11.2.2 Integrating DevTest with DevTrack Sites
11.3 Administering DevTest-DevTrack User Mapping and Privileges
11.3.1 Manually Mapping DevTest Users to DevTrack Users
11.3.2 Automatically Mapping DevTest Users to DevTrack Users
11.3.3 Exporting Users from DevTest to DevTrack Sites
11.3.4 Importing User Accounts from DevTrack to DevTest
11.3.5 Administering DevTrack View Privileges
11.4 Administering DevTrack Issue Submission Settings
11.4.1 Defining DevTrack Issue Submission Settings
11.4.2 Mapping DevTest Fields to DevTrack Fields
11.4.3 Mapping DevTest and DevTrack Field Choices
11.5 Administering DevTest-DevTrack Interproject Searching
11.5.1 Administering Custom Product Defect Search Fields to DevTrack Fields
Chapter 12 Knowledge Administration
12 Chapter 12- Knowledge Administration
12.1 Understanding DevTest Knowledge Management
12.2 Administrating Project-Level Knowledge
12.2.1 Creating Knowledge Folders
12.2.2 Editing Knowledge Folders
12.2.3 Defining Knowledge Folder Access Privileges
12.2.4 Defining Knowledge Folder Build Privileges
12.2.5 Defining Knowledge Project Field Labels
12.2.6 Defining Knowledge Topic Page
12.3 Administrating Task-Level Knowledge
Chapter 13 Email Notification Administration
13 Chapter 13- Email Notification Administration
13.1 Administering E-mail Notification
13.1.1 Enabling E-mail Notification
13.2 Administering E-mail Notification Triggers
13.2.1 Understanding E-mail Notification Triggers
13.2.2 System triggers
13.2.3 Custom triggers
13.2.4 Defining E-mail Notification State Change Triggers
13.2.5 Defining E-mail Notification Field Change Triggers
13.3 Administering E-mail Notification Recipients
13.3.1 Understanding E-mail Notification Recipients
13.3.2 Defining E-mail Notification Recipients
13.3.3 Defining User Defined Address Lists
13.4 Administering E-mail Notification Conditions
13.4.1 Defining Task State E-mail Notification Conditions
13.4.2 Defining Keyword E-mail Notification Conditions
13.5 Customizing E-mail Message Templates
13.5.1 Understanding E-mail Message Template Variables
13.5.2 Subject line field content variables
13.5.3 Body field name variables
13.5.4 Body field content variables
13.5.5 Defining Auto E-mail Message Templates
13.5.6 Defining Manual E-mail Message Templates
13.5.7 Defining New Test Cycle E-mail Message Templates
13.5.8 Defining E-mail Subject Line Prefixes
13.6 Administering E-mail Integration
13.6.1 Defining General E-mail Properties
13.6.2 E-mail Authentication
13.6.3 Character Sets
13.6.4 Defining the Incoming Mail Server
13.7 Administering E-mail Escalation
13.7.1 Enabling E-mail Escalation
13.7.2 Understanding Escalation Rules
13.7.3 Defining E-mail Escalation Rules
13.7.4 Understanding Escalation Actions
13.7.5 Defining Escalation Actions
DevTest Admin Guide

Chapter 1 DevTest Concepts
1 Chapter 1- DevTest Concepts
Wiki Summary.
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?hey 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 possible?Iif 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 own?ew 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 ?eginning 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 degree of
planning and organization as do contemporary software suites?hey 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 approaches some kind 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 their
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 inaccessible?ost or
misplaced in a stack of paper, buried in someone? 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 interface for 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 stakeholders, management, developers, and testers have access to the most up-
to-date control documents and may effectively communicate with others both within and outside their organizations and teams.In short, everyone must beon the same pageat all times.
To address this issue, TechExcel DevTest takes a ‘knowledge-centric’ approach 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.
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 documents?he 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.
Leveraging Control Documents
A common knowledge base ensures that the QA organization always has access to the latest project control documents ?usiness 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 base?t 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.
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 materials?est 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 need 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 testing project 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.
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 ?unctional tree?because 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 ?he designed product?described 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.
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 environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a
product feature can be easily accomodated.
In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome
of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI)
that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and
track testing data.
Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their
own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles.
Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared.
The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently.
Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test
cycle, or change in platform.
Test Templates and Test Tasks
As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the
QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle.
In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases
that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases
(test templates)andto track the performance of program features against that test (test tasks) in many different environments.
?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 environments.
?Test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was
used to create it.
What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an
application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental
factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors.
A single test template that includes one environmental variable may be used to generate multiple test tasks ?one for each environmental variable value ?or, if it includes many
environmental variables ?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental
variable values:Internet Explorer,Firefox, andSafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: aInternet Explorertest
task, aFirefoxtest task, and aSafaritest task.
1.5 Scheduling and Assigning Testing
DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test
management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics.
In DevTest, all test planning ?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles?he test
schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test
template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and
test cycles.
The DevTest two-tiered approach to test planning provides the following benefits:
View the test plan:The planning tree structure defines and shows the relationships between products, releases, and test cycles.
View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and
which areas have not been tested so that they can avoid unnecessary duplication of effort.
Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle.
Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test
cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release
cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release.
Planning Test Cycles
Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies
heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based
on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs.
Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the
testing objectives defined in the parent release cycle.
Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign
more complex test tasks to the testing group until the basic bugs are fixed.
Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to
generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group.
Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be
assigned to the same applicable owners or to any other applicable owner or applicable testing group.
Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They
may generate new test tasks based on the same test template to retest the feature.
Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found,
the effective time, the ineffective time, and the total time spend testing.
1.6 Running Tests and Tracking Results
Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze
the results of the test, and they are foundation for any bug reports based on that test.
DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases,
schedules, or test assignment accordingly.
DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared
to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle.
Submitting Bug Reports
DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the
sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be
retested in subsequent DevTest regression testing.
The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and
forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report
the less likely the tester is to forget key details that will enable developers to reproduce the bug.
Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure,
the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces
the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing.
Linking Test Cases to Bug Reports
During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively
communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports
only creates more work for the developers.
In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate
development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively.
Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team.
Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features.
Researching Existing Bug Reports
DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects
provides the following benefits:
Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers. ?Enables testers to fully understand product features and expected
behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical
specifications.
Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical
bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing
issues before they can submit a new bug report.
Sharing Experiences and Information
The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively.
As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks
notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing
groups within many other tools for communicating key information to developers.
DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools
enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information.
DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory
dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case.
The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version
or environment the bug was discovered.
Conclusion
TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis.
DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products.
Chapter 2 DevTest Admin Basics
2 Chapter 2- DevTest Admin Basics
Wiki Summary.
2.1 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges must open the appropriate project in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator,
division administrator, and project administrator account types.
System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.2 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated
testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages.

Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking
integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.3 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
2.4 Understanding the DevTest Administration
In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system
and project administrators to define, configure, and administer TechExcel sites and projects.
DevTest system administration is the process of configuring, administering, and maintaining aDevTest site. A site consists of a knowledge base project and multiple template basework
projects.Every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client.
Comparing System and Project Administration
All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator?
user account granted administrative privileges?ust open the appropriate ?roject?in the client.
DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator,
division administrator, and project administrator account types.
?SPAN style="FONT: 7pt 'Times New Roman'" System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level
settings.
?SPAN style="FONT: 7pt 'Times New Roman'" Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects.
Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own
unique team structure and workflow.
Understanding DevTest System Administration
System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation,
creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server.
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site.
DevTest system administration tasks fall into seven general areas:
?SPAN style="FONT: 7pt 'Times New Roman'" DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server,
DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level
administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Multiple Site Administration - Includes the definition and management of a site family and management of user licenses for all member
sites.
?SPAN style="FONT: 7pt 'Times New Roman'" License Management System-level tasks include license management and allocation. Web Administration
?SPAN style="FONT: 7pt 'Times New Roman'" Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in the site.
?SPAN style="FONT: 7pt 'Times New Roman'" E-mail Integration - Foundation of DevTest e-mail notification and escalation.
All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client.
2.5 Understanding the DevTest Admin Workspace
In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client.
When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site.

Figure 2-1: DevTest Admin Client
The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-
level features. The DevTest Admin client is organized into four sections:
?SPAN style="FONT: 7pt 'Times New Roman'" Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus
include the File, View, System, and Help menus.
?SPAN style="FONT: 7pt 'Times New Roman'" Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.
?SPAN style="FONT: 7pt 'Times New Roman'" Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed
in the tree panel depending on the project type opened: knowledge, template, or work.
?SPAN style="FONT: 7pt 'Times New Roman'" Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-level settings.
Understanding Menu Bar Commands
The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help
menus.
The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands
displayed in the Tool menu.
?SPAN style="FONT: 7pt 'Times New Roman'" File - Displays commands that enable the administrator to create, open, back up, restore work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin
client.
?SPAN style="FONT: 7pt 'Times New Roman'" System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user,
login, and license administration.
?SPAN style="FONT: 7pt 'Times New Roman'" Help - Displays commands that enable the administrator to access online help systems and information about the current build.
Understanding the Tool Bar Commands
The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest
Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings
buttons.
New Project button - Enables the administrator to create a new work project.
Open Project button - Enables the administrator to open an existing work project.
Close Project button - Enables the administrator to close a work project.
Back Up Project button - Enables the administrator to back up an existing work project.
Restore Project button - Enables the administrator to restore a closed work project.
Delete Project button - Enables the administrator to delete a work project.
Page 10 of 80
User Manager button - Enables the administrator to open the User Manager.
Login Manager button - Enables the administrator to open the Login Manager.
Understanding the Tree Panel
The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the
project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific.
Knowledge Project
In a knowledge base project the tree panel displays three folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and
define knowledge versioning controls.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child
template base and work projects.
?SPAN style="FONT: 7pt 'Times New Roman'" Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI.
To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator.
Test Template Project
In a test template project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including
environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.
?SPAN style="FONT: 7pt 'Times New Roman'" State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures,
administer system and custom fields, and customize template folder system, function, and custom pages.
?SPAN style="FONT: 7pt 'Times New Roman'" Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields,
and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template
project features including template status groups, TestLink automated testing integration, and email notification.
To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator.
Test Task Project
In a work project the tree panel displays five folders:
?SPAN style="FONT: 7pt 'Times New Roman'" Project Settings - The folder contains tools that enable the administrator to
?SPAN style="FONT: 7pt 'Times New Roman'" State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state
statuses and state-based workflow rules.
?SPAN style="FONT: 7pt 'Times New Roman'" Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer
system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.
?SPAN style="FONT: 7pt 'Times New Roman'" Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and
customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project
features including test task status groups, DevTrack bug tracking integration, email notification, and test time tracking.
To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator.
2.6 Accessing DevTest Projects
Logging into DevTest Projects
To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate ?roject?in the client.
To log into a DevTest project:
1.Select the DevTest Admin command in the Windows Start menu.

By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder.

The DevTest Admin Login dialog box appears.
2.Enter a user name and password.

Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not
case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible.

3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service.
Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site.
4Click the OK button. The DevTest Admin client opens.
5Select File Open Project in the File menu. The Open Project window appears.
6Select a project in the project list.
7Click the OK button. The project opens.
Switching Projects
To switch to another project:
1Select File Open Project in the File menu. The Open Project window appears.
2Select a project in the project list.
3Click the OK button. The project opens.
Closing DevTest Projects
Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:
?Select File Close Project in the menu bar.
?Press CTRL + S.
Chapter 3 Site and System Administration
3 Chapter 3- Site and System Administration
Wiki Summary.
3.1 Understanding DevTest Site Administration
In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of aDevTest
Serverand may include multiple knowledge, test template, and work projects.
DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest
Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools.
Site and System Administration
The foundation of every DevTest implementation -- called aDevTest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server,
DevTest Application Server, DevTest Document Server, and DevTest Web Services.

Figure 3-1: DevTest Core Architecture
DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts
connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server.
DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-
compliant DBMS.

DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data.

DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server.

DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure,
customize, and manage the DevTest site and multiple projects.

DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web
Server use the DevTest Document Server to access files including file attachments, e-mail attachments, and knowledge items.
Understanding System Administrator Privileges
All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type.
Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-
sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible.
3.2 Administering DevTest Database Servers
The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel
DevTest supports five database management systems (DBMS):
Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5,
Microsoft SQL Server 7, or Microsoft SQL Server 2000.

Oracle - DevTest supports Oracle 7.3, 8, and 9i.
The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS.
Checking Database Integrity
System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation.
This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade.
For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data.
System administrators do not need to check database integrity when they initially install DevTest.
To check database integrity:
1Select System System Integrity Check in the menu bar. The System Integrity Check dialog box appears.
2Click the Start button.
Setting DevTest System Compatibility
To define DevTest system compatibility:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field
are denied access, and prompted to upgrade their client.
Defining Memo Field Size Limits
In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields.
Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments.
By default, the memo fields in a DevTest site are limited to 10K bytes.
To define memo field size limits:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select an option in the Maximum memo field size dropdown list
Defining Name Display Formats
To define the format of names in a site:
1Select System System Settings General Settings in the menu bar. The General Settings window appears.
2Select a display option.
To display project team member names using the format First Name Last Name select the First_Name Last_Name option.

To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option.
3.3 Administering DevTest Application Servers
In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site.
The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is
implemented as a Windows NT Service that stores database connection information.
All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database
are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more
information see "Administering System Date and Time Settings."
Defining Application Server Connections
Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server
settings include the system name, the application server name, and the port number.

Figure 3-2: DevTest Application Server Configuration Manager
To define DevTest Application Server configurations:
1Select Start All Programs TechExcel DevTest DevTest Application Server Configure Application Server. The DevTest Application Server Configuration window appears.
2Define the system name, server name, and port number.
Defining DevTest Database Server Connections
In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially
agatekeeperbetween DevTrack application components and the DevTest Database Server.
Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server
machine, the database name, and authentication information.
Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database
Server.

Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager
DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings.
Database Type - DevTest may run on any ODBC-compatible DBMS.

Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs.

Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB
DevTest supports two authentication modes:
SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database.

Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or
group membership. They are not required to enter a password.
3.4 Administering the DevTest Document Server
The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site
knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes
and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add
attachments to project work items.
Configuring DevTest Document Server Settings
Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge items
stored in the knowledge base.
To define the DevTest Document Server connection:
1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears.
2Input the server name and port number of the DevTest Document Server.
Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs.

Port Number - Defines the port number used by the DevTest Document Server.
3 Optional: To test the connection to the DevTest Database Server, click the Connect button
Defining the Document Root and Document Revision Directories
The DevTest Document Server organizes and stores all files and manages version control.
The repository may manage up to five versions of each file.
The repository is organized into two directories: the document root directory and the document revision directory.
Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server.

Document Revision Directory - Stores previous versions of the files stored in the document root directory.
The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the
Document Server Configuration tool in the Windows Start menu.
To change the document root directory and document revision directory:
1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window
appears.
2 Optional: To edit the document root directory, update the path in the Document Root Directory text box.
3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box.
4Click the OK button. The Document Server Configuration window closes and the changes are saved.
Configuring Document Server Settings
The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document
Server Manager.
All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to
manage project documentation in a knowledge project.
Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest
projects.
Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply
to every project in a DevTest implementation.
Administrators must define two document server properties:
The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides.
The Port Number represents the port number used by the document server. The default port number is 8229.
To configure Document Server properties:
1Select System Document Server. The Document Server Setting dialog box appears.
2Enter a name in the Server Name field.
3Enter a port number in the Port Number field.
4Click the OK button.
3.5 Administering System Date and Time Settings
DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to
every project in the site or designated as default settings which may be overridden at the project or user-level.
All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are
using the same time clock standard.
Administering Standard System Time Zones
DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone.
The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level.
To define a standard time zone:
To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder.
To define a standard time zone rule:
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder.
To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page.
The Time Zone area displays four mutually exclusive options:
Default - The standard time zone corresponds to the default time zone of the application server machine.

System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients.
Defining System Date Formats
To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13
date formats:
M/d/yy MM/dd/yyyy
yy/MM/dd yyyy/MM/dd
yyyy-MM-dd dd-MMM-yy
dd/MMM/yyyy dd/MM/yy
dd/MM/yyyy dd.MM.yy
dd.MM.yyyy dd-MM-yy
dd-MM-yyyy

Defining System Time Formats
To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder.
The Time Format dropdown list displays four date formats:
h:mm:ss am/pm hh:mm:ss am/pm
H:mm:ss HH:mm:ss

Administering Date and Time Privileges
To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page.
The Date/Time Format area displays three mutually exclusive options:
System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone.

Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time
zone.

User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients.
Displaying Date and Times in Reports
To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box.
Defining Project Date and Time Settings
DevTest enables testing organizations to define standard date and time settings and formatting at the system-level.
A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-
level. All DevTest clients connect to the DevTest Application Server to get the current date and time.
Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager
to define all project date and time zone settings.

Figure 3-4: System Time/Date Manager
3.6 Administering System Messages and Help
The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest
user in every project in the system.
DevTest Admin enables administrators to create two types of system messages:
System Welcome Messages
System Warning Messages
Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically
overrides the welcome message and appears in the login screen for the duration of its broadcast period.
Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications.
DevTest Client System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In the DevTest client, system messages appear on the Select Project to Login dialog box.
DevTest Web System Messages
System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project
selection page, the first screen the user sees when he or she logs into DevTest.
In DevTest Web, system messages appear on the home page.
System administrators can format DevTest Web welcome messages using standard HTML markup tags.
Defining System Welcome Messages
DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users.
DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome
messages using standard HTML markup tags.
To define DevTest welcome messages:
1Select System System Message System Welcome.
The System Message dialog box appears.
2Enter a message in the Message for DevTest Web (in HTML) text area.
3Enter a message in the Message for DevTest Client (in TEXT) text area.
Administrators may format the message using standard HTML markup tags.
4Click the OK button.
Defining System Warning Messages
The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users.
System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest
Web users for the duration of the broadcast period defined by the system administrator.
During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message
returns to the page.
To define DevTest system warning messages:
1Select System System Message System Warning The System Warning dialog box appears.

- Enter a message in the Message for DevTest Web (in HTML) text area.
- Enter a message in the Message for DevTest Web (in Text) text area.
2Select the Display message at project selection page checkbox.
3Choose the beginning time and date in the Date/Time From [control].
4Choose the ending time and date in the Date/Time To [control].
5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox.
All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest
client for the duration of the outage.
6Choose the beginning time and date in the Date/Time From [control].
7Choose the ending time and date in the Date/Time To [control].
8Click the OK button.
Administering User Sessions
System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance.
DevTest Admin provides system administrators with two methods for managing user sessions:
- Automatically log all users off the system using tools in the Warning System Message Manager -
- Manually log users off the system using the Login Manager.
Configuring Online Help Settings
Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system.

Figure 3-5: Online Help Settings Manager
Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL.
Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally.
To configure online help settings:
1Select System Online Help Setup. The Online Help Setting dialog box appears.
2Enter the URL for the online help system in the Client Help Path field.
3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided.
4Enter the URL for the DevTest Admin online help system in the Admin Help Path field.
5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided.
6Click the OK button.
3.7 Administering DevTest Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
DevTest provides three different types of reports:
The User Information Report displays detailed information about DevTrack users in a printable format.

The Project Information Report displays detailed information about DevTrack projects in a printable format.

The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format.
Viewing Admin Reports
Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system.
To view Admin reports:
1Select Tool Admin Report.
The Admin Report submenu appears.
2Select an option from the Admin Report submenu.
The report window appears.
3To switch between reports, you can select a report type from the Project Selection dropdown list.
4To print the report, select the Print button.
Understanding the User Information Report
The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID.
The User Information Report shows detailed information for project member:
Full Name License type Work phone

E-mail address Address Status
Privilege Home Phone
Understanding the Project Information Report
The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a
detailed report about five project-specific areas:
Project Overview - This area shows the project name, project status, project ID, starting number, and project description.

Project Administrator - This area lists all project administrators for the project.

Account Type Privileges - This area shows the account type members and privileges for each account type.

Groups - This area shows all project members by project group.

Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder.
3.8 Administering DevTest Web
The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser.
Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest
Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database.
DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings
and system runtime keys.
Defining the DevTest Web Server Path
To define DevTest Web Server paths:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter the DevTest project URL in the DevTest Web Server Path field.
3 Optional: To test the connection, click the Connection Test button.
4Click the OK button.
Defining DevTest Web Login Titles and Messages
To define DevTest web server paths:
1Select Tool Web Support General Setting.
The Web Support manager appears.
2Enter the title for DevTest Web in the Web Login Title field.
3Enter a message in the Web Login Message in HTML field.
4Click the OK button.
Defining DevTest Web Logout URLs
In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project.
By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project.
If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web
Logout URL abrogates this error.
To define a DevTest Web logout URL:
1Select Tool Web Setup.
The Web Setup window appears.
2Enter a URL in the Web Logout URL text box.
3To test the logout URL, click the Test Connection button.
4Click the OK button.
The Web Setup window closes.
Managing DevTest Web Idle Time-out Settings
In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be
automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period.
Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out
setting is 15 minutes.
System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users
are not logged out of DevTrack projects.
To define DevTest Web idle time-out settings:
1Select Tools Web Setup. The Web Setup window appears.
2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box..
0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site.

15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle
timeout setting is 15.

Defining DevTest Web Authentication Preferences
DevTest Web supports Windows NT authentication.
System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating.
DevTest Login and Password
Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently
logged into their machine) to access DevTest projects through DevTest Web.
If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web.
Users are automatically logged into the project for all future sessions.
System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication.
To define DevTest Web authentication preferences:
1Select Tool Web Authentication.
The Web Authentication dialog box appears.
2Select an authentication method for the DevTest Web client.
To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button.

To enable Windows NT authentication, select the Windows NT Authentication option button.
3Click the OK button. The Web Authentication dialog box closes.
Configuring the DevSuite Web Server
The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection.
Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and
the DevTest Application Server and the DevTest Database Server.

Figure 3-6: DevTest Web Server Configurational
Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated
using controls in the DevTest Web Server Configuration window.
Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in
DevTest Admin.
To configure DevTest Web Server:
1Select Start All Programs TechExcel DevTest Configure DevTest Web.
The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration
window appears.
2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number.
3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path.
4Define the authentication method.
To use Windows NT authentication, select the Windows NT Authentication option button.

To use SQL Server authentication, select the SQL Server Authentication option button.
5Click the OK button.
Starting and Stopping the DevTest Web Server
In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all
changes are properly displayed, system administrators must stop and restart the DevTest Web Server.
To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client.
Administering Multiple DevTest Web Servers
Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)
lack of bandwidth at remote or home offices.
TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load
across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks.

Figure 3-7: Regional DevTest Web Server
Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is
guaranteed between the database server and the regional web server, data transfer is constant and rapid.
If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance.
Install a regional web server if:
- A centralized web server is geographically distant from some offices
- Clients must connect from various local offices within a single region
- At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server
Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and
designate the primary DevTest Web Server.

Figure 3-8: Multiple Web Server Support Page
In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central
DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access
bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good
performance, a remote user with a may actually experience faster performance by accessing the central web server.
To define connections to multiple DevTest Web Servers:
1Select System Multiple Web Server Support.
The Multiple Web Server Setting window appears.
2Click the Add New button.
The Add Web Server dialog box appears.
3Define the host name and IP address of the machine running the DevTest Web Server.
4Click the OK button. The Add Web Server dialog box closes.
3.9 Administering DevSuite Integration
Enabling and Defining DevSuite Integration

DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.

To enable and define DevSuite integration:

1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Click the Change button.
3Select the Enable DevSuite Integration check box.
4Select a DevSuite site in the DevSuite dropdown list.
5Input the DevSuite Web Service URL in the Admin Web Service URL text box.
Enabling and Defining KnowledgeWise and DevSpec Integration
To enable DevSuite integration:
1Select System DevSuite Integration in the menu bar.
The DevSuite Integration window appears.
2Select the Enable KnowledgeWise Integration check box.
3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box.
4Input the DevSpec web service URL in the DevSpec Web Service URL text box.
3.10 Administering Multiple Sites
A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in
DevTest site shares a common database and other system-level configurations.

In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses.

Figure 3-9: DevTest Site Family and Stand-Alone Site

QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in
any project in the site family.
Master Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable
work sites to join the site family.
Work Site A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any
number of DevTest projects, knowledge projects, template base projects, and work projects.
Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations.
DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any
project in the site family.
Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project
belonging to other DevTest sites.

Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the
maximum number of users is exceeded.Fixed
FixedA Administering a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites.
To define a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Create a New Multiple Site Family button.
A confirmation dialog box appears.
3Click the Yes button.
The confirmation dialog box closes.
The Create a Site Family dialog box appears.
4Input the name of the site in the Site Name edit box.
5Input the site family web service URL in the Site Web Service URL edit box.
6Click the OK button.
The Create a Site Family dialog box closes.
The site is displayed in the Site Family list of the Site Settings page.
To add a work site to a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Add button in the Site Settings window.
The Add a Regular Work Site dialog box appears.
3Enter the name of the work site in the Site field.
4Enter the URL for the site? DevTest Web in the Web Server URL.
5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family.
7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To edit work site settings:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Select a work site in the Site Family list of the Site Settings page.
3Click the Edit button in the Site Settings manager.
The Edit a Regular Work Site dialog box appears.
4Enter the name of the work site in the Site field.
5Enter the URL for the site? DevTest Web in the Web Server URL.
6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric
authentication key.
7Write down the authentication code.
The authentication code is required for the work site to join the site family.

8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page.
To allocate floating licenses to work sites:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Allocate Site Licenses button.
The Multiple Site License Allocation dialog box appears.
3Select a site in the site list.
The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site.
Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master
site.
4Click the Edit button.
The Update Floating License dialog box appears.
5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box.
6Click the OK button.
The Update Floating License dialog box closes.
Administering a Standalone Site
In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally.
To define a standalone site:
By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family.
To change a master site or work site into a standalone site:
System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system
master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site.
Joining a Site Family
In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of
DevSuite licenses.
Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family.

Figure 3-10: Join Multi Site Family Wizard
DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family.
To join a site family:
1Select System Multi Site Family.
The Multiple Site Settings window appears.
2Click the Join Site Family button.
The Join Multi Site Family wizard (Page 1) appears.
3Input the name of the site family in the Site Name text box.
4Input the site family web service URL in the Web Service URL text box.
5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site
administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family.
6 Optional: To test the connection to the site family web service.
The Join Multi Site Family wizard (Page 2) appears.
7 Optional: To identify new users, select the check box next to the user name in the user list.
The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site.
8Click the Next button.
The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the
project. .
9Click the Next button.
The Join Multi Site Family wizard (Page 4) appears.
10Click the Start button.
The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done
11Click the Next button.
The Join Multi Site Family wizard (Page 5) appears.
12Click the Start button.
The wizard adds the current project to the selected site family.
13Click the Finish button.
Administering Standard Lookup Fields
In DevTest, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevTest site.
Each standard lookup field defines a set of field values, which may potentially define that field in the project. In the DevTest clients, the field is represented by a multiple selection control
(such as a dropdown list) and the field values are displayed as options within that control.
Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values.
A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description.
Field Name The field name enables project administrators to identify the field in each project.
Field Description The field provides project administrators with information about the data tracked in the field.
Chapter 4 System Level User Administration
4 Chapter 4- System Level User Administration
Wiki Summary.
4.1 Understanding System-Level User Administration
System-level user administrative tasks include license management and allocation, user account creation and definition, the management of system and project administrators, user
licenses, logins, and sessions.
User Licenses
User Accounts
LDAP Directory Servers
User Logins
Administrator Account Type

4.2 Administering User Licenses
TechExcel offers many different varieties licenses to testing organizations that purchase DevTest software, and the licenses purchased by these test management organizations determine
the features available within the DevTest implementation.
4.3 Administering User Accounts
In DevTest, every user account is defined by a unique login ID, password, user profile, and contact information?sually a phone number and email account.
All work projects in a DevTest site share a common group of licensed users that may belong to multiple projects?nowledge, template, and work. A user account may be assigned a different
account type in each project.
The DevTest Admin User Manager is the primary tool for managing and tracking user contact information, account types, project membership, administrative privileges, and licensing
information.
Creating User Accounts
In DevTest, a user account identifies a user that may access and work in a DevTest project. Every project in a DevTest site share a common set of user accounts.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevTest project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?on page 107.
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members.
Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Is System Administrator The Is System Administrator property defines whether a user account has system-level administrative privileges.
Is Project Administrator The Is Project Administrator property defines whether a user account has project-level administrative privileges.
Is Active DevTest User The Is Active DevTest User property defines whether a user account is active and may be added to DevTest projects.
To create a user account:
1Click the User Manager button in the tool bar.
The User Manager appears.

2Click the New button.

The User Information dialog box appears.

3Define basic user account properties in the User Information tab.

Basic user account properties include:

User Name Password First Name
Last Name Phone (W) Phone (H)
Date/Time Format Address E-mail
Memo
For more information see See ?efining Basic User Account Settings?
4 Optional:To designate the user as a project or system administrator, select the appropriate check box in the Is Administrator area of the User Manager.

For more information see See ?esignating Users as Administrators?
5 Optional:To assign a license to the user, select the check box in the License Information area of the User Manager.

A user account must be assigned a license to access a project. For more information see See ?ssigning Licenses to User Accounts?
6 Optional:Define pager and mobile phone account settings in the Advanced tab.
?Mobile phone account settings define contact information that enables users to be contacted by mobile phone. For more information see See ?efining Mobile Phone Account Services?
?Pager account settings define contact information that enables users to be contacted by pager or PDA. For more information see See ?efining Pager or PDA Account Services?
7Click the OK button.

The user account is displayed in the User Manager list.
Defining Basic User Account Settings
The User Information page enables system administrators to define the user account properties for new and existing DevTest user accounts.
The User Information page consists of two tabs: the User Information tab and the Advanced tab.
?The User Information tab displays basic user account properties including their name, e-mail, and status in the DevTest implementation.
?The Advanced tab displays controls that enable the administrator to define a user? pager and mobile phone numbers and addresses.
The basic user account properties displayed in the User Information tab include:
User Name The User Name property represents the name that the project member uses to log into the application.
First Name The First Name property stores the first name of project members.
Last Name The Last Name property stores the last name of project members.
Password The Password property stores the password that project members use to log into the DevSpec project.
Auto Login Account The Auto Login Account field stores the NT username that a project member may use to log into projects through DevTest Web.

The auto login account is only used if the system administrator has enabled Windows NT Authentication in the DevTest site. For more information see See ?
onfiguring Windows NT Authentication?
Phone (W) The Phone (W) property may be used to store the work phone number of project members.
Phone (H) The Phone (H) property may be used to store the work phone number of project members.
E-mail The E-mail property may be used to store the e-mail address of project members. Address The Address property may be used to store the mailing address of project members.
Memo The Memo property may store short notes about project members.
Assigning Licenses to User Accounts
Using controls in the License Information tab of the User Manager, system administrators may assign appropriate licenses to user accounts and designate those user accounts as active
members of DevTest projects.
The License Information tab displays shows whether a user account is an active DevTest user, the license type assigned to that user (fixed or floating), and shows the projects that the user
may access based on the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest work projects based on the license
assigned.
Is Active KnowledgeWise User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more KnowledgeWise work projects based on
the license assigned.
Is Active DevTest User The Is Active DevTest User property indicates whether the user may be added as a project member of one or more DevTest projects based on the license assigned.
Designating Users as Administrators
In DevTest, an administrator is a user that is responsible for configuring, managing, or maintaining a site or project. DevTest supports three types of administrators: system administrators,
division administrators, and projects.
System Administrator A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings.
Division Administrator A division administrator is responsible for configuring, customizing, and managing multiple work projects.
Project Administrator A project administrator is responsible for configuring, customizing, and managing a work project.
System administrators may designate user accounts as system or project administrators whenever they create or edit a user account
To designate a user as an administrator:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.
3Click the Edit button.
4Assign administrative privileges to the user account.
?To designate the user a system administrator, select the Is System Administrator check box.

?To designate the user a division administrator, select the Is Division Administrator check box.

?To designate the user a project administrator, select the Is Project Administrator check box.
Defining Pager or PDA Account Services
Pager account settings define contact information that enables users to be contacted by pager or PDA (personal handheld device).

If pager or PDA phone account information is recorded in the User Manager, project members may receive notifications through their page or PDA based on e-mail notification or e-mail
escalation rule is triggered.

Pager and PDA account properties include:
Defining Mobile Phone Account Services
Mobile phone account settings define contact information that enables users to be contacted by mobile phone.

If mobile phone account information is recorded in the User Manager, project members may receive notifications through their mobile phone whenever an e-mail notification or e-mail
escalation rule is triggered.

Mobile phone account properties include:
Editing User Accounts

Administrators may use the Edit button in the User Manager to edit user accounts from DevTest projects.

Administrators may update all user account properties using controls in the User Information dialog box.
To delete a user account:

1Click the User Manager button in the tool bar.
The User Manager appears.

2Select the user account in the User Manager list.

3Click the Edit button.

The User Information dialog box appears.

4Define user account properties for the user account.

5Click the OK button.
Deleting User Accounts
Administrators may use the Delete button in the User Manager to delete user accounts from DevTest projects.

User accounts may be deleted only if they are not currently a member of any DevTest project. For step-by-step instructions on removing a user account from a project see See ?efining User
Profiles?
To delete a user account:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select the user account in the User Manager list.

3Click the Delete button.

The warning dialog box appears.

4Click the OK button.
Defining User ProfilesIn DevTest, a user profile identifies the projects that a user account may access in a DevTest site, the account types and groups assigned a user account in each
project, and, in DevTest projects, the state-based workflow access rights.

The User Profile page of the User Manager enables system administrators to assign an account type, group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.
Account Type The Account Type tab enables administrators to define project membership and account types for a user account in multiple DevTest projects.
Group Membership The Group Member tab enables administrators to define group membership for a user account in multiple DevTest projects.
Workflow The Workflow tab enables administrators to define the user account as an applicable owner in various issue states in multiple DevTest projects.
To assign an account type:
1Select the user account in the User Manager list.
2Click the Profile button.
The User Profile page appears.
3Select the Account Type tab.
4Select a project in the Project list.
5To make the user account a project member select the Is a Project Member check box.
6To assign an account type select an option from the Account Type dropdown list.
To define group membership:
1Select the user account in the User Manager list.
2Click the Profile button.

The User Profile page appears.
3Select the Group Member tab.
4Select one or more groups in the Group list.

The project member is added to a group if a black check mark appears in the check box next to the group name.
To define workflow ownership rules:
1Select the user account in the User Manager list.
2Click the Profile button
The User Profile page appears.
3Select the Workflow tab.
4Select workflow states in theWorkflowStatelist.
The project member may be an applicable owner of an issue in each workflow state if a black check mark appears in the check box next to the name of the workflow state.
Merging User Accounts
Administrators may use the Merge button in the User Manager to merge multiple user accounts into a single user account.
Administrators may use the merge command to clean up duplicate or invalid user accounts or to transfer tasks that belong to a user account to another user account.
User accounts can easily be duplicated whenever an administrator imports user attributes from a structured text file. The merge command enables administrators to merge duplicate
accounts into a pre-existing account without losing data.
In cases where a new employee replaces a previous project member, administrators may merge the old DevTest user account attributes into the newer user account.
To merge user accounts:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list. Hold the CTRL or SHIFT keys to select multiple users. Administrators may merge any number of user accounts.
3Click the Merge button.

The Merge dialog box appears.
4Select the user account into which all of the data for the other selected users is to merge in the Merge to dropdown list.
5Click the OK button.

The DevTest Admin dialog appears.
6Click the Yes button.
Importing User Accounts from a Structured Text File
Administrators may use the Import button to import user account attributes from a structured text file or from LDAP.
Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.
Field Delimiter The field delimiter defines the beginning and end of each field imported. Administrators may between five different delimiters: The pipe character (|) usually gets the best
results.
Text Qualifier Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text
qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the
default text qualifier is the double quotation mark (?.
The Import wizard enables administrators to quickly create multiple user accounts.
To import user account attributes:
1Click the User Manager button in the tool bar. The User Manager appears.
2Click the Import button. The Select a User Import Source dialog box appears.
3Select the Import from an External File option. The File and Format dialog box appears.
4In the User Information field locate the file that contains the data you want to import.
5Select a field delimiter from the Field Delimiter dropdown list. The fields delimiter defines the beginning and end of each field you import. You can choose five different delimiters:

# , ; {tab} |
6Enter a text delimiter in the Text Delimiter field.
7 Optional: To exclude Field names from the first row, select the Field names on the first row check box.
8Select the Next button.

The Mapping User Fields dialog box appears.
9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.
10Click the Next button.

The Import page appears.
11Select all appropriate options in the Import dialog box.
?To overwrite duplicate records, select the Overwrite check box.
?To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. Administrators may define where DevTest saves the
test file by selecting the Browse button.
12Click the Finish button.
Viewing User Information Reports
Administrators may use the Report button in the User Manager to view user information reports.
User information reports provide the administrator with detailed information about all user accounts:
Administrators may filter the user account displayed in the User Information report based on their current status. The report may display all users, all active users, or all inactive users.
Administrators may use the Print button to print out copies of the User Information report.
Emailing DevTest Installer to Users
Administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the DevTest client installation program.
Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the DevTest installation program available to
future DevTest project members.
To e-mail the client installation program:
1Click the User Manager button in the tool bar.

The User Manager appears.
2Select a user account in the User Manager list.
3Click the E-mail the Selected Users for Client Installation button.

The E-mail client appears. The e-mail is automatically addressed to the selected user account.
4.4 Administering LDAP Directory Server Integration
DevTest-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory
server rather than in individual DevTest projects or sites and use data managed in the directory server to authenticate users when they log into
DevTest projects.
LDAP authentication removes the burden of password storage from the DevTest system and places in the realm of the directory server. This allows a
single source of password generation and maintenance. Once an administrators has enabled the LDAP integration data, any logins to the DevTest
client are automatically forwarded to the LDAP directory for authentication.
Using controls in the LDAP Integration dialog box, system administrators may identify directory server integration settings and LDAP authentication
settings for a DevTest implementation.

IMAGE
To connect to the directory server the administrator must define the appropriatehost name,port name,distinguished nameandpassword,search filter,
andattribute name.

Server Name The Server Name is a name that identifies the registered LDAP server in the DevTest system.

DirectoryServerPort A port number is a specific number that is used to map data to a particular process running on a computer. In a DevTest-
directory server integration, the a port number identifies the channel over which data is communicated between the DevTest and
the directory server. For example, port 389.

Domain Connection String A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in
the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name
components(DC). For example, CN=users,DC=mydomain,DC=com
The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the
corresponding password.

Once the system administrator has integrated the DevTest site with their directory servers they may use LDAP to manage user accounts and logins:
?System administrators may import user data from an LDAP server into a DevTest site.
?System administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is used authenticate
users logging into projects using DevTest Windows and Web clients.
Note:One limitation of this implementation is that DevTest uses its own security model based on user account type settings. Because of the
differences in LDAP directories, DevTest cannot map account type properties to an LDAP login without the same login existing in DevTest.
To configure LDAP integration:
1Select System System Settings LDAP Integration.

The LDAP Integration for Windows Client dialog box appears.
2Select the Enable LDAP Integration check box.
3Select an LDAP authentication option:
?To enable LDAP authentication for both DevTest Windows client and DevTest Web client, select the Client and Web option button.
?To enable LDAP authentication for the DevTest Windows client only, select the Client Only option button.
4Enter the name of the LDAP server in the LDAP Server Name field.
5Enter the TCP port that is used to connect to the server in theDirectoryServerPortfield.
6Enter a connect string that will be appended to the LDAP connection in the Domain Connect String field.
7To test the connection to the directory server, click the LDAP Server Connection Test button.
8Click the OK button. The LDAP Integration for Windows Client dialog box closes.
4.5 Administering User Logins
The Login Manager displays high-level information the current status and login history of DevTest project members including login names, login and logout times,
machine names, and license types. The Login Manager consists of two tabs: the Login Status tab and the Login History tab.
?The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
?The Login History tab displays high-level information about each user session during an administrator-defined time period.
Viewing the Login Status of Project Members
The Login Status list displays high-level information about the project members that are logged into a project.
The following columns may be displayed in the Login Status list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Time The Login Time column shows the time that the project member logged into the project.
Login Project The Login Project column shows the name of the project.
From Application The Application column shows the client that was used to access the project?eb or Client.
From Machine The Machine column shows the name or IP address of the machine that was used to log into the project.
License Type The License Type column shows the type of license that is assigned to the project member.
Last Active Time
Lockup Time
List columns may be added or removed from Login Status list.
To view the login status for DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
The Login Status tab displays high-level information about the user accounts logged into each DevTest project.
3Select a project from the Project dropdown list.

The Login Status list displays information about every project member that is currently logged into the selected project.
Logging Off DevSpec Users
Administrators may use the Login Manager to log project members off of DevSpec projects.
Once the system administrator logs a user off the DevSpec system, the user has five minutes to log off. A warning message appears in the screen of the client
reminding users to save their work.
To log users off of DevSpec projects:
1Open the Login Manager.
The Login Manager command may be invoked by two methods:
?Select the Login Manager command in the Tool menu.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.3Select a project from the Project dropdown list.
4Click the Log Off button.
5Click the OK button.
Managing DevTest Idle Timeout Settings
In DevTest, administrator-defined timeout settings control access to projects and manage the distribution of floating licenses to project team members. DevTest
client users may be automatically logged out of DevTest projects if they remain inactive for a period that exceeds the idle timeout period.
Idle timeout settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The
minimum idle timeout setting is 15 minutes.
System administrators may disable DevTest idle timeout controls by entering 0 in the the Idle Timeout control of the Login Manager. If zero 0 is entered in the Idle
Timeout control, idle users are not logged out of DevTest projects.
1Open the Login Manager. The Login Manager command may be opened by two methods:
?Select the Login Manager page in the User & License Management folder of the tree panel.
?Click the Login Manager button in the tool bar.

The Login Manager appears.
2Select the Login Status tab.
3Enter 0 or a number greater than 15 in the Idle Timeout to Log Off the Client (in Minutes) field.
0 If zero is entered, DevTest idle timeout controls are disable in the DevTest site.
15 If a number is entered, the DevTest idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The
minimum idle timeout setting is 15.
Refreshing Login Lists
To refresh the data displayed in the Login Status list or the Login History list of the Login Manager, click the Refresh button.
Viewing Login History Logs
The Login History list displays high-level information about the past DevTest sessions of project members.
The following columns may be displayed in the Login History list of the Login Manager.
Login Name The Login Name column shows the name of the project member that is logged into the project.
Login Status The Login Status column shows if project members are currently logged into the project.
Login Time The Login Time column shows the time that the project member last logged into the project.