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?I>if 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
In DevTest, a project is a tool for storing, organizing, and managing testing and QA processes. Every DevTest implementation, called aDevTest site, consists of a knowledge base project, a test template project, and a work project.
DevTest enables project teams to create three different types of projects. Each project type provides users with the views and tools that a project team may use to manage an aspect of the testing process.
Knowledge Project Knowledge projects enable project teams to collect and manage information gathered across multiple template projects and work projects. Knowledge project members may manage knowledge items in the knowledge project. When integrating DevTest with a DevSuite master site administrators can link the DevTest Knowledge Project to the appropriate KnowledgeWise project in the DevSuite system.
Template Project Template projects enable project teams to create and manage test templates that may used to create test tasks in multiple work projects. Template project members may manage test templates in a template project.
Work Project Work projects enable project teams to plan and execute test cycles using test tasks that have been generated from test templates created in a parent test template project. Work project members may manage test tasks in the work project.
Every DevTest implementationmustconsist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical. A knowledge project is the parent of one or more child template projects. Each template project is the parent to one or more child work projects. Every work project is the child of one template project.
The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects.
Creating DevTest Projects
The New Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects.
Using controls in the New Project window, system administrators may create new live and sample projects.
|
Most system-level project settings cannot be edited once defined. The project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings. For more information see See editing DevTest Project Settings.
Project definition settings define the project type and the parent project in the DevTest system. These settings enable the DevTest system to integrate records created in the new project with other DevTest projects.
Most system-level project properties are permanent. Once an administrator has created a project the project type, project base, and knowledge base definitions for that project cannot be changed. Administrators may edit the project name, project identifier, and the project description settings.
Project-definition settings are defined by system administrators when they create a project in DevTest. Those project-definition settings that are editable can be changed by project administrators in the Project Settings Overview page.
Project Name The Project Name property enables administrators to define the name of the project.
Project Identifier The Project Identifier property enables administrators to define a prefix that is added to each issue created in the project. This identifier may be used to identify issues associated with a particular project.The project identifier prefix may include alphabetical or numeric characters.
Project Type The Project Type property enables administrators to define the project type. Once set this propertycannotbe changed. Every DevTest project is one of three types of projects: template base, work, or knowledge base.
Template Base The Template Base property enables administrators to define the project template base. Once set this propertycannotbe changed. Every project belongs to a template base.
Knowledge Base The Knowledge Base property enables administrators to define the project knowledge base. Once set this propertycannotbe changed.
Description The Description property enables administrators to define a general description of the current project.
ID Prefix The ID Prefix property enables administrators to define a numerical or character prefix to each issue ID. This feature may be used so that issues associated with a particular project are easier to identify.
ID Starting No. The ID Starting No. property enables administrators to define the initial issue ID number. For example, if an administrators enters 100 in this field, the first issue created will be issue 100.
Active Project The Active Project property enables administrators to define the status of the project: a project must be active before users may access it. A project must be inactive before the system administrator can delete it.
Name Display Format The Name Display Format property enables administrators to define how the project displays the names of project members. Names are displayed either first name, last name or last name, first name.
Date/Time Format The Date/Time Format property enables administrators to define the project? time zone and date settings. If the system-level time zone definition is selected, the Date/Time Format dialog box is disabled. For more information, see?dministering System Date and Time Settings?
System administrators need not define every project from scratch. Administrators may import system-level project settings from previously created projects whenever they create a new DevTest project. For more information see See ?mporting Project Definition Properties?
When creating DevTest projects administrators may create projects from scratch or they may import project properties from existing projects, sample projects, or project templates.
Creating Knowledge Projects
To create a new knowledge project:
1Select File > New Project.
The New Project manager appears.
2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ : ? ?< > |.
3Define the project as a live project or sample project.
?To define the project as a sample project, select the Sample Project option button.
?To define the project as a live project, select the Live Project option button.
4Enter a project identifier in the Project Identifier field.
The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project.
5Select the Knowledgebase Base Project option Project Type dropdown list.
The Project Type dropdown list displays three options: knowledge, template, and work.
6 Optional: To copy project settings from an existing knowledge project, select that project in the list.
7Click the Next button. The Available Project Settings page appears.
8Select one or more of the project-level settings defined in the selected knowledge project.
The following knowledge project settings may be copied from existing knowledge projects.
Project Administrators Knowledge Folder Information
Knowledge Folder Access Knowledge GUI Fields
9Click the Finish button.
Creating Template Projects
To create a new template project:
1Select File > New Project.
The New Project manager appears.
2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ : ? ?< > |.
3Define the project as a live project or sample project.
?To define the project as a sample project, select the Sample Project option button.
?To define the project as a live project, select the Live Project option button.
4Enter a project identifier in the Project Identifier field.
The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project.
5Select the Template Base Project option Project Type dropdown list.
The Project Type dropdown list displays three options: knowledge, template, and work.
6Select a knowledge project in the Knowledge Base dropdown list. Every DevTest template project is the child of a single knowledge base project.
7 Optional: To copy project settings from an existing template project, select that project in the list.
8Click the Next button.
The Available Project Settings page appears.
9Select one or more of the project-level settings defined in the selected knowledge project.
The following knowledge project settings may be copied from existing template projects.
Account Types and Privileges Project Members, Groups and Group Folders
Project Environment Variables Verification Point Settings
State and Workflow Settings Template Folder GUI Settings
Template GUI Settings Email Notification Settings
Status Group Settings TestLink Settings
Template Folder Template
10Click the Next button.
The New Project Confirmation page appears.
11Click the Finish button.
Creating Work Projects To create a new work project:
1Select File > New Project.
The New Project manager appears.
2Enter a project title in the Project Name text box.
Avoid using the following characters when naming the project: / \ : ? ?< > |.
3Define the project as a live project or sample project.
?To define the project as a sample project, select the Sample Project option button.
?To define the project as a live project, select the Live Project option button.
4Enter a project identifier in the Project Identifier field.
The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project.
5Select the Work Project option Project Type dropdown list.
The Project Type dropdown list displays three options: knowledge, template, and work.
6Select a template project in the Template Base dropdown list. Every DevTest work project is the child of a single template base project.
7 Optional: To copy project settings from an existing knowledge project, select that project in the list.
8Click the Next button.
The Available Project Settings page appears.
9Select one or more of the project-level settings defined in the selected knowledge project.
The following knowledge project settings may be copied from existing knowledge projects.
Account Types and Privileges Project Members, Groups and Group Folders
State and Workflow Settings Planning View GUI Settings
Test Task View GUI Settings Email Notification Settings
Status Group Settings DevTrack Integration
10Click the Finish button.
Administering Sample Projects
In DevTest, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment.
Using tools in DevTest Admin, administrators may create sample projects or live projects based on sample projects.
Project administrators may freely configure sample projects to represent their development processes.
?Project configurations and settings tried and tested in sample projects may be imported into newly created ?ive projects?
?Sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes.
Using controls in the DevTest Admin client, administrators may create additional sample or live knowledge base, template, and work projects based on existing projects.
Backing Up DevTest ProjectsDevTest stores backups of DevTrack projects in a proprietary DTT file format. Once the administrator define the project information, the administrator may back up either the entire database or only selected projects. DevTest Admin creates the backup file with the selected project data.
DevTest Admin stores backed up projects in a proprietary DTT file format.
Note:DevTest backups are a good way to save project properties, but cannot be considered a substitute for regular database server backups.
To backup DevTest projects:
1Invoke the Back Up Project command.
?Select File > Back Up Project in the menu bar.
?Press CTRL + B. The Back Up Project dialog box appears.
2Click the Ellipsis button to navigate to the location of the backup file.
The Backup dialog box opens.
3Navigate to the location of the backup files.
4Enter a name for the DTT file in the File Name field.
5Select the DevTrack Backup File (DTT) option in the Save as Type dropdown list.
6Click the Save button.
The Backup dialog box closes.
7Select a back up option:
?Click the Whole Database radio button to backup all projects in a DevTrack implementation.
?Click the Selected Projects radio button to backup some, but not all projects in a DevTrack implementation. Highlight the projects to be backed up.
8 Optional: To identify the project to be backed up, select a project in the project list.
9Projects may be selected only if the Selected Projects option is selected.
10Click the OK button.
The site or project is backed up.
Restoring DevTest Projects
DevTest stores backups of DevTest projects in a proprietary DTT file format. Administrators may choose to back up selected projects or the entire database.
When restoring backed up DevTest projects administrators may overwrite existing projects or create new projects based on the backed up projects.
To restore DevTest projects:
1Invoke the Restore command.
?elect File > Restore in the menu bar.
?ress CTRL + R.
The Restore Project dialog box appears.
2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format.
3Click the Open button.
The DevTest Restore II dialog box appears. The dialog box displays the Project ID number of the project to be restored.
4Select the Overwrite radio button in the Options area.
5Click the OK button.
The project is restored. If the DTK file selected contains multiple backed up, the DevTest Restore II dialog box appears for each backed up project.
Creating Projects Based from Backed Up Projects
Whenever an administrator backs up a DevTest project, DevTest saves a copy of that project in a proprietary DTT file format.
Administrators may create a new DevTest project from DTK files.
To create a new project from a backed up project:
1Invoke the Restore command.
?elect File > Restore in the menu bar.
?ress CTRL + R.
The Restore Project dialog box appears.
2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format.
3Click the Open button.
The DevTest Restore II dialog box appears.
4Select the Create New project radio button in the Options area.
5Enter a title in the New Project Name field.
6Click the OK button.
The new project is created and the Open Project dialog box appears.
Understanding Active and Inactive Projects
Every DevTest project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project.
Administrators define the status of a project by selecting the Active Project check box in the Overview page.
Active Projects
Administrators may perform the following tasks using active DevTest projects:
?Administrators may open active projects in DevTest Admin and configure project settings.
?Administrators may use the User Manager to add user accounts as project members to active projects.
?Administrators may import project properties from Active projects.
Inactive Projects
Administrators may perform the following tasks using inactive DevTest projects:
?Inactive DevTest projects may be deleted using the Delete Project command. Active projects cannot be deleted.
Deleting DevTest Projects
System administrators may use the Delete command to delete inactive DevTest projects.
Administrators may only delete projects that have an inactive status. For instructions on making a project inactive see ?nderstanding Active and Inactive Projects?
Note:Deleting a project from the system is permanent. Administrators must perform all appropriate back ups before deleting a project.
To delete a project:
1Select File > Delete.
2The Delete Project dialog box appears.
The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted.
3Select a project.
4Click the Delete button.
Understanding Keyboard Shortcuts
Keyboard shortcuts are combinations of keystrokes that perform predefined functions. Keyboard shortcuts consist of a modifier key and a hot key:
CTRL + X Cut
CTRL + C Copy
CTRL + V Paste
CTRL + N New Project
CTRL + O Open Project
CTRL + S Close Project
CTRL + B Backup Project
CTRL + R Restore Project
CTRL + D Delete Project
All projects in a DevTest site are organized into a hierarchical structure that defines the relationships between the projects in a DevTest site.
Editing DevTest Project Settings
System administrators may use the Project Settings page to update a limited number of project properties.
Most system-level project settings cannot be edited once defined. The project project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings.
To edit DevTest project settings:
1Select Project Settings > Overview.
The Project Settings page appears.
2Enter a name in the Name field
3Enter an identifier in the Project Identifier field.
4Enter a brief description in the Description text field.
Administering Project Login TipsIn DevTest, the project tip window is an administrator-defined message that is displayed in the client workspace when a user logs into a DevTest project. The window is designed to enable project administrators to provide project team members with information or links to information that will enable them to begin working in a project.
The project tips window is fully customizable on a project-by-project basis. Using controls in the Admin client, project administrators may define both the content and format of the project tip.
To define a project login tip:
1Select Project Settings > Project Login Tip in the tree panel.
2Input the title of the project login tip in the Title text box.
3Define and format the project login tip.
?To define or edit the project login tip using a wysiwyg editor, click the Edit button.
?To define or edit the project login tip using HTML markup tags, click the Edit Source button.
To enable project login tip preferences:
To enable project team members to define their own project login tip preferences, select the Allow Users To Skip Project Tip Screen check box.
To override project login tip preferences:
To override project team member project login tip preferences, clcik the Reset User Project Tip Preferences button.
If this button is clicked, the project login tip window is displayed in the workspace of every DevTest user the next time they log into the project.
In DevTest, a project is a tool for storing, organizing, and managing testing and QA processes. Every DevTest implementation?alled aDevTest site?onsists of a knowledge base project, a test template project, and a work project.
DevTest enables project teams to create three different types of projects. Each project type provides users with the views and tools that a project team may use to manage an aspect of the testing process.
Knowledge Project Knowledge projects enable project teams to collect and manage information gathered across multiple template projects and work projects. Knowledge project members may manage knowledge items in the knowledge project.
Template Project Template projects enable project teams to create and manage test templates that may used to create test tasks in multiple work projects. Template project members may manage test templates in a template project.
Work Project Work projects enable project teams to plan and execute test cycles using test tasks that have been generated from test templates created in a parent test template project. Work project members may manage test tasks in the work project.
Every DevTest implementationmustconsist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical. A knowledge project is the parent of one or more child template projects. Each template project is the parent to one or more child work projects. Every work project is the child of one template project.
The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects.
In DevTest, a project is a tool for storing, organizing, and managing work items, project knowledge, and testing teams.
A project is a tool for storing, organizing, and managing testing and QA processes. Every DevTest implementation?alled aDevTest site?onsists of a knowledge base project, a test template project, and a work project.
Creating DevTest Projects
The New Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects.
Using controls in the New Project window, system administrators may create new live and sample projects.
|
Most system-level project settings cannot be edited once defined. The project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings. For more information see See ?diting DevTest Project Settings?
Project definition settings define the project type and the parent project in the DevTest system. These settings enable the DevTest system to integrate records created in the new project with other DevTest projects.
Most system-level project properties are permanent. Once an administrator has created a project the project type, project base, and knowledge base definitions for that project cannot be changed. Administrators may edit the project name, project identifier, and the project description settings.
Project-definition settings are defined by system administrators when they create a project in DevTest. Those project-definition settings that are editable can be changed by project administrators in the Project Settings Overview page.
Project Name The Project Name property enables administrators to define the name of the project.
Project Identifier The Project Identifier property enables administrators to define a prefix that is added to each issue created in the project. This identifier may be used to identify issues associated with a particular project.The project identifier prefix may include alphabetical or numeric characters.
Project Type The Project Type property enables administrators to define the project type. Once set this propertycannotbe changed. Every DevTest project is one of three types of projects: template base, work, or knowledge base.
Template Base The Template Base property enables administrators to define the project template base. Once set this propertycannotbe changed. Every project belongs to a template base.
Knowledge Base The Knowledge Base property enables administrators to define the project knowledge base. Once set this propertycannotbe changed.
Description The Description property enables administrators to define a general description of the current project.
ID Prefix The ID Prefix property enables administrators to define a numerical or character prefix to each issue ID. This feature may be used so that issues associated with a particular project are easier to identify.
ID Starting No. The ID Starting No. property enables administrators to define the initial issue ID number. For example, if an administrators enters 100 in this field, the first issue created will be issue 100.
Active Project The Active Project property enables administrators to define the status of the project: a project must be active before users may access it. A project must be inactive before the system administrator can delete it.
Name Display Format The Name Display Format property enables administrators to define how the project displays the names of project members. Names are displayed either first name, last name or last name, first name.
Date/Time Format The Date/Time Format property enables administrators to define the project? time zone and date settings. If the system-level time zone definition is selected, the Date/Time Format dialog box is disabled. For more information, see?dministering System Date and Time Settings?
System administrators need not define every project from scratch. Administrators may import system-level project settings from previously created projects whenever they create a new DevTest project. For more information see See ?mporting Project Definition Properties?
When creating DevTest projects administrators may create projects from scratch or they may import project properties from existing projects, sample projects, or project templates.
Creating Knowledge Projects
To create a new knowledge project:
1Select File > New Project.
The New Project manager appears.
2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ : ? ?|.
3Define the project as a live project or sample project.
?To define the project as a sample project, select the Sample Project option button.
?To define the project as a live project, select the Live Project option button.
4Enter a project identifier in the Project Identifier field.
The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project.
5Select the Knowledgebase Base Project option Project Type dropdown list.
The Project Type dropdown list displays three options: knowledge, template, and work.
6 Optional: To copy project settings from an existing knowledge project, select that project in the list.
7Click the Next button. The Available Project Settings page appears.
8Select one or more of the project-level settings defined in the selected knowledge project.
The following knowledge project settings may be copied from existing knowledge projects.
Project Administrators Knowledge Folder Information
Knowledge Folder Access Knowledge GUI Fields
9Click the Finish button.
Creating Template Projects
To create a new template project:
1Select File > New Project.
The New Project manager appears.
2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ : ? ?|.
3Define the project as a live project or sample project.
?To define the project as a sample project, select the Sample Project option button.
?To define the project as a live project, select the Live Project option button.
4Enter a project identifier in the Project Identifier field.
The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project.
5Select the Template Base Project option Project Type dropdown list.
The Project Type dropdown list displays three options: knowledge, template, and work.
6Select a knowledge project in the Knowledge Base dropdown list. Every DevTest template project is the child of a single knowledge base project.
7 Optional: To copy project settings from an existing template project, select that project in the list.
8Click the Next button.
The Available Project Settings page appears.
9Select one or more of the project-level settings defined in the selected knowledge project.
The following knowledge project settings may be copied from existing template projects.
Account Types and Privileges Project Members, Groups and Group Folders
Project Environment Variables Verification Point Settings
State and Workflow Settings Template Folder GUI Settings
Template GUI Settings Email Notification Settings
Status Group Settings TestLink Settings
Template Folder Template
10Click the Next button.
The New Project Confirmation page appears.
11Click the Finish button.
Creating Work Projects To create a new work project:
1Select File > New Project.
The New Project manager appears.
2Enter a project title in the Project Name text box.
Avoid using the following characters when naming the project: / \ : ? ?|.
3Define the project as a live project or sample project.
?To define the project as a sample project, select the Sample Project option button.
?To define the project as a live project, select the Live Project option button.
4Enter a project identifier in the Project Identifier field.
The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project.
5Select the Work Project option Project Type dropdown list.
The Project Type dropdown list displays three options: knowledge, template, and work.
6Select a template project in the Template Base dropdown list. Every DevTest work project is the child of a single template base project.
7 Optional: To copy project settings from an existing knowledge project, select that project in the list.
8Click the Next button.
The Available Project Settings page appears.
9Select one or more of the project-level settings defined in the selected knowledge project.
The following knowledge project settings may be copied from existing knowledge projects.
Account Types and Privileges Project Members, Groups and Group Folders
State and Workflow Settings Planning View GUI Settings
Test Task View GUI Settings Email Notification Settings
Status Group Settings DevTrack Integration
10Click the Finish button.
Administering Sample Projects
In DevTest, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment.
Using tools in DevTest Admin, administrators may create sample projects or live projects based on sample projects.
Project administrators may freely configure sample projects to represent their development processes.
?Project configurations and settings tried and tested in sample projects may be imported into newly created ?ive projects?
?Sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes.
Using controls in the DevTest Admin client, administrators may create additional sample or live knowledge base, template, and work projects based on existing projects.
Backing Up DevTest ProjectsDevTest stores backups of DevTrack projects in a proprietary DTT file format. Once the administrator define the project information, the administrator may back up either the entire database or only selected projects. DevTest Admin creates the backup file with the selected project data.
DevTest Admin stores backed up projects in a proprietary DTT file format.
Note:DevTest backups are a good way to save project properties, but cannot be considered a substitute for regular database server backups.
To backup DevTest projects:
1Invoke the Back Up Project command.
?Select File > Back Up Project in the menu bar.
?Press CTRL + B. The Back Up Project dialog box appears.
2Click the Ellipsis button to navigate to the location of the backup file.
The Backup dialog box opens.
3Navigate to the location of the backup files.
4Enter a name for the DTT file in the File Name field.
5Select the DevTrack Backup File (DTT) option in the Save as Type dropdown list.
6Click the Save button.
The Backup dialog box closes.
7Select a back up option:
?Click the Whole Database radio button to backup all projects in a DevTrack implementation.
?Click the Selected Projects radio button to backup some, but not all projects in a DevTrack implementation. Highlight the projects to be backed up.
8 Optional: To identify the project to be backed up, select a project in the project list.
9Projects may be selected only if the Selected Projects option is selected.
10Click the OK button.
The site or project is backed up.
Restoring DevTest Projects
DevTest stores backups of DevTest projects in a proprietary DTT file format. Administrators may choose to back up selected projects or the entire database.
When restoring backed up DevTest projects administrators may overwrite existing projects or create new projects based on the backed up projects.
To restore DevTest projects:
1Invoke the Restore command.
?elect File > Restore in the menu bar.
?ress CTRL + R.
The Restore Project dialog box appears.
2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format.
3Click the Open button.
The DevTest Restore II dialog box appears. The dialog box displays the Project ID number of the project to be restored.
4Select the Overwrite radio button in the Options area.
5Click the OK button.
The project is restored. If the DTK file selected contains multiple backed up, the DevTest Restore II dialog box appears for each backed up project.
Creating Projects Based from Backed Up Projects
Whenever an administrator backs up a DevTest project, DevTest saves a copy of that project in a proprietary DTT file format.
Administrators may create a new DevTest project from DTK files.
To create a new project from a backed up project:
1Invoke the Restore command.
?elect File > Restore in the menu bar.
?ress CTRL + R.
The Restore Project dialog box appears.
2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format.
3Click the Open button.
The DevTest Restore II dialog box appears.
4Select the Create New project radio button in the Options area.
5Enter a title in the New Project Name field.
6Click the OK button.
The new project is created and the Open Project dialog box appears.
Understanding Active and Inactive Projects
Every DevTest project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project.
Administrators define the status of a project by selecting the Active Project check box in the Overview page.
Active Projects
Administrators may perform the following tasks using active DevTest projects:
?Administrators may open active projects in DevTest Admin and configure project settings.
?Administrators may use the User Manager to add user accounts as project members to active projects.
?Administrators may import project properties from Active projects.
Inactive Projects
Administrators may perform the following tasks using inactive DevTest projects:
?Inactive DevTest projects may be deleted using the Delete Project command. Active projects cannot be deleted.
Deleting DevTest Projects
System administrators may use the Delete command to delete inactive DevTest projects.
Administrators may only delete projects that have an inactive status. For instructions on making a project inactive see ?nderstanding Active and Inactive Projects?
Note:Deleting a project from the system is permanent. Administrators must perform all appropriate back ups before deleting a project.
To delete a project:
1Select File > Delete.
2The Delete Project dialog box appears.
The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted.
3Select a project.
4Click the Delete button.
Understanding Keyboard Shortcuts
Keyboard shortcuts are combinations of keystrokes that perform predefined functions. Keyboard shortcuts consist of a modifier key and a hot key:
CTRL + X Cut
CTRL + C Copy
CTRL + V Paste
CTRL + N New Project
CTRL + O Open Project
CTRL + S Close Project
CTRL + B Backup Project
CTRL + R Restore Project
CTRL + D Delete Project
All projects in a DevTest site are organized into a hierarchical structure that defines the relationships between the projects in a DevTest site.
Editing DevTest Project Settings
System administrators may use the Project Settings page to update a limited number of project properties.
Most system-level project settings cannot be edited once defined. The project project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings.
To edit DevTest project settings:
1Select Project Settings > Overview.
The Project Settings page appears.
2Enter a name in the Name field
3Enter an identifier in the Project Identifier field.
4Enter a brief description in the Description text field.
Administering Project Login TipsIn DevTest, the project tip window is an administrator-defined message that is displayed in the client workspace when a user logs into a DevTest project. The window is designed to enable project administrators to provide project team members with information or links to information that will enable them to begin working in a project.
The project tips window is fully customizable on a project-by-project basis. Using controls in the Admin client, project administrators may define both the content and format of the project tip.
To define a project login tip:
1Select Project Settings > Project Login Tip in the tree panel.
2Input the title of the project login tip in the Title text box.
3Define and format the project login tip.
?To define or edit the project login tip using a wysiwyg editor, click the Edit button.
?To define or edit the project login tip using HTML markup tags, click the Edit Source button.
To enable project login tip preferences:
To enable project team members to define their own project login tip preferences, select the Allow Users To Skip Project Tip Screen check box.
To override project login tip preferences:
To override project team member project login tip preferences, clcik the Reset User Project Tip Preferences button.
If this button is clicked, the project login tip window is displayed in the workspace of every DevTest user the next time they log into the project.
Work projects enable testing teams to plan and execute test tasks in release cycles and test cycles. The account types that a project administrator creates in a work project represent roles that appropriate to the tasks that must be performed within that project.
The administrator may differentiate between account types by assigning different work project privileges to each account type.
Project administrators may create any number of account types to represent all of the different roles that a project member may perform in the QA process. Work project privileges enable project member to plan and execute test tasks in a work project. A typical testing team for a DevTest work project might include the following account types:
Product Manager QA Lead Engineer Developer
QA Engineer QA Manager
Administering Test Planning Management Privileges
In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Test planning management privileges determine which project team members may create, modify, and delete test folders.
Planning view privileges are generally only assigned to account types responsible for planning or managing test assignment and executions; for example, a test manager.
Can Access Planning View --The Can Access Planning View privilege enables an account type to access the Planning view of a work project.
Can Create Test Folder --The Can Create Test Folder privilege an account type to create new planning folders in the Planning Tree window.
Can Modify Test Folder--The Can Modify Test Folder privilege enables project members to edit planning folders in the Planning Tree window.
Can Delete Test Folder--The Can Delete Test Folder privilege enables project members delete planning folders in the Planning Tree window.
Can Create New Release -- The Can Create New Release enables the account type to create a new release (release folder) and define release settings.
Can Create New Test Cycle -- The Can Create New Release enables the account type to create a new test cycle (test cycle folder) and define test cycle settings.
Can Show Template Tree--The Can Show Template Tree enables the account type to view the template tree panel in the planning and test task view of the DevTest client.
Can Access User Preference --The Can Access User Preference enables the account type to define personal preferences in the DevTest client.
Can Push User Preference Settings To Other User --The Can Push User Preference Settings To Other User enables the account type to define the personal preferences of other project team members.
Administering Test Task Management Privileges
In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Issue management privileges determine which project team members may submit and manage test tasks in a project. Work view privileges are assigned to account types that are responsible for executing test tasks in a work project.
Can Access Task View privilege --The Can Access Task View privilege enables project members to access the Task view within a work project.
Can Forward Own Task to Own Group Members privilege --The Can Forward Own Task To Own Group Members privilege enables project members to forward the test tasks they own to members of their group.For more information on groups see “Administering Team Groups” on page 94
Can Forward Other User’s Task Within Own Group privilege --The Can Forward Other User’s Task Within Own Group privilege enables project members to forward tasks belonging to members of their group to other members of the same group. For more information on groups see “Administering Team Groups".
Can Forward Own Tasks to All Project Members privilege -- The Can Forward Own Tasks to All Project Members privilege enables an account type to forward the test tasks they own to any other project member.
Can Forward Other User’s Task to All Project Members privilege -- The Can Forward Other User’s Task to All Project Members privilege project members to forward test tasks belonging to anyone in the project to any other project member.
Can View Tasks With Own Group privilege--The Can View Tasks of All Groups privilege enables project members to view every test tasks that is owned by a member of their group. For more information on groups see “Administering Team Groups”.
Can View Tasks of All Groups privilege --The Can View Tasks of All Groups privilege enables project members to view all tasks belonging to every groups. For more information on groups see “Administering Team Groups”.
Can Edit Tasks within Group privilege --The Can Edit Tasks within Group privilege enables project members to edit test tasks belonging to anyone within their group. For more information on groups see “Administering Team Groups”.
Can Edit All Tasks privilege -- The Can Edit All Tasks privilege enables project members to edit test tasks belonging to all project members.
Can Edit Other User’s Notes privilege--The Can Edit Other User’s Notes privilege enables project members to edit notes created by all project members.
Can Define Public Query privilege --The Can Define Public Query privilege enables project administrators to define queries that are available to all project members.
Can Perform Group Change privilege -- The Can Perform Group Change privilege project members to edit or forward groups of test tasks simultaneously
Can Perform Inter-project Defect Submission privilegeThe Can Perform Inter-project Defect Submission privilege enables project members to submit product defect issues to an integrated DevTrack project from within the Task view of a DevTest work project.
Can Link a Defect to a Test Task privilege The Can Link a Defect to a Test Task privilege enables project members to create links between DevTest test tasks and DevTrack product defect issues.
Can Delete a Test Task privilege The Can Delete a Test Task privilege enables project members to delete test tasks in a work project.
Can Add Template Feedback Note privilege The Can Add Template Feedback Note privilege enables project members to create template feedback notes. Template feedback notes enable project members to inform template project members of errors found in child test tasks.
Can Edit Time Tracking Item privilege The Can Edit Time Tracking Item privilege enables project members to edit the time measured by the time tracking stopwatch. The Can Edit Time Tracking Item privilege may only be granted if time tracking is enabled in the Time Tracking Settings page.
Administering Knowledge View Privileges
Work Knowledge view privileges enable project members to perform certain actions in the Knowledge view of a template project.
All DevTest privileges are granted to account types. Project members inherit privileges when they are assigned an account type in a project.
Administering Report View Privileges
The Report view enables users to create public reports. Report view privileges are generally only granted to team members responsible for generating and examining test plan results.
Can Access Test Task Report View The Can Access Test Task Report View privilege enables the account type to access the test task report view.
Can Create Public Test Task Report The Can Create Public Test Task Report privilege enables the account type to author public test task reports.
Can Create Private Test Task Report The Can Create Private Test Task Report privilege enables the account type to author private test task reports.
Can Access Template Report View The Can Access Template Report View privilege enables the account type to access template report view.
Can Create Public Template Report The Can Create Public Template Report privilege enables the account type to author public template reports.
Can Create Private Template Report The Can Create Private Template Report privilege enables the account type to author private template reports.
Can Delete Public Test Task Report The Can Delete Public Test Task Report privilege enables the account type to delete public test task reports.
Can Delete Public Template Report The Can Delete Public Template Report privilege enables the account type to delete public template reports.
Can Enable Web Query Report The Can Enable Web Query Report privilege enables the account type to enable and define web query reports.
Administering Invisible Test Task Pages and Fields
Invisible page and field access controls enable project administrators to choose the data is displayed to project team members based on their account type.
Pages or data-entry controls that track confidential data may be displayed to project members of one account type—for example, management—and hidden from other account types.
Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as invisible.
Administering Read-Only Test Task Pages and Fields
Read-only page and field access controls enable project administrators to control which project team members may update project data based on their account type.
Pages or data-entry controls that track confidential data may be editable to project members of one account type—for example, management—and read-only to project members belonging to other account types.
Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as read-only.
In DevTest, a team group is an administrator-defined collection of project members— who do not necessarily share the same account type, but who share common responsibilities in a work project.
Team groups organize support teams into smaller, more useful entities that facilitate the assignment and control of issues and events.
Team groups are fully customizable. Project administrators create team groups to represent teams of project members that share the same manager, are working on the same product or component, share the same shift, work from the same office, or any other grouping that makes sense to the organization.
Figure 6-2: Project Members and Groups
Team groups cannot “own” work items. But project administrators may use team groups to determine which project team members may own work items in particular workflow states or who may be automatically assigned issues based on administrator-defined rules.
Team groups are particularly useful to project administrators when they define work item workflow and routing rules, privileges and access controls, and issue notification and escalation rules.
Workflow Team groups may be defined as anapplicable ownerof issues in each workflow state. Only those project members that are members of an applicable team group may be assigned issues in that state.
Routing Team groups may be defined as the “target” of work items automatically routed based on administrator-defined routing rules.
Notification and Escalation Team groups may be defined as potential recipients of issue or event notification and escalation messages based on administrator-defined rules.
Privileges Team groups may define the scope of the privileges granted to project members of a particular account type. The ability of a project member to view or forward work items may be restricted based on team membership.
In the DevTest client, work items may be filtered in the issue list panel by team group. Moreover, report authors may run reports that return project data grouped by team group.
Defining Team Groups
Using controls in the Team Groups page, project administrators may create any number of team groups and assign any number of project team members to each team group. A project member may belong to multiple team groups.
To create groups:
1Select Project Settings > Team Groups in the tree panel.
The Team Groups page appears.
2Click The New button.
The New Team Group dialog box appears.
3Enter a name in the In The Group Name field.
4Click the Ok button.
The New Team Group dialog box closes and the group appears in the Existing Groups list of the Groups page.
5Select the group in the in Existing Groups list.
6Select project members in the Groups Member Selection area.
A check mark appears next to the name of the project member when they have been added to the group.
7Define the e-mail notification list for the group.
For step-by-step instructions see “Defining Team Group Email Notification Lists”.
To rename a group:
1Select Project Settings > Groups in the tree panel.
The Groups page appears.
2Highlight a group in the Existing Groups list.
3Click the Rename button. The Edit Team Group dialog box appears.
4Enter a name for the group in the Group Name field.
5Click the OK button. The Edit Team Group dialog box closes. The new group name is displayed in the Existing Groups list.
To delete a group:
1Select Project Settings > Groups in the tree panel.
The Groups page appears.
2Highlight a group in the Group Team list.
3Click the Delete button.
A DevTest Admin warning may appear prompting asking you if you really want to remove this group from the project.
4Click the Yes button.
Adding Project Members to Groups
Administrators may use controls in the Group page to add project members to groups.
To add members to groups:
1Select Project Settings > Groups in the tree panel.
2Select a group in the Group Team list.
3Select project members in the Group Member Selection list.
A check mark appears next to the members name when they have been added to the group.
Removing Project Members from Groups
Administrators may use controls in the Group page to remove project members from groups.
To add members to groups: 1Select Project Settings > Groups in the tree panel.
2Select a group in the Group Team list.
3Deselect project members in the Group Member Selection list.
No check mark appears next to the members name when they have been removed from the group.
Defining Team Group Email Notification Lists
To define group e-mail notification lists:
1Select Project Settings > Groups in the tree panel.
2Select the Define Group E-mail Notification List button in the Groups page.
The Group E-mail Notification Manager appears.
3Select a project member in the Available Members list.
The Available Members list displays all project members regardless of group or group folder membership.
4Click the Add button.
The name of the selected project member is displayed in the Members to be Notified list. To notify all group members click the Notify to All Group Members check box.
All DevTest testing activities are controlled by account typed-based privileges, workflow rules, and access controls. The ability of a DevTest user account to access projects, views, folders, and pages depends on the role (account type) assigned to that user in the project.
The account type concept provides administrators with the flexibility to customize project workflow and security to support their unique business requirements. DevTest team representation structures enable development organizations to define sophisticated and flexible workflow rules for managing project data and security.
Project-level team administration is the process of defining team management structures (account types, team groups, and group folders), adding user accounts to the project, and assigning appropriate role and responsibilities to each project member.
In DevTest, privileges and access rights are not granted to user accounts directly, but assigned to administrator-definedaccount types.
An account type defines the role assigned to a user account in a project and determines the projects, views, data, and reports that are available to a project team team member through the DevTest clients.
Users are assigned an account type when they join a project and assume the rights and privileges granted to that account type—when a user’s responsibility changes, he or she may be assigned a different account type.
In each project, the project administrator is responsible for creating all account types, granting privileges and access rights to those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project.
Defining Account Types
DevTest team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability.
All account types are project-specific and defined by the project administrator. In DevTest, organizations are free to define the account types that best represent their business processes.
For example, a typical development project might feature five different account types: the Manager account type, the System Architect account type, the Programmer account type, the Tech Support account type, and the QA account type.
Figure 6-1: Typical DevTest Project Account Types
Every licensed DevTest user may be a member of multiple projects and may be assigned a different account type in each project.
To create an account type:
1Select Project Settings > Account Type.
2Click the New button in the Account Type page.
The New Account Type dialog box appears.
3Enter a name in the Account Type Name text box.
4 Optional:
To copy standard access privilege settings from another account type:
• Select the Copy Account Type Setting From check box.
• Select an account type from the dropdown list.
5Click the OK button.
To rename an account type:
1Select Project Settings > Account Type.
2Click the Rename button.
The Rename Account Type dialog box appears.
3Enter a name in the Name field.
4Click the OK button.
To delete an account type:
1Select Project Settings > Account Type.
2Select an account type in the Account Type list.
3Click the Delete button. The Delete Account Type warning appears.
Template projects enable testing teams to develop, edit, and manage the test templates that are used to create test tasks in multiple work projects.
Template project privileges enable project members to create, edit, and otherwise manage test templates in template projects. For example, a typical template development in a template project might include the following account types:
The QA Manager
Developer
Product Manager
The QA Lead account type represents a lead tester who is responsible for managing testers in a work project. This individual understands which templates are needed to create test tasks in the child work projects and can be expected to create and edit create and edit new test templates.
The QA Manager account enables a project member to edit and approve test templates for use in work projects as part of workflow process. The QA manager would be assigned privileges that enabled that user to control every aspect of the project. For example, the QA manager might be granted the Can Edit All Templates privilege
The Developer and Product Manager account types are often used in organizations that wish to have a review and approval process for tests. It is often helpful to have team members familiar with a feature's requirements or responsible for the implementation review the tests.
Administering Template Management Privileges
In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Test template privileges determine which project team members may submit and manage development test templates in a project.
Using controls in the Privileges tab of the Account Type page, project members may grant standard issue management privileges to project members of each account type in a DevTest project
Administering Template Management Privileges
In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Test template privileges determine which project team members may submit and manage development test templates in a project.
Using controls in the Privileges tab of the Account Type page, project members may grant standard issue management privileges to project members of each account type in a DevTest project
Can Submit Template The Can Submit Template privilege enables project members to create new test templates in a template project.
Can Edit own Template The Can Edit own Template privilege enables project members to edit test templates that they created in a template project.
Can Edit Template within own Group The Can Edit Template within own Group privilege enables project members to edit test templates created by project members who belong to the same group that they do. For more information on groups see See ?dministering Team Groups?
Can Edit All Templates The Can Edit All Templates privilege enables project members to edit all of the test templates created in a template project.
Can Edit Other User? Notes The Can Edit Other User? Notes privilege enables project members to edit notes created by other project members.
Can Perform Group Actions The Can Perform Group Actions privilege enables project members to edit or forward groups of test templates simultaneously.
Can Define Public Query The Can Define Public Query privilege enables project members to create queries that are available to all project members. Private queries are only available in the client of the project member who created them.
Can Create Template Snapshot The Can Create Template Snapshot privilege enables project members to create a snapshot of a version of a test template.
Can Delete Template Snapshot The Can Delete Template Snapshot privilege enables project members to delete snapshots of test templates.
Can Perform Rollback Template Snapshot The Can Perform Rollback Template Snapshot privilege enables project members to roll back to a previous version of a test template.
Can Create Default Value Template The Can Create Default Value Template privilege enables project members to create default value templates.
Can Create Template Folder The Can Create Template Folder privilege enables project members to create template folders in the Template Tree window.
Can Delete/Move Template Folder The Can Delete/Move Template Folder privilege enables project members to move or delete the template folders in the Template Tree window.
Can Import Template (including Template Folder) The Can Import Template (including Template Folder) enables project members to import template folders and test templates from other template projects.
Can Delete Template The Can Delete Template enables project members to delete test templates.
Can Define Template Folder Write Access Control The Can Define Template Folder Write Access Control enables project members to determine which project members may create test templates in a specific template folder.
Administering Invisible Template Pages and Fields
Invisible page and field access controls enable project administrators to choose the data is displayed to project team members based on their account type.
Pages or data-entry controls that track confidential data may be displayed to project members of one account type?or example, management?nd hidden from other account types.
Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as invisible.
To define invisible pages and fields:
1Select Project Settings > Account Type page in the tree panel.
2Select an account type in the Account Types list.
Invisible pages and fields may be uniquely defined for each account type.
3Select the Invisible tab.
The Invisible tab is only displayed in the Account Type page if Standard Access Controls are enabled in the project.
4Select a page or field in the Invisible tab.
The Invisible tab displays all pages and fields in a hierarchical tree structure.
Administering Read-Only Template Pages and Fields
Read-only page and field access controls enable project administrators to control which project team members may update project data based on their account type. Pages or data-entry controls that track confidential data may be editable to project members of one account type?or example, management?nd read-only to project members belonging to other account types. Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as read-only. The Read-Only tab is only displayed in the Account Type page if standard access controls are implemented in the project.
To define read-only pages and fields:
1Select Project Settings > Account Type page in the tree panel.
2Select an account type in the Account Types list.
Read-only pages and fields may be uniquely defined for each account type.
3Select the Read-Only tab.
The Read-Only tab is only displayed in the Account Type page if Standard Access Controls are enabled in the project.
4Select a page or field in the Read-only tab. The Read-Only tab displays all pages and fields in a hierarchical tree structure.
Administering DevTest Knowledge Management Privileges
DevTest knowledge management privileges enable project team members to access, manage, publish, and update project knowledge in the knowledge view of the DevTest Windows client
Using controls in the Knowledge Access tab of the Account Type page, project administrators may grant knowledge access privileges to project team members based on their account type.:
Can Access Knowledge View The Can Access Knowledge View privilege enables project members to access the Knowledge view through a template project.
Can Build Public Knowledge The Can Build Public Knowledge privilege enables project members to create knowledge items that are available to all template project members.
Can Build Protected Knowledge The Can Build Protected Knowledge privilege enables project members to create protected knowledge items in a knowledge project.
Can Read Protected Knowledge The Can Read Protected Knowledge privilege enables project members to open and view protected knowledge items in a knowledge project.
Can Delete Knowledge The Can Delete Knowledge privilege enables project members to delete knowledge items in a knowledge project.
Can Set up Knowledge Tree and Access Control The Can Set up Knowledge Tree and Access Control privilege enables project members to manage knowledge folders in the Knowledge Tree window.
Can Unlock Documents Checked Out by Other UsersThe Can Unlock Documents Checked Out by Other Users privilege enables project members to unlock documents that have been checked out or locked by other project members.
Administering Report Management Privileges
DevTest features a built-in, robust reporting tool for end users. DevTest features over 150 predefined reports and graphs, including customizable text reports for issue lists, graphic reports for defect distribution and trends, tabular reports, lifetime analysis reports, Web Query reports, and time tracking reports at the Issue level and project level
Using controls in the Report Access tab of the Account Types page, project administrators may define account type-based access rights to reports in the DevTest Windows client and the DevTest Web client.
Distinct access rights may be defined for the reports in the DevTest Windows client and reports in the DevTest Web client.
Administrators may make reports visible to an account type by selecting the check box next to the report type in the Client Access and Web Access lists. Reports may be viewed by an account type only if a black check mark appears in the check box next to the report type.
The Report view enables users to create public reports. Report view privileges are generally only granted to team members responsible for generating and examining test plan results.
Can Access Test Template Report View The Can Access Test Template Report View privilege enables the account type to access the test template report view.
Can Create Public Test Template Report The Can Create Public Test Template Report privilege enables the account type to author public test template reports.
Can Create Private Test Template Report The Can Create Private Test Template Report privilege enables the account type to author private test template reports.
Can Delete Public Test Template Report The Can Delete Public Test Template Report privilege enables the account type to delete public test template reports.
Can Create Web Query Report The Can Create Web Query Report privilege enables the account type to create web query reports.
In DevTest, all development and project management tasks are managed and tracked by a project team consisting of multipleproject team members.A project team member is a licensed DevSuite user that has been assigned an account type.
A DevSuite user account cannot access a DevTest project unless they have been assigned a DevTest (or DevSuite) license by the system administrator and a project account type by the DevTest project administrator.
Using controls in the Project Member page, project members may add user accounts to DevTest projects, assign account types to user accounts, and view project member information.
Adding User Accounts to Projects To add user accounts to a project:
1Select Project Setting > Project Member in the tree panel.
2Select a user from the Available Members list.
Administrators may use the SHIFT and CTRL keys to select multiple users for account type assignment.
3Click the Add button.
The Account Type dialog box appears.
4Select an account type option from the Account Type dropdown list.
5Click the OK button.
The user account appears in the Members in Project list. Inactive user accounts are displayed with the word Inactive to show they are inactive.
Editing Project Member Account Types To edit a project member account types:
1Select Project Setting > Project Member in the tree panel.
2Select a user from the Members in Project list.
3Select an account type option from the Account Type dropdown list.
Removing User Accounts from Projects To remove a user account from a project:
1Select Project Setting > Project Member in the tree panel.
2Select a user from the Members in Project list.
3Click the Remove button.
The user account disappears from the Members in Project list and appears in the Available Members list.
Viewing Project Member Information To view project member data:
1Select the Project Member page in the Admin Tree window.
2Select a user account in the Available Members list or Members in Project list.
3Click the View button.
The User Information page appears.
DevTest team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability.
Group folders are an optional DevTest feature that enables development organizations to more effectively manage the distribution of work assigned to a group of project team members.
Issue ownership
In DevTest, a work item is at all times owned by a project team member or group folder. Unlike team groups which cannot “own” work items, work items may be assigned to group folders as if they were actual project members.
Using group folders, development organizations may store a pool of work items that are held in common and manually distribute those issues.
Any issue that may be assigned to a project team member may be assigned to a group folder. Group folders may be assigned work items based on workflow and routing rules.
Workflow Group folders may be defined as anapplicable ownerof issues in each workflow state and project members may assign work items to an applicable group folders as if it were another project member.
Routing Group folders may be defined as the “target” of work items automatically routed based on administrator-defined routing rules.
Security
Access to the issues assigned to a group folder is controlled by account type-based access controls. Only project members with the appropriate access rights may View, Put, or Get issues in a group folder. Used in this way, group folders serve as a “buffer” between project members and their workload.
For example, an administrator may require that all issues forwarded to the QA Testing state are assigned to the QA Testing group folder. The QA team leader belongs to the Manager account type and so has been granted the Get privilege. The QA team leader may view issues assigned to team folder and then assign those issues to specific team group members based on their workload or expertise.
Enabling Group Folders
Group folders are an optional DevTest feature that must be enabled by the project administrator on a project-by-project basis.
To enable support for group folders in a project, select the Enable Group Folder Support check box in the Group Folders page.
Defining Group Folders
A group folder is a mechanism that enables development organizations to assign and store a pool of common work items and serves as a “buffer” between project members and their workload.
Every group folder is defined by its name, a team group, account type-based access controls, and (optionally) an email notification list.
Using controls in the Group Folder page, project administrators may create group folders, define group folder membership, and group folder access controls.
In DevTest, every group folder is “owned” by an administrator-defined team group or by the All Members user variable.
Account type-based access controls enforce folder-level security. To access or manage the work items assigned to a group folder, the user must be long to an account type that has been granted the appropriate access rights for that folder.
An account type may be granted three access rights for each group folder.:
View The View access right enables the user to view the issues assigned to a group folder.
Put The Put access right enables the user to forward issues to a group folder.
Get The Get access right enables the user to get issues assigned to a group folder.
To create a group folder:
1Select Project Settings > Group Folder in the tree panel.
The Group Folder page appears.
2Click the New button.
The New Group Folder dialog box appears.
3Define a unique name and description of the group folder.
The name of the group folder is displayed in the Team Member dropdown list of the DevTest clients.
4Select a team group from the Owner Group dropdown list.
The Owner Group dropdown list displays all team groups defined in the project as well as the All Members user variable.
5Click the OK button.
The New Group Folder dialog box closes and the group folder is displayed in the Group Folder list.
6To grant folder access rights to an account type, select the View, Put, and Get controls in the Folder Access Control list.
A red check mark indicates that the access right is granted to all project members belonging to that account type.
To edit a group folder:
1Select Project Settings > Group Folder in the tree panel.
The Group Folder page appears.
2Select a group folder in the Group Folder list.
3Click the Edit button.
The Edit Group Folder dialog box appears.
4Enter a name in the Folder Name field.
5Select a group from the Owner Group dropdown list.
6Enter notes into the Description text area.
7Click the OK button.
To delete a group folder:
1Select Project Settings > Group Folder in the tree panel.
The Group Folder page appears.
2Select a group folder in the Group Folder list
3Click the Delete button.
A confirmation dialog box appears.
4Click the Yes button.
Defining Group Folder Email Notification Lists
Group folder email notification enables development teams to ensure that appropriate stakeholders are notified by e-mail whenever a work item is assigned to a particular group folder.
Unique email notification list may be defined for each group folder in a project.
To define a group folder email notification list:
1Select Project Settings > Group Folder in the tree panel. The Group Folder page appears.
2Click the Define Folder E-mail Notification List button. The Group Folder E-mail window appears.
2Add or remove project team members from the email notification list.
The Available Members list displays all project members regardless of group or group folder membership.
• To add a project member to the notification list, select the project member in the Available Members list and click the Right Arrow button.
• To remove a project member to the notification list, select the project member in the Members To Be Notified list and click the Left Arrow button.
3 Optional: To notify all group members click the Notify to All Group Members check box.
In DevTest, a template base project is a project for creating, defining, and managing a test library through the creation and management of test templates. Once defined test templates may be used to generate test tasks in one or more child work projects.
Template project administration is the process of defining test template management structures, identifying the data managed and tracked as test templates, defining project team structures, and enabling and defining optional project features including environmental variables, verification points, template feedback notes, and TestLink integration.
Template Management Structures
In DevTest, template project customization is the process of defining test template and test template management structures. All test template management structures are manifested in the test template view.
Test Template
Folder
Test Template
Each template project is the parent of many child work projects. Template structures and features enabled in the parent template project are manifested in all child work projects.Test template management structures include test template folders and test templates.
Team Administration
Every test template project is defined by unique team management structures— account types, team groups, and team folders. Template base project administrators are responsible for assigning the appropriate account types to all project team members. Test Template Folder Test Template
Optional Features
Template project administrators must enable and define five features before these features can be used in a DevTest implementation:
Template WorkflowTemplate workflow defines the test template management lifecycle and rules for managing test templates within that lifecycle. The template workflow is typically used to manage an approval process for the creation and modification of test coverage.
Environmental VariablesAn environmental variable represents the applicable environments that a particular test can be run against. Every test template may be defined by one or more environmental variables which in turn represent multiple environmental variable (EV) values. One test tasks may be generated for every EV value permutation of a test template. EV's act as a filter when planning test coverage and they can be used to create multiple test tasks when a test template is applicable for more than one environment.
Verification PointsVerification points enable testing teams to track multiple validation points in a single test case. Each verification point defines a different checkpoint (expected result) that the tester must confirm during the execution of that test task.
Template Feedback NotesTest template feedback notes enable work project members to pass information to test template project members about the test templates used to create test tasks and, optionally, to change the template state of those test templates.
Testlink IntegrationTestLink integration enables testing organizations to integrate their test template and test task management project with third party automated testing solutions.
In test template projects, test templates are managed in a hierarchical tree structure— the test template tree—that organizes test templates in the workspace, implements security, and enforces good development practices.
Every area of development within the template tree framework is represented by a template folder. A template folder is a discreet area of work that corresponds a test case.
Customizing Add Template Folder Pages
In the DevTest client, project members may create test template folders and define test template folder access controls, applicable environmental variables, and applicable work projects using the Add Test Template Folder window.
The Add Template Folder page may display multiple system pages and custom pages including:
Applicable ProjectThe Applicable Project system page enables project members to restrict access to the test templates contained in a test template folder.
Environmental VariableThe Environmental Variable system page enables project members to choose which environmental variables may be included in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template.
Folder DescriptionThe Folder Description custom page enable project members to define template folder properties.
Write AccessThe Write Access system page enables project members to restrict which project members may create test templates in a template folder by project account types.
To customize template submission pages:
1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Folder Submission page appears.
2Add or remove system or custom pages to the function page.
Four pages may be displayed in the Template Folder Submission page: the Applicable Project page, the Environmental Variable page, the Folder Description page, and the Write Access page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional: To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Customizing Edit Template Folder Pages
The Template Folder Editing function page enables template project members to update template folder properties and, depending on the pages displayed, manage how the test templates contained in a template folder are used in a project.
Administrators may determine which pages are displayed in the Template Folder Editing form by adding custom pages and system pages to the Template Folder Editing function page in DevTest Admin:
Applicable Project System PageThe Applicable Project system page enables project members to restrict access to the test templates contained in a test template folder to designated work projects.
Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template
Change Log System PageThe Change Log system page enables project members to view a readonly log of changes made to the template folder.
Folder Order System PageThe Folder Order system page enables project members to determine the order of the template folders displayed in the Template Tree window.
Notes System PageThe Notes system page enables project members to add notes or note attachments to template folders.
Template Order System PageThe Template Order system page enables project members to define the order of the test templates contained in a template folder. Template and work project members may sort records based on template order.
Time Report System PageThe Time Report system page enables project members to track the time used to perform test tasks based on the test templates contained in a particular template folder.
Folder Description Custom PageThe Folder Description custom page enable project members to define template folder properties.
To customize the edit template folder page:
1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Folder Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Customizing Add Test Template Pages
The Template Submission function page enables template project members to define test template properties.
Administrators may determine which pages are displayed in the Template Submission form by adding custom pages and system pages to the Template Folder Submission function page in DevTest Admin:
Folder Description Custom PageThe Folder Description custom page enable project members to define template folder properties.
Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template.
To customize the add test template page:
1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Folder Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Customizing Edit Test Template Pages
The Template GUI Editing function page enables template project members to update test template properties.
Template project administrators may determine which pages are displayed in the Template Editing page by adding or removing system and function page to the Template GUI Editing function page:
Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template.
Notes System PageThe Notes system page enables project members to add notes or note attachments to template folders.
Snapshot System PageThe Snapshot system page enables project members to take a snapshot of a test template at a particular point-in-time and revert to that snapshot.
Template Description Custom PageThe Template Description custom page enable project members to define test template properties.
To customize template submission pages:
1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Folder Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Customizing Template Detail Pages
The pages displayed in the Template Detail window enable template project members to update test template properties.
Administrators may determine which pages are displayed in the Template Detail window by adding custom pages and system pages to the Template Detail function page in DevTest Admin:
Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template.
History System PageThe History system page enables project members to view a read-only history of a test template.
Linked Task System PageThe Linked Task system page enables project members to view test tasks linked to test templates.
Notes System PageThe Notes system page enables project members to add notes or note attachments to template folders.
Snapshot System PageThe Snapshot system page enables project members to take a snapshot of a test template at a particular point-in-time and revert to that snapshot.
Testlink System PageThe Test Link system page enables project members to run automated test scripts.
Template Description Custom PageThe Template Description custom page enable project members to define test template properties.
To customize the test template detail page:
1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Customizing Test Template Forward Pages
The Template Forward function page enables template project members to forward test templates to other project members and, optionally, to update test template properties.
Administrators may determine which pages are displayed in the Template Forward form by adding custom pages to the Template Folder Submission function page in DevTest Admin.
To customize template submission pages:
1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
Customizing Test Template Snapshot Pages
The Template Snapshot function page enables users to take a snapshot of test templates and save them in the project. Using the Snapshot page users can save several different versions of a test template and rollback to previous versions of the test template.
Administrators may determine which pages are displayed in the Snapshot page by adding custom pages to the Template Folder Snapshot function page in DevTest Admin.
Generally, the snapshot page is used to take a snapshot of general test template properties such as those displayed in the Template Description custom page.
To customize template submission pages:
1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
Customizing Default Value Template Pages
The Default Value Template manager enables template project members to pre-define the field values for the test templates created in the Template view.
Project administrators may add an unlimited number of custom pages to the Default Value Template function page. Each custom page that the project administrator adds to the Default Value function appears in the Default Value Template manager.
The Test Template Default Value Template function page enables project administrators to define which pages template project members may pre-define when they create test templates.
To customize the default value template page:
1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
Customizing Template Group Change Pages
The Template Group Change function page enables template project members to change test template properties for a group of test templates.
Administrators may determine which pages are displayed in the Template Group Change form by adding system pages and custom pages to the Template Group Change function page in DevTest Admin:
• The Environmental Variable system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template.
• Administrators may add any number of custom pages to the Template Group Change function page.
To customize template submission pages:
1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Submission page appears.2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Customizing Template Group Folder Pages
The Template Group Folder function page enables template project members to define which pages appear in the Template Detail window of template projects.
Administrators may determine which pages are displayed in the Template Group Folder form by adding custom pages and system pages to the Template Group Folder function page in DevTest Admin:
Administrators may add any number of custom pages to the Template Group Change function page.
To customize template submission pages:
1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window.
The Template Submission page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3To change the title of the function page, enter a new title in the Page Display Name field.
Template project workflow rules determine the way that test templates are managed in DevTest work projects. All DevTest workflow rules are based on the relationship between three entities: workflow states, transitions, and applicable owners. Project administrators may define workflow rules to manage test templates that are based on template states or the transitions between template states.
Template workflow rules define the how test templates are managed in a template based project. Workflow rules define which members may own a test template, what changes may be made to test template, or even which controls are displayed in the test template itself.
Creating Template States
In DevTest template base projects, all test template management tasks are based on template states. A template state represents a particular stage in the life cycle of a test template.
The administrator-defined workflow rules are based on template states or state-to-state transitions. At all times during template workflow, access to a test template— including the ability to view and update—is controlled by the template state.
Template states might include:
• Approved
• Draft
• Pending Approval
All template states are defined in a template project within DevTest Admin. The template states are shared by every work projects based on that parent template project. Work project administrators may define their own workflow rules to manage these template states and need not utilize every template state inherited from the parent template project.
Template administrators may create as many workflow states as they deem necessary to implement workflow in their work projects.
To create template states:
1Select the
The State page appears. All currently defined workflow states and their current status appear in the State list.
2Click the New button.
The Add a
3In the State text box enter the state name.
4In the Status area, select a status property for the state.
• Select the Open radio button if a user can open an issue in this workflow state. When a user opens an issue, the issue must be in one of these workflow states.
• Select the Closed radio button if a user can close an issue in this workflow state. When a user closes an issue, the issue must be in one of these workflow states.
5Click the OK button.
Defining Default Template States
Template project administrators may use the
To define default template states:
1Select the
The State page appears. All currently defined workflow states and their current status appear in the State list.
2Select a default template state in the
Editing Template States
Template project administrators may use the
To edit test template workflow states:
1In the Template Base project Tree window select the State Definition folder.
2Select the
3Select a workflow state in the State list.
4Click the Edit button. The Edit the State dialog box appears.
5 Optional:To change the title of the workflow state, enter a new title in the State text box.
6 Optional:To change the status of the progress, select an option in the Status area.
7 Optional:To make data-entry controls in this workflow state read-only, select the Read Only in this State check box.
8Click the OK button.
Enabling State-to-State Transition Options
The State to State Transition option enables the administrators to define workflow rules which manage the transitions between template states.
To enable the state-to-state option, select the State-to-State Transition check box. State-to-state workflow rules restrict template state changes. For more information see See “Defining State Transition Workflow Rules”.
Enabling State-based Applicable Owner Rules
The Applicable Owners option enables project administrators to specify the user accounts, account types, and groups that may own a test template based on its template state.
To enable the applicable owners option, select the Applicable Owners check box. Applicable owner workflow rules enable the administrator to ensure that test templates are only assigned or forwarded to a designated applicable owner.
For more information see See “Defining Applicable Owner Workflow Rules”.
Enabling State-based Read-only Field Rules
The Read-Only Fields option enables project administrators to designate controls as read only in particular template states. To enable the read-only fields option, select the Read-only Fields check box. If this option is enabled, read-only workflow rules may be defined that prevent controls from being updated when a test template is in certain template states. For more information see See “Defining Read-Only Workflow Rules”.
Enabling State-based Invisible Field Rules
The Invisible Fields option enables project administrators to designate test template controls as invisible when that test template is in certain template states. To enable the invisible controls option, select the Invisible Fields check box. For more information see See “Defining Invisible Fields Workflow Rules”.
Enabling State-based Mandatory Field Rules
The Mandatory Fields option enables project administrators to designate test template controls as mandatory when that test template is in certain template states.Mandatory controls must be completed before the template state of the test template can be changed. To enable the mandatory controls option, select the Mandatory Fields check box. For more information see See “Defining Mandatory Fields Workflow Rules”.
Enabling State-based Access Controls
The Who Can Change option enables project administrators to restrict which project members may make changes to test templates based on their workflow states. Who Can Change rules may be based on the current workflow state of the test template, or they may be based on state transitions.
To enable the who can change option, select the Who Can Change check box.
For more information see See “Defining Who Can Change Workflow Rules”.
To enable test template workflow properties:
1Select the Options page beneath the State & Workflow folder in a work project in DevTest Admin.
The Options page appears.
2Select the appropriate check box to enable each workflow property option. Administrators may enable the following workflow properties in each template project:
3If the State-to-State Transition option has been enabled, the administrator may select a workflow option from the Who Can Change dropdown list.
• Current state workflow rules limit who can change template states based on the current state of the test template.
• Transition workflow rules define who can change template states based on state-to-state transitions.
Defining State Transition Workflow Rules
Template project administrators may use tools in the State Transition tab of the Template Workflow page to define transitions between template states in template projects.
State transition workflow rules enable administrators to ensure that project members may only change the template state of test templates to appropriate states. For example, administrators may define state transition workflow rules ensure that project members can only change the workflow state of a test template from State A to State B and not from State A to State C.
Administrators may only define state transition workflow rules if they have enabled the State-to-State Transition workflow option in the Options page.
To define state transition workflow rules:
1Select the Settings page beneath the State& Workflow folder in the Tree window.
The Settings page appears.
2Select the State Transition tab.
The State Transition page appears.
3Highlight a workflow state in the
4Select test templates in the
The options displayed in the
Defining Applicable Owner Workflow Rules
Template project administrators may use tools in the Applicable Owner tab of the Template Workflow page to define applicable owner rules and default applicable owners for test templates.
• Applicable owner rules determine which project members may own a test template based on the template state of the test template.
• Default applicable owners are the default owners for test templates in a particular template state.
An applicable owner may be a user, an account type, a member of a group or group folder, or any of a number of a predefined system users (Unassigned, Submitter, Current Owner and Previous Owner).
Ownership means a user has privileges and responsibilities for the test template that other users do not have. Applicable owner workflow rules enable managers to direct test templates to individuals or teams with particular skills or expertise.
Work project administrators may enable test template ownership for five different types of applicable owners: account types, groups, group folders, system applicable owners, and user accounts.
• An account type applicable owner represents an administrator-defined account type.
• A group applicable owner represents an administrator-defined group of account types.
• A group folder applicable owner represents an administrator-defined group of account types.
• System applicable owners represent system variables that may be assigned ownership of test templates in particular template states. Administrators may enable five different types of system applicable owners: {Unassigned], {Submitter}, {Current Owner}, and {Previous Owner}.
• A user applicable owner represents a user account. Administrators may only define applicable owner workflow rules if they have enabled the Applicable Owner workflow option in the Options page.
To define applicable owners workflow rules:
1Select the Template Workflow page in the State Definition folder of a template base project.
The Template Workflow page appears.
2Select a template state in the Template States list.
3Select the Applicable Owners tab. The Applicable Owners page appears.
4Select a template state in the
5Select all appropriate workflow applicable owners in the Applicable Owners list.
Administrators may assign as many applicable owners as needed for each template state.
6Select a default applicable owner option in the Default Owner dropdown list.
Default applicable owners are by default responsible the test templates in each workflow state.
Defining Applicable Owners in the User Manager
Project administrators may define applicable owner workflow rules using controls in the User Manager. The User Profile page in the User manager enables administrators to define or update applicable owner rules for each user account across all template states.
Applicable owner workflow rules determine which project members may own a test template in a particular template state.
All changes made to the profile of a user account in the User Manager are immediately implemented in project workflow rules.
To apply ownership in the user profile:
1Select System > User Manager in the tool menu.
The User Manager appears.
2Select a project member in the User Manager.
3Click the Profile button. The User Profile page appears.
4Click the Workflow page.
The Workflow tab allows users to specify applicable ownership rules for the selected user. All predefined workflow states will be listed in the window.
5Select the appropriate test template states.
The user may own test templates in all selected template states.
6Click the OK button.
Defining Who Can Change Workflow Rules
Work project administrators may use tools in the Who Can Change tab of the Settings page to define which project members may change the template state of a test template. Who Can Change workflow rules are based either on template states or the transition between template states.
• Current state workflow rules designate which project members may change template states based on the current state of the test template.
• Transition workflow rules designate which project members may change template states based on the transitions between tasks states.
Administrators may grant project members the ability to change the template state of test template based on either on current states or on the transitions between template states.
The workflow rules defined in the Who Can Change tab depend on the Who Can Change option selected by the project administrator in the Options page.
• If the administrator has enabled the Based on the
• If the administrator enabled the Based on State Transition option in the Options page, Who Can Change workflow rules restrict the options available to project members when they change the template state of test templates.
Note:Account type privileges override the Who Can Change workflow rules. Even though administrator-defined Who Can Change workflow rules may entitle a project member to change template states, that project member may only change the template state of template states for which they have been granted the edit privilege, based on their account type.
Administrators may only define who can change workflow rules if they have enabled the Who Can Change workflow option in the Options page.
To define current state workflow rules:
1Select the Settings page beneath the State & Workflow folder in the Tree window.
The Settings page appears.
2Select the Who Can Change tab.
The Who Can Change page appears.
3Select a template state in the
4Select one or more project members in the Member Name text box.
To define transition workflow rules:
1Select the Template Workflow page in the State Definition folder of a template base project.
The Template Workflow page appears.
2Select a template state in the Template States list.
3Select the Who Can Change tab.
The Who Can Change page appears.
4Select a template state in the
5Highlight a template state in the
The options displayed in the
6Select one or more project members in the Member Name list.
The selected project members may change the template state of a test template from the template state selected in the
Defining Read-Only Workflow Rules
In DevTest, a read-only field represents a data-entry control that may be viewed but not edited in the client in a particular workflow state.
Template workflow rules enable project administrators to define one or more test template properties as read-only in each template state. Template properties managed in the in the Description,
To define read-only workflow rules:
1Select the Template Workflow page in the State Definition folder of a template base project. The Template Workflow page appears.
2Select a template state in the Template States list.
3Select the Read Only Fields tab.
The Read Only tab is only displayed in the Template Workflow page if read-only workflow rules have been enabled in the project. For more information see See “Enabling State-based Read-only Field Rules”.
4Select one or more fields in the Read Only text box.
The Read-only Fields list displays the following test template properties:
Expected ResultTitle
E. Setup TimeE.Test Time Test
Procedure
The selected fields are designated as read-only when a test template is in the selected template state.
Defining Invisible Fields Workflow Rules
In DevTest, a invisible field represents a data-entry control that is not displayed in the client in a particular workflow state. Template workflow rules enable project administrators to define one or more test template properties as invisible in each template state.
Template properties managed in the in the Description,
To define invisible field workflow rules:
1Select the Template Workflow page in the State Definition folder of a template base project.
The Template Workflow page appears.
2Select a template state in the Template States list.
3Select the Invisible Fields page.
The Invisible Field tab is only displayed in the Template Workflow page if read-only workflow rules have been enabled in the project. For more information see See “Enabling State-based Invisible Field Rules”
4Select one or more fields in the Invisible Fields text box.
The Invisible Fields list displays the following test template properties:
Expected ResultTitle
E. Setup TimeE.Test Time Test
Procedure
The selected fields are designated as invisible when a test template is in the selected template state.
Defining Mandatory Fields Workflow Rules
In DevTest, a mandatory field represents a property that must be defined in a particular workflow state. Template workflow rules enable project administrators to mandate that one or more test template properties be defined in each template state.
Template properties managed in the in the Description,
To define mandatory fields workflow rules:
1Select the Template Workflow page in the State Definition folder of a template base project.
The Template Workflow page appears.
2Select a template state in the Template States list.
3Select the Mandatory Fields tab.
The Mandatory Fields tab is only displayed in the Template Workflow page if read-only workflow rules have been enabled in the project. For more information see See “Enabling State-based Mandatory Field Rules”.
4Select one or more fields in the Mandatory Fields list. .The Mandatory Fields list displays the following test template properties:
Expected ResultTitle
E. Setup TimeE.Test Time Test
Procedure
The selected fields are designated as mandatory when a test template is in the selected template state.
In DevTest, an environmental variable identifies an environmental factor that may performance of a feature or function during a test cycle—examples include the operating system, hardware, network infrastructure, or browser types.
Each environmental variable represents one or more environmental variable values (EV values). EV values are the specific instances of an environmental variable. For example, the Web Browser environmental variable may represent three different EV values: Internet Explorer, Firefox, and Safari.
When a test template includes multiple environmental variables, project teams may generate one test task for eachpermutationof EV values present in the parent test template. A permutation represents one combination of all of the possible EV values present in the test template.:
Test templates are particularly powerful when they include multiple environmental variables each of which represents multiple EV values.
A test template that includes two environmental variables (X and Y) that represent three EV values a piece may be used to create nine test tasks (3 x 3).
A test template that includes three environmental variables that represents three EV values a piece may be used to create 18 test tasks (3 x 3x 3).
By building environmental variables into test templates, testing organizations may create powerful test templates that may be used to generate many different test tasks that are appropriate to different testing environments.
Environmental variable administration the process of enabling the environmental variable features. identifying environmental factors, defining environmental variable assignment options, creating the environmental variables and EV values, defining the maximum number of EV permutations per test template, and defining the maximum number of EV permutations that may be selected in each test template.
Enabling Environmental Variables
Environmental variables are an optional DevTest feature that must be enabled on a project-by-project basis.
To enable environmental variables, select the Enable Environmental Variables check box in the Features Options page in the tree panel.
Defining Environment Variable Assignment Options
In DevTest, environmental variables may be assigned to test templates on atemplate-by-template basisorfolder-by-folder basis.
Template-by- TemplateThe By Template option enables project members to assign environmental variables to each test template individually. Each test template contained in a template folder may be assigned a unique set of environmental variables.
Folder-by-FolderThe By Template Folder option enables project members to assign environmental variables to all of the test templates contained in a particular template folder. Every test template within a template folder uses the same set of environmental variables.
To define environmental variable assignment options:
1Select Project Settings > Environment Variable Settings in the tree panel.
2Select an option in the Environment Variables Option area.
• To assign environmental variables on a template-by-template basis, select the By Template option button.
• To assign environmental variables on a folder-by-folder basis, select the By Template Folder option button.
Defining Environmental Variables To add an environmental variables:
1Select Project Settings > Environment Variable Settings in the tree panel.
2Click the New button in the Environment Type area.
The Add Environment Type dialog box appears.
3Enter a name for the environment variable in the Name text box.
4Enter a brief description of the environment variable in the Description text area.
5Click the OK button.
The Add Environment Type dialog box closes and the new environmental variable is displayed in the Environment Type list.
To edit an environmental variable:
1Select an environmental variable in the Environment Type list of the Environment Variable Settings page.
2Click the Edit button in the Environment Type area.
The Edit Environment Type dialog box appears.
3Update the title of the environmental variable in the Name text box.
4Update the description of the environmental variable in the Description text box.
5Click the OK button.
The Edit Environment Type dialog box closes.
To delete an environmental variable:
1Select an environmental variable in the Environment Type list of the Environment Variable Settings page.
2Click the Delete button in the Environment Type area.
A confirmation dialog box appears.
3Click the Yes button.
Defining Environmental Variable Values
An environmental variable value (EV value) is a specific value that is substituted for an environmental variable when test tasks are generated from a test template.
For example, a Web Browser environmental variable may represent three EV values: the Firefox, Internet Explorer, and Safari EV values.
To add an environmental variable value:
1Select Project Settings > Environment Variable Settings in the tree panel.
2Select an environmental variable in the Environment Type list.
3Click the New button in the Environment Value area.
The New Environment Type Value dialog box appears.
4Enter a name for the EV value in the Name text box.
5Click the OK button.
The New Environment Type Value dialog box closes and the EV value is displayed in the Environment Value list.
To add an environmental variable value:
1Select an environmental variable in the Environment Type list of the Environment Variable Settings page.
2Select an EV value in the Environment Value list.
3Click the Edit button in the Environment Value area. The Edit Environment Type Value dialog box appears.
4Update the name of the EV value in the Name text box.
5Click the OK button.
The Edit Environment Type Value dialog box closes and the updated EV value is displayed in the Environment Value list.
Defining Maximum Possible EV Value Permutations
An EV permutation represents a combination of environment factors—such as the operating system, hardware, and network architecture—that may affect the performance of an application in a test cycle.
Each combination of EV values defines a specifictesting environment. Test templates with built-in environmental variables enable test planners to generate test tasks for many different environments using a single test template.
Using controls in the Environmental Variable Settings, template project administrators may define the limit the number EV value permutations that may be generated in each test template.
The maximum number of possible EV value permutations is 9999.
To define the maximum number of EV permutations:
1Select the Project Settings > Environmental Variable Settings in the tree panel.
2Enter a number in the Maximum Number of Possible Environmental Variable Permutations text box.
This number determines the maximum number of total environmental variable permutations that may be generated in a test cycle.
3Enter a number in the Maximum Number of Possible Environmental Variable Permutations text box.
This number determines restricts number of total environmental variable permutations that may be selected to generate test tasks in a test cycle.
Defining Maximum Selectable EV Permutations
An EV permutation represents a combination of environment factors—such as the operating system, hardware, and network architecture—that may affect the performance of an application in a test cycle.
Each combination of EV values defines a specifictesting environment. Test templates with built-in environmental variables enable test planners to generate test tasks for many different environments using a single test template.
Using controls in the Environmental Variable Settings, template project administrators may limit the number EV value permutations that may be selected to create test tasks based on each test template.
<< div/>
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.
• A release cycle defines the scope and objectives of a group of test cycles—the test schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
• A test cycle is a group of tests that are generated within a release cycle. Test cycle planning is the act of choosing appropriate test templates and environments, generating test tasks, and assigning those test tasks to testers for test execution.
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.
Test planning administration is the defintion and customization of tools that enable test planners to define and manage release cycles and test cycles in the planning view of a work project.
Using planning wizards project members may generate multiple test tasks from each test template utilizing each templates built-in environmental variables and EV values.
Project administrators may make relatively few customizations to the planning wizards in DevTest projects. Planning wizard customization consists of three tasks:
• Project administrators may change the title of all planning wizard pages.
• Project administrators may add and format page descriptions in each planning wizard page.
• Project administrators may customize headers and enable target data reporting in the Target Data Planning wizard.
In DevTest, all test planning – the definition of the scope and objectives—is managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles—the 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.
Product Folders:Product folders enable project teams to organize their test processes by product. Within each product folder project members may organize testing processes by release and test cycle.
Release Folders:Release folders contain all of the test tasks performed during a particular release. Within a release folder test task records are stored in multiple test cycle folders.
Test Cycle Folders:Test cycle folders contain all of the test tasks that are used during a test cycle within a release. Each test cycle folder is contained within a release and inherits the team members, test templates, and environmental variable definitions assigned in the parent release folder.
To enable test planners to view notes in a modeless window, select the Enable View Note in Modeless Window check box in the Notes page of the Folder System Page subfolder in the Planning View GUI Settings folder in a work project.
To display the Notes page in the folder property, select the Display in Folder Property check box in the Notes page of the Folder System Page subfolder in the Planning View GUI Settings folder in a work project.
To enable test planners to view notes in a modeless window, select the Enable View Note in Modeless Window check box in the Notes page of the Folder System Page subfolder in the Planning View GUI Settings folder in a work project.
To display the Notes page in the folder property, select the Display in Folder Property check box in the Notes page of the Folder System Page subfolder in the Planning View GUI Settings folder in a work project.
In DevTest, all test planning – the definition of the scope and objectives—is managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles—the test schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.
The release wizard organizes release planning management tasks into a series of form pages that represent a single operation. Each operation must be completed in a specific order.
Release wizard pages include the Team Selection page, EV Selection wizard page, the Coverage Selection page, the EV Permutation page, the Coverage Selection page, the Coverage Update page, and the Target Data page.
Team Selection Wizard Page:The Team Selection page enables project members to define the project members available in a release or test cycle.
Ev Selection Wizard Page:The EV Selection page enables project members to define environmental variable filters for selecting the test templates available in the release.
Coverage Selection Wizard Page:The Coverage Selection page enables project members to select test templates to create test tasks within a release or test cycle.
Ev Permutation Wizard Page:The EV Permutation page enables project members to generate combinations of environmental permutations based on the environmental variables selected in the EV Selection page. The EV Permutation wizard page only appears in the Release wizard.
Coverage Update Wizard Page:The Coverage Update page enables project members to change the environmental permutations definitions in a release or test cycle.
Target Data Wizard Page:The Target Data page enables project members to define testing target for the current release cycle.
The Target Data release wizard page is optional and may be displayed in the release wizard or in the Release Folder Editing page.
In DevTest, 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.
The test wizard organizes test cycle planning management tasks into a series of form pages that represent a single operation. Each operation must be completed in a specific order.
Test cycle wizard pages include the the Selection page, EV Permutation page, Coverage Selection page, and the Coverage Update page. The Team Selection wizard page is option in the test cycle wizard.
The test cycle wizard may consist of up to six different planning wizard pages.
Team Selection Wizard Page:The Team Selection page enables project members to define the project members available in a release or test cycle.
Ev Selection Wizard Page:The EV Selection page enables project members to define environmental variable filters for selecting the test templates available in the release.
Coverage Selection Wizard Page:The Coverage Selection page enables project members to select test templates to create test tasks within a release or test cycle.
Coverage Update Wizard Page:The Coverage Update page enables project members to change the environmental permutations definitions in a release or test cycle.
In DevTest Admin administrators may use the Setup Warning Message control to define test coverage warning messages.
Project administrators may define the titles and page descriptions for the planning wizard pages displayed in planning wizard pages.
Administrators may define titles and descriptions for the release cycle wizard pages and test cycle wizard pages displayed in the planning view.
Release Cycle Wizard Pages
Team Selection EV Selection
EV Permutation Coverage Selection
Coverage Update Target Data
Test Cycle Wizard Page
Team Selection EV Selection
Coverage Selection Coverage Update
To define wizard page titles and descriptions:
1Select a planning wizard page in the Planning Wizards Pages folder.
• Release planning wizard pages are in the Release Planning Wizard Pages subfolder.
• Test Cycle planning wizard pages are in the Test Cycle Planning Wizard Pages subfolder.
2Enter a title for the page in the Page Display Name field.
3Select the Show the Following Page Description check box.
4Enter a brief description of the planning wizard page in the Description field.
• Select the Bold check box to set the text in boldface.
• Select the In Group Box check box to set the text in a a group box.
In DevTest, test coverage warning messages are displayed in the client workspace whenever the maximum number of allowable test tasks or verification points are generated in a test cycle.
Administrators may define the text of the message and the numerical triggers for the test coverage warning messages in the Define Warning Message dialog box.
Figure 8-2: Define Warning Message Dialog Box
In DevTest administrators may set limits on the number of test tasks and the number of verification points that may be generated within a test cycle. Test coverage warning messages appear only when these limits are exceeded.
Administrators may use the Setup Warning Message button in the Test Cycle Coverage Update page to test coverage warning messages.
To define coverage update warning messages:
1Select the Test Cycle Coverage Update page in the Admin Tree window.
2Click the Setup Warning Message button. The Define Warning Message dialog box appears.
3Select the Display the Following Message When check box.
4Define the test task numerical trigger.
5Define the dynamic verification point numerical trigger.
6Enter a text message in the Message field.
7If you want to reset the coverage update warning message to the default message, click the Reset button.
8Click the OK button.
The Edit Release Folder manager is a multiple page tabbed form that enables test planners to update team membership, test coverage, and other release cycle settings. The Notes system page may be displayed in the the Edit Release Folder manager.
Work project administrators may display Notes system pages in the Edit Release Folder manager and Edit Test Cycle Folder page of the planning view of a work project.
If the Notes page is displayed in the Edit Release Folder manager or the Test Cycle Folder manager, work project members may add notes and attachments to planning folders in the Planning Tree window of a work project.
To add the Notes page:
1Select Planning View GUI Settings > Folder System Pages > Notes page in the Tree window of a work project in DevTest Admin.
2Select the Display in the Folder Property check box.
The Edit Release Folder manager is a multiple page tabbed form that enables test planners to update team membership, test coverage, and other release cycle settings. The Target Data wizard page may be displayed in the the Edit Release Folder manager.
Using the Test Data wizard page, project members may view and update target data for a release cycle.
To enable release target data reporting:
1Select the Target Data page in the System Wizard Page subfolder of the Planning Wizard folder in a work project.
2Select the Enable Target Data Reporting in Release Folder Property check box.
Project administrators may display the Target Data release wizard page in the release wizard. The Target Data release wizard page enables project members to view and update target data for a release cycle.
To display the target data page in the release wizard:
1Select Planning View GUI Settings > Planning Wizard Page > System Wizard Page > Target Data Page in the Tree window of a work project in DevTest Admin.
2Select the Enable Target Data Reporting in Release Folder Creation check box.
To enable release target data reporting:
1Select Planning View GUI Settings > Planning Wizard Page > System Wizard Page > Target Data Page in the Tree window of a work project in DevTest Admin.
2Select the Release Target Data check box.
3Define the start time for the service in the Start Update Service field.
4To display the target data release wizard page in the release wizard select the Enable Target Data Reporting in Release Folder Creation check box.
5To display the target data release wizard page in the Release Folder Editing page select the Enable Target Data Reporting in Release Folder Property check box.
Test planning is the process of selecting, generating, and assigning test tasks to project members for testing. Test planners may choose appropriate test templates, environments, and team members for reach release cycle and test cycle.
In DevTest, all test planning is managed in a work project planning view using two planning wizards—the release wizard and the test cycle wizard.
• The release wizard enables test planners to define the test templates, environments, test coverage, team members, and the target data that may be used in a release cycle.
• The test cycle wizard enable test planners to define the the test templates, environments, and test coverage that may be used in the test cycle.
A wizard is a GUI element that progressively discloses the operations that are required to complete a complex process. In the planning wizards each operation is represented by a distinct page—a planning wizard page—that is displayed in a prescribed sequence.
Planning wizards simplify the process of defining testing teams, test templates, environmental variables, and test tasks by representing each of these tasks as a distinct page.
• The release wizard is comprised of the Team Selection page, selection page, EV Permutation page, Coverage Selection page, Coverage Update page, and, optionally, the Target Data page.
• The test cycle wizard is composed of the Selection page, EV Permutation page, Coverage Selection page, and the Coverage Update page. The Team Selection wizard page is optional in the Test Cycle wizard.
Although each wizard organizes different processes, each wizard draws on same set of system pages.
Figure 8-1: Planning View Wizards
Administrators may edit the Page Display Name and Page Description fields of all planning wizard pages, but may not make any no other changes to the graphical user interface of the page. For more information see
Each summary report is composed four different type of columns:
• System columns
• State columns
• State Group columns
• Percentage State Group columns
System Columns
System column types display statistics gathered by the system for each DevTest record.
Summary report system columns include:
Tasks Assigned Defect Count E. Test Time
E. Setup Time E. Total Time Actual Test Time
Actual Setup Time Actual Total Time Test Time Delta
Setup Time Delta Total Time Delta Target Total Tasks
Target Total Defects Target Total Effective Time Target Total Ineffective Time
Target Total Time Task Percentage Defect Percentage
Effective Time Percentage Ineffective Time Percentage Time Percentage
State columns display statistics grouped by workflow states. All workflow progress states are user defined.
State Group Columns
Status Group columns display the number of records that fall into each state group. All state groups are defined by project administrators in the Status Group page in DevTest Admin.
Percentage State Group Columns
% Status Group columns display the percentage of records that fall into each state group.
Percentage State Group Over Target Columns
% Status Group Over Target columns display the percentage of records that fall into each state group against the percentage projected in the target data.
Project administrators can customize the appearance of these columns in each summary report:
• Select the columns that appear in each summary report type.
• Select the display name for all columns that appear in Test Planning summary reports.
Project administrators may use tools provided in the Page Setting page to add or remove summary reports from the summary report panel in the planning view.
Planning view summary reports display statistical data from releases or test cycles in a tabular format. Project administrators may add or remove four different types of summary reports to the planning detail panel of the planning view: Summary, Environment, Test Coverage, and Team summary reports
To add or remove summary reports:
1Select the Page Setting page in the Planning Summary Pages subfolder of the Planning View GUI Settings folder in a work project. Planning summary reports may be customized on a project-by-project basis.
2Add or remove summary reports.
• To display a summary report in the planning view, select the report in the Available Pages list and click the Right arrow button to move it to the Summary Pages list.
• To remove a summary report from the planning view, select the report in the Summary Pages list and click the Left arrow button to move it to the Available Pages list.
Project administrators may use controls in the Planning Summary Report Page Settings page to define the refresh options for the summary reports displayed in the Planning Report window.
Planning summary reports may be refreshed automatically or manually in the DevTest client depending on properties defined by an administrator.
• The Automatic option refreshes the summary reports displayed in the Planning Report window whenever the project member selects a folder in the Planning Tree window or Template Tree window.
• The Manual option refreshes the summary reports displayed in the Planning Report window only when the project member clicks the Refresh button in the DevTest client.
In the DevTest client summary reports are displayed in the Reports view and in the Planning view. The summary reports in the Planning view enable project members to view statistical results for each release and test cycle. Project members may filter the results displayed in the Report window by selecting folders in the Planning Tree window and Template Tree windows.
To define Summary Report refresh options:
1Select the Planning Summary Page Settings page in the Admin tree menu.
2Define Summary Report refresh options in the Planning Summary Page Refresh Option area.
• Select the Automatically radio button to enable automatic refreshing of summary reports in the Planning view.
• Select the Manually radio button to enable manual refreshing of summary reports in the Planning view.
Using the Name Setting page in DevTest Admin, project administrators can change the display name for all columns that appear in Planning summary reports.
To define Summary Report Column display names:
1Select Planning View GUI Settings > Planning Summary Pages > Name Setting in the work project tree menu.
The Name Setting page appears.
2Select a Column Name in the Column list.
3Click the Edit button.
The Edit Column Name dialog box appears.
4Enter a name in the Display Column Name field.
5Click the OK button.
The new column name replaces the old column name in the Column list.
The summary reports shows high-level testing data in a tabular format of columns and rows. In the summary report, report data is organized by release cycle and test cycle.
The team summary report may be displayed in the Team tab of the planning detail panel of the planning view.
Using controls in the Summary page in the Planning Summary Pages folder, project administrators may add or remove columns from the team summary reports, define the order that columns are displayed in the report.
To add or remove columns to summary reports:
1Select the Summary page in the Column Setting subfolder of the Planning View GUI Settings folder in a work project.
2Add or remove columns.
• To add columns to the report, select the column name in the Available Columns list and click the Right arrow button to move it to the Summary Page Columns list.
• To remove columns to the report, select the column name in the Summary Page Columns list and click the Left arrow button to move it to the Available Columns list.
To order columns in summary reports:
1Select the Environment page in the Column Setting subfolder of the Planning View GUI Settings folder in a work project.
2Select a column in the Summary Report Columns list.
3Move the column up or down in the report.
• To move the column forward in the report (towards the left), click the Up arrow button.
• To move the column down in the report (towards the right), click the Down arrow button.
The summary reports shows high-level testing data in a tabular format of columns and rows. In the summary report, report data is organized by release cycle and test cycle.
The team summary report may be displayed in the Team tab of the planning detail panel of the planning view.
Using controls in the Summary page in the Planning Summary Pages folder, project administrators may add or remove columns from the team summary reports, define the order that columns are displayed in the report.
To add or remove columns to summary reports:
1Select the Summary page in the Column Setting subfolder of the Planning View GUI Settings folder in a work project.
2Add or remove columns.
• To add columns to the report, select the column name in the Available Columns list and click the Right arrow button to move it to the Summary Page Columns list.
• To remove columns to the report, select the column name in the Summary Page Columns list and click the Left arrow button to move it to the Available Columns list.
To order columns in summary reports:
1Select the Environment page in the Column Setting subfolder of the Planning View GUI Settings folder in a work project.
2Select a column in the Summary Report Columns list.
3Move the column up or down in the report.
• To move the column forward in the report (towards the left), click the Up arrow button.
• To move the column down in the report (towards the right), click the Down arrow button.
In DevTest, all tests are managed and tracked astest tasks. A test task is an instance of a test template that may be used to test a feature in a specific environment.
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.
Test tasks not only define test procedures and expected results, they also enable testers to record the result of those tests and other testing data. As test templates are fully customizable, testing groups may define templates that may be used to track a wide range of testing information— all information may be tracked and reported.
Each test task give testers what they need to run tests A test task typically consists of a procedure, an expected result, and other properties such as instructions for setting up the test environment. Information may be presented to testers in the test task itself through test task notes or attached to the test task. Knowledge items may be attached directly to a test task or attachments may be inherited by test task from the test template used to generate it. Key knowledge items such as test plans are always at the testers fingertips.
Work project administrators may customize six function pages that are displayed in the test task view of a DevTest work project—Edit Test Task page, the Test Task Detail page, the Forward Test Task page, the Override Test Task page, the Group Change Test Task page, and the Group Forward Test Task page.
A function page is a GUI element that enables the user to perform a specific action such as submitting, updating, or forwarding a record. In the DevTest client, a function page as a multiple-page tabbed form called amanager. Each function page may display multiple system and custom pages.
Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages.
In the DevTest client, test team members may update and manage test task properties in the Edit Test Task manager, a multiple-page tabbed form that may display multiple system or custom pages.
Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages.
The following system pages may be added to the Edit Test Task function page:
• Notes system page
• TestLink system page
To customize task editing function page:
1Select the Editing page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Tasks Editing page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
In the DevTest client, the task detail panel displays detailed information about a single test task in multiple tabbed pages. Using controls in the task detail panel, test team members may update and manage test task properties.
The test task detail panel represents a customized task detail function page that may display multiple system or custom pages as tabbed pages. Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages.
The following system pages may be added to the Edit Test Task function page:
• Notes system page
• Linked Defect system page
• History system page
• TestLink system page
To customize the task detail function page:
1Select the Detail Pages page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Test Task Detail page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
The Task Forward function page in the Task view of a work project enables work project members to forward test tasks to other project members.
No system pages may be added to the Test Task Forward function page.
To customize task forward pages:
1Select the Forward Pages in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Test Task Forward function page appears.
2Add or remove custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
Project members use the override pages to change test task properties defined in the planning wizards.
The Override function page enables work project administrators to create the Override tabbed forms. Project administrators can add to the Override function page custom pages that contain data entry controls. The Override function page enables you to change any settings that are defined in the controls on that page.
Project administrators may add an unlimited number of custom pages to the Override function page. Project administrators cannot add system pages to the Override function page.
To customize override pages:
1Select the Editing page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Override function page appears.
2Add or remove custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
The Task Group Change function page in the Task view of a work project enables work project members to update test task properties.
No system pages may be added to the Test Task Group Change function page.
To customize task group change pages:
1Select the Editing page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Test Task Group Change function page appears.
2Add or remove custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
The Task Group Forward function page in the Task view of a work project enables work project members to forward and update groups of test tasks.
No system pages may be added to the Test Task Group Forward function page.
To customize task group forward pages:
1Select the Editing page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Test Task Group Forward function page appears.
2Add or remove custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
In the DevTest client, test team members may update and manage test task properties in the Edit Test Task manager, a multiple-page tabbed form that may display multiple system or custom pages.
Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages.
The following system pages may be added to the Edit Test Task function page:
• Notes system page
• TestLink system page
To customize task editing function page:
1Select the Editing page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Tasks Editing page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
The test task list panel displays high-level information about multiple test tasks in a tabular format of rows and intersecting columns. Project administrators may determine which list columns are displayed in the test task list panel by default in the Test Task List Column page.
Test task list panel columns include the following test task properties:
Actual Setup Time Actual Test Time Assigned by
Closed by Created by Date Assigned
Date Closed Date Created Date Last Modified
Days Open Days To Finish Date Days To Start Date
Environment E. Setup Time E. Test Time
Last Modified by Plan Finish Date Plan Start Date
Task Owner
Template Folder Path Template ID Template Order
Test Task Folder Name Test Task Folder Path Task ID
Title
Project administrators may only define thedefaultsettings for each project. Individual project members may customize the test task list panel to display the test task properties that are most useful to them.
To customize the test task list panel:
1Select the Test Task List Column page in the Field Design subfolder of the Test Task GUI Settings folder in a work project.
The Test Task Column Settings page appears.
2Add or remove columns by moving them between the Available Data Fields list and the Select List Columns list.
• To add columns to the Test Task List window highlight options in the Available Data Fields list and click the Right arrow to move them to the Select List Columns list.
• To remove columns from the Test Task List window highlight options in the Select List Columns list and click the Left arrow to move them to the Available Data Fields list.
3Click the OK button.
The test task list panel displays high-level information about multiple test tasks in a tabular format of rows and intersecting columns. Each column represents a test task. Each column represents a test task property such as its ID number, title, task owner, and environment.
Indicator icons enable test team members to quickly identify the test tasks that are important to them differentiating those tasks from the other tasks in the list. Each test task is flagged by an icon that carries a specific significance.
Specific icons may be assigned to test tasks based on incident property values. Indicator icons may be assigned to test tasks based on four test task incident properties:
• The Script Type
• The Task Owner
• The
• The Test Execution Type
To define test task indicator icons:
1Select the Test Task List Column page in the Field Design subfolder of the Test Task GUI Settings folder in a work project.
The Test Task Column Settings page appears.
2Click the List View Graphic Display Settings button.
The List View Graphic Display Settings dialog box appears.
3Select an option in the Indicator Field List dropdown list.
The Indicator Field List dropdown list displays five options:
• {None}
• Script Type
• Task Owner
•
• Test Execution Type
4Select a test task property in the the Available Options list.
The icon options displayed are determined by the indicator field selected. The Available Options list displays one icon for each property value of the selected test task property.
5Click the Select Icon button.
The Select an Icon dialog box appears.
6Select an icon.
7Click the OK button.
The Select an Icon dialog box closes.
8Click the OK button.
The List View Graphic Display Settings dialog box closes.
The test task list panel displays high-level information about multiple test tasks in a tabular format of rows and intersecting columns. Each column represents a test task. Each column represents a test task property such as its ID number, title, task owner, and environment.
Text formatting may be used to enable test team members to quickly identify the test tasks that are important to them by highlighting certain test tasks in the list based on test task property definitions.
Text colors and boldfacing may be assigned to test tasks based on four test task incident properties:
• The Script Type
• The Task Owner
• The
• The Test Execution Type
To define test task text formatting:
1Select the Test Task List Column page in the Field Design subfolder of the Test Task GUI Settings folder in a work project.
The Test Task Column Settings page appears.
2Click the List View Graphic Display Settings button.
The List View Graphic Display Settings dialog box appears.
3Select an option in the Indicator Field List dropdown list.
The Indicator Field List dropdown list displays five options:
• .{None}
• Script Type
• Task Owner
•
• Test Execution Type
4Select a test task property in the the Available Options list.
The icon options displayed are determined by the indicator field selected. The Available Options list displays one icon for each property value of the selected test task property.
5Optional: To display test tasks in boldface in the test task list, select the Text Bolded check box.
Only those test tasks that match the selected property value are displayed in boldface.
6Optional: To display colored test task text in the test task list, select a color option from the Text Color dropdown list.
The Text Color dropdown list displays the following options:
Black White Red
Green Yellow Blue
Purple Dark Red Dark Green
Light Brown Dark Blue Dark Cyan
Light Gray Gray Magenta
Cyan Automatic
Only those test tasks that match the selected property value are displayed in the selected color.
7Click the OK button.
The List View Graphic Display Settings dialog box closes.
In the DevTest client, the task detail panel displays detailed information about a single test task in multiple tabbed pages. Using controls in the task detail panel, test team members may update and manage test task properties.
The test task detail panel represents a customized task detail function page that may display multiple system or custom pages as tabbed pages. Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages.
The following system pages may be added to the Edit Test Task function page:
• Notes system page
• Linked Defect system page
• History system page
• TestLink system page
To customize the task detail function page:
1Select the Detail Pages page in the Function subfolder within the Test Task GUI Settings folder in a work project.
The Test Task Detail page appears.
2Add or remove system or custom pages to the function page.
• To add pages select a page in the Available Pages list and click the Right arrow button.
• To remove pages select a page in the Working Pages list and click the Left arrow button.
3 Optional:To change the title of the function page, enter a new title in the Page Display Name field.
4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button.
In DevTest work projects task states drive workflow rules. Any change to the task state of a test task may change the rules that govern that test task.
The administrator-defined workflow rules are based on task states or state-to-state transitions. The ownership of a test task and the ability of project members to view or update a record depend on its workflow state.
All task states are defined by the template project administrator of the parent template project (the template base). Once the task states have been created, individual work project administrators may define workflow rules based on these task states in their projects. All workflow rules are specific to the project in which they are defined.
In the DevTest Sample Work Project five workflow states represent the results of product testing during a test cycle. A typical shop may define project workflow using states that are similar to these five workflow states:
• Blocked
• Did Not Run
• Fail
• In Progress
• Pass
The workflow states in the DevTest sample project represent only some of the options available to project teams to manage workflow in a template project. Each project team may customize their workflow to match their own business processes.
Verification points are an optional feature in DevTest that enable project teams to test an application’s performance during a test cycle against multiple checkpoints during a test cycle.
In DevTest work projects workflow states drive workflow rules. Any change to the workflow state of a test task may change the workflow rules which govern that test task or may trigger events administrator-defined workflow rules.
In a work project all workflow states may be changed by one of two methods based on whether verification points are used in the project.
• If a test task displays a single expected result (checkpoint) in the Expected Results field of the Task Description page, the test task owner may indicate the success or failure of the test task by manually changing the workflow state of the test task using the
• If a test task displays multiple expected results (verification points) in the Expected Results field of the Task Description page, the test task owner must indicate the success or failure of the tested application against each verification point. Administrator-defined dependency rules determine the overall success of the test task based on cumulative results of the checkpoints and automatically change the workflow state of the test task.
The State to State Transition option enables the administrators to define workflow rules which manage the transitions between task states. State-to-state workflow rules restrict task state changes.
The Applicable Owners option enables project administrators to specify the user accounts, account types, and groups that may own a test task based on its task state. Applicable owner workflow rules enable the administrator to ensure that test tasks are only assigned or forwarded to a designated applicable owner.
The Read-Only Fields option enables project administrators to designate fields as read only in particular task states. If this option is enabled, read-only workflow rules may be defined that prevent fields from being updated when a test task is in certain task states.
The Invisible Fields option enables project administrators to designate test task fields as invisible when that test task is in certain task states. Enabling State-to-State Transitions
The Mandatory Fields option enables project administrators to designate test task fields as mandatory when that test task is in certain task states.Mandatory fields must be completed before the task state of the test task can be changed.
The Who Can Change option enables project administrators to restrict which project members may make changes to test tasks based on their workflow states. Who Can Change rules may be based on the current workflow state of the test task, or they may be based on state transitions.
If the State-to-State Transition option has been enabled, the administrator may select a workflow option from the Who Can Change dropdown list.
• Current state workflow rules limit who can change task states based on the current state of the test task.
• Transition workflow rules define who can change task states based on state-to-state transitions.
The Enable Triggering Defect Submission property enables project administrators to set triggers for automatically generating DevTrack issues whenever a test task record changes to a particular workflow state. If enabled, this property automatically creates DevTrack issues. DevTest-DevTrack integration must be enabled to use this feature.
Work project administrators may use tools in the State Transition tab of the Settings page to define transitions between task states in work projects.
State transition workflow rules enable administrators to ensure that project members may only change the task state of test tasks to appropriate states. For example, administrators may define state transition workflow rules ensure that project members can only change the workflow state of a test task from State A to State B and not from State A to State C.
Administrators may subsequently define Who Can Change workflow rules for all state-to-state transitions.
Administrators may only define state transition workflow rules if they have enabled the State-to-State Transition workflow option in the Options page.
To define state transition workflow rules:
1Select the Settings page beneath the State& Workflow folder in the Tree window.
The Settings page appears.
2Select the State Transition tab.
The State Transition page appears.
3Highlight a workflow state in the
4Select test tasks in the
5The options displayed in the
Work project administrators may use tools in the Applicable Owner tab of the Settings page to applicable owner rules and default applicable owners for test tasks.
• Applicable owner rules determine which project members may own a test task based on the task state of the test task.
• Default applicable owners are the default owners for test tasks in a particular task state.
An applicable owner may be a user, an account type, a member of a group or group folder, or any of a number of a predefined system users (Unassigned, Submitter, Current Owner and Previous Owner).
Ownership means a user has privileges and responsibilities for the test task that other users do not have. Applicable owner workflow rules enable managers to direct test tasks to individuals or teams with particular skills or expertise.
Work project administrators may enable test task ownership for five different types of applicable owners: account types, groups, group folders, system applicable owners, and user accounts.
• An account type applicable owner represents an administrator-defined account type.
• A group applicable owner represents an administrator-defined group of account types.
• A group folder applicable owner represents an administrator-defined group of account types.
• System applicable owners represent system variables that may be assigned ownership of test tasks in particular task states. Administrators may enable five different types of system applicable owners: {Unassigned], {Submitter}, {Current Owner}, and {Previous Owner}.
• A user applicable owner represents a user account.
Administrators may only define applicable owner workflow rules if they have enabled the Applicable Owner workflow option in the Options page.
To define applicable owners workflow rules:
1Select the Settings page beneath the State& Workflow folder in the Tree window.
The Settings page appears.
2Select the Applicable Owners tab.
The Applicable Owners page appears.
3Select a task state in the
4Select all appropriate workflow applicable owners in the Applicable Owners list.
Administrators may assign as many applicable owners as needed for each task state.
5Select a default applicable owner option in the Default Owner dropdown list.
Default applicable owners are by default responsible the test tasks in each workflow state.
Project administrators may define applicable owner workflow rules using controls in the User Manager. The User Profile page in the User manager enables administrators to define or update applicable owner rules for each user account across all task states.
Applicable owner workflow rules determine which project members may own a test task in a particular task state.
All changes made to the profile of a user account in the User Manager are immediately implemented in project workflow rules.
To apply ownership in the user profile:
1Select System > User Manager in the tool menu.
The User Manager appears.
2Select a project member in the User Manager.
3Click the Profile button.
The User Profile page appears.
4Click the Workflow page.
The Workflow tab allows users to specify applicable ownership rules for the selected user. All predefined workflow states will be listed in the window.
5Select the appropriate test task states.
The user may own test tasks in all selected task states.
6Click the OK button.
Work project administrators may use tools in the Who Can Change tab of the Settings page to define which project members may change the task state of a test task.
Who Can Change workflow rules are based either on task states or the transition between task states.
• Current state workflow rules designate which project members may change task states based on the current state of the test task.
• Transition workflow rules designate which project members may change task states based on the transitions between tasks states.
Administrators may grant project members the ability to change the task state of test task based on either on current states or on the transitions between task states.
The workflow rules defined in the Who Can Change tab depend on the Who Can Change option selected by the project administrator in the Options page.
• If the administrator has enabled the Based on the
• If the administrator enabled the Based on State Transition option in the Options page, Who Can Change workflow rules restrict the options available to project members when they change the task state of test tasks.
Note:Account type privileges override the Who Can Change workflow rules. Even though administrator-defined Who Can Change workflow rules may entitle a project member to change task states, that project member may only change the task state of task states for which they have been granted the edit privilege, based on theiraccount type.
Administrators may only define who can change workflow rules if they have enabled the Who Can Change workflow option in the Options page.
To define current state workflow rules:
1Select the Settings page beneath the State & Workflow folder in the Tree window.
The Settings page appears.
2Select the Who Can Change tab.
The Who Can Change page appears.
3Select a task state in the
4Select one or more project members in the Member Name field.
The selected project members may change the task state of a test task when that test task is in the current task state.
To define transition workflow rules:
1Select the Settings page beneath the State & Workflow folder in the Tree window.
The Settings page appears.
2Select the Who Can Change tab.
The Who Can Change page appears.
3Select a task state in the
4Highlight a task state in the
The options displayed in the
5Select one or more project members in the Member Name list.
The selected project members may change the task state of a test task from the task state selected in the
Work project administrators may use tools in the Read-Only Fields tab of the Settings page to designate certain test task fields as read-only to project members whenever that test task is in a particular task state.
To define read-only workflow rules:
1Select the Setting page beneath the State & Workflow folder in the Tree window.
The Settings page appears.
2Select the Read Only Fields page.
The Read Only Fields page appears.
3Select a task state in the
4Select one or more fields in the Read Only field.
The selected fields are designated as read-only fields for all project members when test tasks are in the selected task state.
Work project administrators may use tools in the Invisible Fields tab of the Settings page to designate certain test task fields as invisible to all project members based on the task state of the test task.
To define invisible field workflow rules:
1Select the Setting page beneath the State & Workflow folder in the tree menu.
The Settings page appears.
2Select the Invisible Fields page.
The Invisible Fields page appears.
3Select a task state in the
4Select one or more fields in the Invisible Fields field.
The selected fields will be invisible to all users when a test tasks is in the selected task state.
Work project administrators may use tools in the Mandatory Fields tab of the Settings page to define certain test task fields in test tasks as mandatory to all project members based on the task state of the test task.
Mandatory fields must be completed by a project members before the task state of the test task can be changed another task state.
Administrators may define mandatory fields in the Description,
To define mandatory fields workflow rules:
1Select the Setting page beneath the State & Workflow folder in the tree menu.
The Settings page appears.
2Select the Mandatory Fields page.
The Mandatory Fields page appears.
3Select a task state in the
4Select one or more fields in the Mandatory Fields field.
The selected fields are designated as mandatory to all users when a test task is in the selected task state.
Work project administrators may use tools in the Mandatory Fields tab of the Settings page to define certain test task fields in test tasks as mandatory to all project members based on the task state of the test task.
Mandatory fields must be completed by a project members before the task state of the test task can be changed another task state.
Administrators may define mandatory fields in the Description,
To define mandatory fields workflow rules:
1Select the Setting page beneath the State & Workflow folder in the tree menu.
The Settings page appears.
2Select the Mandatory Fields page.
The Mandatory Fields page appears.
3Select a task state in the
4Select one or more fields in the Mandatory Fields field.
The selected fields are designated as mandatory to all users when a test task is in the selected task state.
All DevTest processes are managed in two applications: DevTest Admin and the DevTest clients.
• DevTest Admin enables administrators to create, manage, and customize DevTest projects.
• The DevTest client enable project members to work in DevTest projects. Project members may log into DevTest projects using either the Windows client or the Web client applications.
DevTest Admin is an application that enables administrators to manage system-level settings and to configure, customize, and manage DevTest projects.
Figure 10-1: DevTest Admin GUI
Thegraphical user interface(GUI) of the DevTest Admin application consists of two panels: the Admin Tree panel and the Page panel.
• The Admin Tree panel enables administrators to select the page displayed in the Admin Page panel. The folders and pages displayed in the Admin Tree panel are project-specific.
• The Admin Page panel enables administrators to define project settings.
All administrative tasks are managed by two types of administrators:
• System administrators are responsible for defining system-level settings and for enabling functions that are used across an entire DevTest implementation: knowledge projects, template projects, and work projects.
• Project administrators are responsible for defining project membership and workflow rules, and for customizing the graphical user interface of DevTest projects. Each DevTest project may have its own project members and workflow rules.
The DevTest client is an application that enables project members to work within DevTest projects.
Project members may log into and work in three types of projects using the DevTest client applications: knowledge projects, template projects, and work projects. Each project consists of one or more views. A view is a graphical user interface that enables project members to work within a project.
DevTest provides two different types of client applications:
• The DevTest Windows client
• The DevTest Web client
The DevTest Windows client application enables project members to log into project using a client application running on the Microsoft Windows operating system.
Figure 10-2: DevTest Windows Client
The DevTest web client enables project members to log into projects using a web browser.
Figure 10-3: DevTest Web Client
The DevTest web client is a thin client that connects to the DevTest Web Server over the Internet. Using DevTest Web does not require users to install any additional software on their local machine—all that is needed is a web browser. All processing is performed by the DevTest Web Server.
DevTest Web may be accessed using the following web browsers:
• Mozilla Firefox 1 and above
• Microsoft Internet Explorer 5.0 and above
• Netscape Navigator 6.0 and above
• Apple Safari 2 and above
Every task that may be performed in the DevTest Windows client may be performed in the DevTest Web client.
To log into and work in a DevTest project a user must be a member of that project. Project membership is defined by a project administrator of each project in DevTest Admin.
DevTest Admin is an application that enables administrators to manage system-level settings and to configure, customize, and manage DevTest projects.
Figure 10-1: DevTest Admin GUI
Thegraphical user interface(GUI) of the DevTest Admin application consists of two panels: the Admin Tree panel and the Page panel.
• The Admin Tree panel enables administrators to select the page displayed in the Admin Page panel. The folders and pages displayed in the Admin Tree panel are project-specific.
• The Admin Page panel enables administrators to define project settings.
All administrative tasks are managed by two types of administrators:
• System administrators are responsible for defining system-level settings and for enabling functions that are used across an entire DevTest implementation: knowledge projects, template projects, and work projects.
• Project administrators are responsible for defining project membership and workflow rules, and for customizing the graphical user interface of DevTest projects. Each DevTest project may have its own project members and workflow rules.
The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects.
Every DevTest implementation must consist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical.
• Each knowledge project is the parent of one or more child template projects.
• Each template project is the parent to one or more child work projects.
• Each work project is the child of a template project.
The project hierarchy enables project members to use views to access and work within a parent project from within any child project. A view is a graphical user interface (GUI) that enables project members to access and perform tasks in a project. Each project type consists of one or more views. Each DevTest project is comprised of one or more views that enable project members to plan, manage, and execute testing processes.
All DevTest projects within a DevTest implementation have a relationship to other projects based on their place within the project hierarchy. Each project is either a parent project, a child project, or a sibling project to other projects.
• A parent project forms the basis for many child projects. The child project has visibility to the parent project through views and inherits customizations made to the parent project. Each knowledge project is the parent to many template projects which, in turn, are the parent to many work projects.
• A child project is based upon a parent project and inherits customizations made to the parent project. All work projects are children of a parent test template project. Work projects share the test template created in that project and have access to the test template project through the Template view.
• A sibling project shares a common parent project with other projects of the same project type. All of the work projects based on the same template project are siblings of one another. Sibling project do not have visibility to the views in other sibling projects and do not inherit customizations made to their siblings.
All of the projects in a DevTest integration stand in a hierarchical relationship with one another. Their place in that hierarchy and the customizations made to their parent projects determine the functionality.
Figure 10-4: DevTest Project Relationships
The project hierarchy and customizations
The project hierarchy enables work project administrators to customize each project to meet their individual business needs without affecting other projects.
• Customizations made to a parent project are visible in all child projects through views.
• Customizations made in child project are not visible in parent projects.
• Customizations made in a project are not visible in any sibling project.
In DevTest multiple work project testing teams may share the same template base structures and test templates and still define their own team members and workflow rules, and track project-specific data independently.
Because each work project is a sibling of every other work project based on the same template project, they share the same template structures, but project membership and workflow rules are completely independent.
Knowledge projects provide project teams with a central repository for storing and managing information collected throughout a DevTest implementation.
Knowledge projects enable project teams to manage knowledge items. A knowledge item is a document, HTML link, or topic that is created and managed in the Knowledge view.
Every DevTest implementation must include at least one knowledge project. A knowledge project is the foundation, the knowledge base, for multiple template projects and work projects. Each knowledge project is the parent to one or more template projects and the grandparent to one or more work projects.
A knowledge base is a central repository that enables members of various projects to store and exchange general information relevant throughout a DevTest implementation.
The Knowledge view in a child template project or grandchild work project provides project members with direct access to a parent knowledge project.
Template projects enable project teams to create, organize, and manage test templates for multiple work projects.
Test templates are the master copies (test plans) of the test procedures (test tasks) that QA engineers use to execute product testing in DevTest work projects. Each template project is the parent of multiple child work projects, and the test templates created in the parent template project may be used to create test tasks in the child work projects.
• Test template enable project teams to save time and effort by building environmental variables into their test templates and using these test templates to create multiple test tasks.
• Test templates enable project teams to enforce standardization in test tasks across all child work projects.
Every DevTest implementation must include at least one template project. Each template project is the foundation (the template base) for multiple work projects. Child work projects may use test templates created in a parent template project to create test tasks.
Work projects enable project teams to plan manage, execute, and track product testing by product, release cycle, and test cycle.
The tools available in a work project enable project members to manage test tasks. A test task is the basic element for all DevTest processes and provides project teams the means of planning and tracking individual tests performed in DevTest.
Each test task is based on a test template created in a parent template project.
Each work project is comprised of three separate views that project members may use to manage different aspects of product testing.
• Test planning
• Test execution
• Test reporting
The DevTest client is an application that enables project members to work within DevTest projects.
Project members may log into and work in three types of projects using the DevTest client applications: knowledge projects, template projects, and work projects. Each project consists of one or more views. A view is a graphical user interface that enables project members to work within a project.
DevTest provides two different types of client applications:
• The DevTest Windows client
• The DevTest Web client
The DevTest Windows client application enables project members to log into project using a client application running on the Microsoft Windows operating system.
Figure 10-2: DevTest Windows Client
The DevTest web client enables project members to log into projects using a web browser.
Figure 10-3: DevTest Web Client
The DevTest web client is a thin client that connects to the DevTest Web Server over the Internet. Using DevTest Web does not require users to install any additional software on their local machine—all that is needed is a web browser. All processing is performed by the DevTest Web Server.
DevTest Web may be accessed using the following web browsers:
• Mozilla Firefox 1 and above
• Microsoft Internet Explorer 5.0 and above
• Netscape Navigator 6.0 and above
• Apple Safari 2 and above
Every task that may be performed in the DevTest Windows client may be performed in the DevTest Web client.
To log into and work in a DevTest project a user must be a member of that project. Project membership is defined by a project administrator of each project in DevTest Admin.
The Knowledge view enables project members to view and manage knowledge items in a knowledge project.
The Knowledge view GUI consists of three panels: the Knowledge Tree panel, the Knowledge List panel, and the Knowledge Detail panel.
Figure 10-6: Knowledge View
The Knowledge view provides project members with tools to manage all project-related documents including internal design documents, system requirements, user specifications, test cases, and even HTML links.
• The Knowledge Tree panel enables project members to organize knowledge items in knowledge folders.
• The Knowledge List panel enables project members to view high-level information about multiple knowledge items.
• The Knowledge Detail panel enables project member to view and update information about a single knowledge item.
Project members may access a knowledge project using the Knowledge view in any child template project or work project. Knowledge view access privileges may be granted to account types in template projects and work projects.
The Template view enables project members to view and manage test templates in a template project.
The Template view GUI consists of three panels: the Template Tree panel, the Template List panel, and the Template Detail panel.
Figure 10-7: Template View
A template project enables project members to manage the development and distribution of test templates in a DevTest implementation.
• The template tree panel enables project members to organize test templates in template folders, to select applicable environmental variables, and to define applicable projects for the test templates contained in template folders.
• The template list panel enables project members to view high-level information about multiple test templates.
• The template detail panel enables project members to view and update information about a single test template.
Project members may access a template project using the Template view in any child work project. To view and access the template project, the user must be a member of the parent template project and be assigned appropriate privileges by the template project administrator.
The planning view enables project members to generate test tasks from test templates, organize test tasks in planning folders, assign test tasks, and track testing performance in a work project.
The Planning view GUI consists of three panels: the Planning Tree panel, the Planning List panel, and the Planning Summary Statistics panel.
Figure 10-8: Planning View
• The planning tree panel enables project members to generate and organize test tasks in product, release cycle, and test cycle folders.
• The template tree panel enables project members to filter the test tasks displayed in the Planning List panel by test template. The Template Tree panel displayed in the Planning view is identical to the Template Tree panel displayed in the Template view of the parent template project. The Template Tree panel is optional in the Planning view. Project members may choose to display or hide this panel.
• The planning list panel enables project members to view high-level information about multiple test tasks.
• The planning summary statistics panel enables project members to view summary statistics based on the results of product testing.
To view and access the Planning view of a work project, the user must be a member of that work project and be assigned appropriate privileges by the work project administrator.
The Planning view of a child work project is only accessible within a work project. Project members may not be access the Planning view from parent template project or knowledge project.
The task view enables project members to view and manage test tasks in a work project.
The Task view GUI consists of three panels: the Task Tree panel, the Task List panel, and the Task Detail panel.
Figure 10-9: Task View
The Task view provides project members with tools to update and manage information gathered during a test cycle in test tasks.
• The task tree panel enables project members to filter the test tasks displayed in the Task List panel by product, release cycle, or test cycle folder. The Task Tree panel is identical to the Planning Tree panel created and managed in the Planning view.
• The template tree panel enables project members to filter the test tasks displayed in the Task List panel by test template. The Template Tree panel displayed in the Task view is identical to the Template Tree panel displayed in the Template view of the parent template project. The Template Tree panel is optional in the Task view. Project members may choose to display or hide this panel.
• The task list panel enables project members to view high-level information about multiple test tasks.
• The task detail panel enables project members to view and update detailed information about a single test task.
To view and access the Task view of a work project, the user must be a member of that work project and be assigned appropriate privileges by the work project administrator.
Project members may not access the Task view of a work project from parent template project or knowledge project.
The Report view enables project members to create and manage reports based on project data.
The Report view consists of two panels: the Report Tree panel and the Report panel.
Figure 10-10: Report View
The Report view provides project members with tools to create and manage presentation-quality reports and graphs based on project data.
• The report tree panel enables project members to organize public and private reports in report folders.
• The report panel displays reports in the DevTest client.
The reports that project members create and manage in the Report view are project-specific.
• When a project member accesses the Report view within a template project they access the Template Report view. The Template Report view enables project members to run reports based on template project data.
• When a project member accesses the Report view within a work project they access the Task Report view. The Task Report view enables project members to run reports based on work project data.
The DevTrack view enables project members to manage DevTrack product defect issues from within an integrated DevTest work project.
The DevTrack view is optional and is only displayed in DevTest work projects that have been integrated with a DevTrack project.
The DevTrack view consists of two panels: the Product Defect Tree panel and the Product Defect Detail panel.
Using tools in the DevTrack view project members may manage DevTrack product defect issues within a DevTest work project.
• The Product Defect List panel enables project members to view high-level information about multiple DevTrack issues.
• The Product Defect Detail panel enables project members to view detailed information about a single DevTrack product defect issue.
To view and access the DevTrack view of a work project, the user must be a member of that work project and be assigned appropriate privileges by the work project administrator.
Project members may not be access the DevTrack view from parent template project or knowledge project.
Project members may use tools in the DevTest client to organize, manage, and track testing processes in projects.
DevTest enables project teams to create three different types of projects. Each project type provides users with the views and tools that a project team may use to manage an aspect of the testing process.
• Knowledge projects enable project teams to collect and manage information gathered across multiple template projects and work projects. Knowledge project members may manage knowledge items in the knowledge project.
• Template projects enable project teams to create and manage test templates that may used to create test tasks in multiple work projects. Template project members may manage test templates in a template project.
• Work projects enable project teams to plan and execute test cycles using test tasks that have been generated from test templates created in a parent test template project. Work project members may manage test tasks in the work project.
The tree panel is an organizational tool that enables project members to manage DevTest records in a hierarchy of folders.
Five DevTest views feature a tree panel that enables project members to work with the records managed in that view:
• The Template Tree panel enables project members to manage test template records in test template folders.
• The Planning Tree panel enables project members generate test tasks based on test templates and manage test tasks in product folders, release folders, and test cycle folders. The tree structure of every work project is created and managed in the Planning view of that project.
• The Task Tree panel enables project members to filter the test tasks displayed in the Task List panel. The Task Tree panel displayed in the Task view is identical to the Planning Tree panel displayed in the Planning view of the same work project.
• The Report Tree panel enables project members to manage reports in report folders.
• The Knowledge Tree panel enables project members to manage knowledge items in knowledge folders.
Tree panels are particularly useful as a tool for filtering the records displayed in the list panel of a view.
The root folder for each view appears at the top of the menu and all subordinated folders appear underneath.
List panels display high-level information about DevTest records in rows and columns.
• Each list panel row represents a DevTest record.
• Each list panel column represents a record property and displays record property values.
The List panel is a key feature of the Knowledge view, the Template view, the Planning view, the Task view, and the DevTrack view.
• The Knowledge List panel displays knowledge items (documents, topics, HTML Links, and attachments).
• The Template List panel displays test templates.
• The Planning List panel displays test tasks.
• The Task List panel displays test tasks.
• The DevTrack List panel displays product defect issues.
Project members may personalize the List panel in their DevTest client. The User Preferences Manager enables them to choose which columns appear in the List panel.
The Detail panel display one or more form pages. Each form page enables project members to view, add, and update record properties.
The Detail panel is a key feature of the Knowledge view, the Template view, and the Task view.
• The knowledge detail panel displays detailed information about a single knowledge item. Project members may use the pages in the Knowledge Detail panel to update knowledge item property values.
• The template detail panel displays detailed information about a single test template. Project members may use the pages in the Knowledge Detail panel to update test template property values.
• The task detail panel displays detailed information about a single test task. project members may use the pages in the task detail panel to update test task property values.
Project administrators may add, remove, or customize the pages displayed in the Template Detail panel of the Template view and the Task Detail panel of the Task view. The Detail panel displays two types of pages: system pages and custom pages.
Project administrators may add an unlimited number of custom pages to the Detail panel. The number of system pages that may be added is restricted by the view.
Template Detail Panel Linked Task system page
History system page
Notes system page
Snapshot system page
Environmental Variable system page
TestLink system page
Task Detail Panel Linked Defect system page
Notes system page
History system page
TestLink system page
The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects.
Every DevTest implementation must consist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical.
• Each knowledge project is the parent of one or more child template projects.
• Each template project is the parent to one or more child work projects.
• Each work project is the child of a template project.
The project hierarchy enables project members to use views to access and work within a parent project from within any child project. A view is a graphical user interface (GUI) that enables project members to access and perform tasks in a project. Each project type consists of one or more views. Each DevTest project is comprised of one or more views that enable project members to plan, manage, and execute testing processes.
All DevTest projects within a DevTest implementation have a relationship to other projects based on their place within the project hierarchy. Each project is either a parent project, a child project, or a sibling project to other projects.
• A parent project forms the basis for many child projects. The child project has visibility to the parent project through views and inherits customizations made to the parent project. Each knowledge project is the parent to many template projects which, in turn, are the parent to many work projects.
• A child project is based upon a parent project and inherits customizations made to the parent project. All work projects are children of a parent test template project. Work projects share the test template created in that project and have access to the test template project through the Template view.
• A sibling project shares a common parent project with other projects of the same project type. All of the work projects based on the same template project are siblings of one another. Sibling project do not have visibility to the views in other sibling projects and do not inherit customizations made to their siblings.
All of the projects in a DevTest integration stand in a hierarchical relationship with one another. Their place in that hierarchy and the customizations made to their parent projects determine the functionality.
Figure 10-4: DevTest Project Relationships
The project hierarchy and customizations
The project hierarchy enables work project administrators to customize each project to meet their individual business needs without affecting other projects.
• Customizations made to a parent project are visible in all child projects through views.
• Customizations made in child project are not visible in parent projects.
• Customizations made in a project are not visible in any sibling project.
In DevTest multiple work project testing teams may share the same template base structures and test templates and still define their own team members and workflow rules, and track project-specific data independently.
Because each work project is a sibling of every other work project based on the same template project, they share the same template structures, but project membership and workflow rules are completely independent.
Function pages appear in the DevTest client as multi-page tabbed forms composed of multiple pages.
Every multi-page tabbed form that a project member might use to create, edit, or forward a DevTest record (test template or test task) is a function page.
Figure 10-12: Template Detail Window
The Template Detail panel and the Task Detail panel are two examples of function pages displayed in the DevTest client. The Submission pages, Editing pages, and Forwarding page are all examples of function pages.
For the project administrator a function page is a frame that is composed of multiple custom pages and system pages. Project administrators may customize the graphical user interface of each DevTest project by adding or removing the custom pages and system pages displayed in function pages.
Figure 10-13: System Pages + Custom Pages = Function Page
DevTest is a highly customizable application. Each project administrator can choose to add or exclude custom pages or system pages to each function page. A function page is a frame that displays custom pages and system pages. Each project administrator chooses which custom and system page are needed in a project and adds or removes pages as needed.
Template view Template Folder Submission function page
Template Folder Editing function page
Template GUI Submission function page
Template GUI Editing function page
Detail function page
Forward function page
Snapshot function page
Default Value function page
Group Change function page
Group Forward function page
Task view Editing function page
Detail function page
Forward function page
Override function page
Group Change function page
Group Forward function page
System pages are predefined form pages that project administrators may add to the multi-page tabbed forms displayed in DevTest views. Each system page provides project teams with tools that enable them to manage DevTest records.
Project administrators may add or remove system pages to DevTest projects by including them in function pages. A function page is displayed in the DevTest client as a multi-page tabbed form. Each page in that form is either a system page or a custom page.
The system pages that an administrator may add to each function page is restricted in each view.
Template view • Linked Task system page
• Environmental Variable system page
• Notes system page
• History system page
• Snapshot system page
• Applicable Project system page
• Folder system page
• Template Order system page
Planning View Notes system page
History system page
Linked Defect system page
Team Selection system page
EV Selection system page
EV Permutation system page
Coverage Selection system page
Coverage Update system page
Coverage Summary system page
Task view Notes system page
History system page
Linked Defect system page
The only changes that a project administrator can make to a system page is to change the title of the system page.
Custom pages are pages conceived, designed, and built by the project administrator. Like system pages, project administrators may add custom pages to function pages to build tabbed forms that appear in the DevTest client GUI.
Custom pages are not shared between projects, views, or panels. All custom pages are specific to the view in which they where created. For example, a custom page created in the Template GUI Folder Settings folder cannot be applied to function pages in the Template GUI Settings folder.
In DevTest project members define all releases and test cycles using planning wizards.
A wizard is a interface that guides the user through a sequential step-by-step process. Planning wizards simplify the process of defining testing teams, test templates, environmental variables, and test tasks used in each release or test cycle.
Project administrators cannot choose to add or remove planning wizard pages to the Release wizard or the Test Cycle wizard.
Release Wizard • The Team Selection wizard page
• The EV Selection wizard page
• The EV Permutation wizard page
• The Coverage Selection wizard page
• The Coverage Update wizard page
• The Target Data wizard page
Test Cycle Wizard • The Team Selection wizard page
• The EV Permutation wizard page
• The Coverage Selection wizard page
• The Coverage Update wizard page
The customizations that project teams may make to planning wizards is relatively limited when compared to the changes that they may make in the Template and Task views.
Knowledge projects provide project teams with a central repository for storing and managing information collected throughout a DevTest implementation.
Knowledge projects enable project teams to manage knowledge items. A knowledge item is a document, HTML link, or topic that is created and managed in the Knowledge view.
Every DevTest implementation must include at least one knowledge project. A knowledge project is the foundation, the knowledge base, for multiple template projects and work projects. Each knowledge project is the parent to one or more template projects and the grandparent to one or more work projects.
A knowledge base is a central repository that enables members of various projects to store and exchange general information relevant throughout a DevTest implementation.
The Knowledge view in a child template project or grandchild work project provides project members with direct access to a parent knowledge project.
Template projects enable project teams to create, organize, and manage test templates for multiple work projects.
Test templates are the master copies (test plans) of the test procedures (test tasks) that QA engineers use to execute product testing in DevTest work projects. Each template project is the parent of multiple child work projects, and the test templates created in the parent template project may be used to create test tasks in the child work projects.
• Test template enable project teams to save time and effort by building environmental variables into their test templates and using these test templates to create multiple test tasks.
• Test templates enable project teams to enforce standardization in test tasks across all child work projects.
Every DevTest implementation must include at least one template project. Each template project is the foundation (the template base) for multiple work projects. Child work projects may use test templates created in a parent template project to create test tasks.
A function page is a compound page composed of multiple custom pages and system pages. Project administrators may customize the Template view and Task view by adding or removing system pages and custom pages to function pages.
Function pages are displayed in project views as multipage tabbed forms. The custom pages and system pages that the project administrator adds to the function page appear as tabs in the tabbed form.
Figure 10-14: System Pages + Custom Pages = Function Page
Project administrators may make four types of customizations to each function page:
• The title of a function pages is customizable.
• Any number of custom pages may be added to a function page.
• A predefined set of system pages may be added to each function page.
• The display order of system pages and custom pages in a function page is customizable.
Figure 11-1: Integrated DevTest-DevTrack WorkflowInterproject searching, bug submission, and tracking enable businesses to define workflow rules that enable them to track issues across multiple test and build cycles. Test task failures may prompt testers to submit a bug report—development issue—to an integrated DevTrack project. A link automatically created between the development issue and the failed test task enabling developers and testers to easily research and track the bug through the entire life cycle.Integration is achieved by mapping DevTest test task fields to DevTrack development issue fields.DevTest- DevTrack integration enables QA and development organizations to work more effectively by facilitating the submission of product defect reports discovered during each test cycle and providing both teams the ability to effectively track and communicate bugs and bug fixes.Issue Searching:Issue Searching settings enable both DevTest and DevTrack users to search for information about a particular record in the other project.Issue Submission:Issue Submission settings enable DevTest project members to submit development issues to the integrated DevTrack development projects using the DevTest client. Once submitted, product defects may be tracked as development issues in the DevTrack project.
Figure 11-2: DevTest-DevTrack Integration
All DevTest-DevTrack integrations are defined on a project-by-project basis. A single DevTest work project may be integrated with multiple DevTrack projects provided that those projects belong to the same DevTrack site. A DevTest user may submit a development issue to any DevTrack project in the integrated DevTrack site.The development projects in a DevTrack site also share a common group of user accounts that may be assigned different account types and privileges in each development project. In an integrated DevTest-DevTrack environment, every DevTest project member is mapped to a DevTrack site user account. User account mapping equates a DevTest user account with a DevTrack user account in the integrated DevTrack site.
Unlike other DevTest views, the DevTrack view is not customizable. The DevTrack view organizes the DevTest client workspace into two panels: the issue list panel and the issue detail panel. All forms in the DevTrack view are defined in the DevSuite Admin client by the DevTrack project administrator.The DevTrack summary contents that are visible, are defined by the "History" sections selected in the Advanced Features, Inter-Project Settings.
Figure 11-2: DevTest-DevTrack Integration
All DevTest-DevTrack integrations are defined on a project-by-project basis. A single DevTest work project may be integrated with multiple DevTrack projects provided that those projects belong to the same DevTrack site. A DevTest user may submit a development issue to any DevTrack project in the integrated DevTrack site.The development projects in a DevTrack site also share a common group of user accounts that may be assigned different account types and privileges in each development project. In an integrated DevTest-DevTrack environment, every DevTest project member is mapped to a DevTrack site user account. User account mapping equates a DevTest user account with a DevTrack user account in the integrated DevTrack site.
Note:Deleting a DevTrack site is dangerous, and is limited to those systems that are not integrated with any DevTest work project.
Unlike other DevTest views, the DevTrack view is not customizable. The DevTrack view organizes the DevTest client workspace into two panels: the issue list panel and the issue detail panel. All forms in the DevTrack view are defined in the DevSuite Admin client by the DevTrack project administrator.The DevTrack summary contents that are visible, are defined by the "History" sections selected in the Advanced Features, Inter-Project Settings.
Note:Confirm that a user account does not exist in the DevTrack project before exporting the DevTest user account to that DevTrack site.
Note:The Default Title Prefix property and the Default Link Type property may be defined when defining Defect Submission Trigger workflow rules. The Defect Submission Trigger workflow rule enables project administrators to configure DevTest to automatically prompt testers to create DevTrack development issues based on changes to the status of test task..
custom fields | All custom fields may be mapped to DevTrack fields |
system fields | Title Test Procedure Expected Result Planned Start Date Planned Finish Date |
system variables | {Current User Name} {Project Name} {Environment} |
{Link Type}:The {Link Type} system variable enables project members to search for issues based on the link type used to link the issue to the DevTest product defect.{Link Note}:The {Link Note} system variable enables project members to search for issues based on linked notes.Issue ID:The Issue ID system field maps to the DevTrack development issue ID number field.Current Owner:The Current Owner field maps to the DevTrack Issue Owner system field.Title:The Title system field maps to the DevTrack development issue title field.Date Created:The Date Created system field maps to the DevTrack development issue creation date field.Created By:The Created By system field maps to the DevTrack development issue Created By field—the DevTest or DevTrack project member that initially submitted the issue to the project.Date Closed:The Date Closed system field maps to the DevTrack development issue Date Closed field.Status:The Status system field maps to the DevTrack development issue workflow state field—the current stage in the development issue life cycle.Sub Status:The Substatus system field maps to the DevTrack development issue Substatus field.Plan StartDate:The Plan Start Date system field maps to the DevTrack development issue Plan Start Date field.Plan End Date:The End Start Date system field maps to the DevTrack development issue End Start Date field.Closed Status:The Closed Status system field maps to the DevTrack development issue Status field—development issues may be open or closed.Assigned By:Date Assigned:Closed By Date:Last Modified:Sub Project:
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.
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—the 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.
DevTest knowledge projects provide testing teams with central repository for all information collected throughout the business. Common access to the a knowledge project (through the knowledge view) enables project members to exchange information between projects.
Knowledge project administrators may restrict access to the knowledge view or the ability to create knowledge items in all child template projects and work projects.
Knowledge project administrators may use the Knowledge Access page to create knowledge folders and define access privileges in DevTest Admin.
Figure 12-1: Access Page in DevTest Admin
In the DevTest Knowledge view project members may use knowledge folders to store knowledge items (documents, HTML links, and topics).
To create knowledge folders:
1Select the Knowledge Access page in the Knowledge Tree window.
The Knowledge Access page appears.
2In the Knowledge Folder area select the Knowledge folder.
3Click the New button.
The Add New Knowledge Folder dialog box appears.
4Enter a name for the new knowledge folder in the Folder field.
5Click the OK button.
The knowledge folder appears in the Knowledge tree window.
6Select the new knowledge folder.
7Define read access privileges for the knowledge folder.
Administrators may restrict read access to this knowledge folder using knowledge project access privileges.
8Define build access privileges for the knowledge folder.
Administrators may restrict write access to this knowledge folder using knowledge project access privileges.
Knowledge project administrators may use the Knowledge Access page in DevTest Admin to edit knowledge folder properties.
In the DevTest Knowledge view project members may use knowledge folders to store knowledge items (documents, HTML links, and topics).
Knowledge project access privileges enable the project administrator to define access to knowledge folders on a project-by-project basis.
To edit knowledge folders:
1Select the Knowledge Access page in the Knowledge tree menu.
The Knowledge Access page appears.
2In the Knowledge Folder area select the Knowledge folder.
Click the New button.
The Add New Knowledge Folder dialog box appears.
3Enter a name for the new knowledge folder in the Folder text box.
4Click the OK button.
The new knowledge folder appears in the Knowledge Folder area as a subfolder beneath the parent Knowledge folder.
5Select the knowledge folder.
6Define read access privileges for the knowledge folder.
Administrators may restrict read access to this knowledge folder using knowledge project access privileges.
7Define build access privileges for the knowledge folder.
Administrators may restrict write access to this knowledge folder using knowledge project access privileges.
Knowledge project administrators may define read access privileges whenever they create or edit knowledge folders in the Knowledge Access page of DevTest Admin.
Administrators may grant access privileges to all child template projects and work projects.
Project members may also define read access and write access privileges for attachment folders in the Knowledge Access page.
To define read access privileges:
1Select a folder in the Knowledge Folder tree of the Knowledge Access page in a knowledge project.
Administrators may define read access privileges for all knowledge folders and attachments folders.
2Click the Access tab in the Read Access Privilege area.
3Select the check box next to the name of each project that is to be granted read access.
Knowledge project administrators may define build access privileges by project whenever they create or edit knowledge folders in the Knowledge Access page of DevTest Admin.
Project members belonging to the selected projects may build knowledge items in the selected knowledge folders and attachment folders.
To define read access privileges:
1Select a folder in the Knowledge Folder tree of the Knowledge Access page in a knowledge project.
Administrators may define write access privileges for all knowledge folders and attachments folders.
2Click the Build tab in the Read Access Privilege area.
3Select the check box next to the name of each project that is to be granted write access.
Knowledge project administrators may customize the field labels for all data entry controls displayed in knowledge projects.
• Knowledge Document GUI Design page
• Knowledge HTML GUI Design page
• Knowledge Topic GUI Design page
Unlike with template projects and work projects, project administrators may not create custom pages or custom controls in a knowledge project, nor can they add or delete pages from the project GUI.
To edit knowledge project field labels:
1Select a knowledge GUI design page in the Knowledge Tree window.
Administrators may customize one of three different pages:
• Knowledge Document GUI Design page
• Knowledge HTML GUI Design page
• Knowledge Topic GUI Design page
2Double-click a field label in the knowledge GUI design page.
3The Edit Field Name dialog box appears.
4Enter a new name for the field label in the Current Name field.
5Click the OK button.
6The new name appears in the knowledge GUI design page.
Knowledge project administrators may customize the Knowledge Topic GUI Design page to display either one or two memo fields in DevTest Admin.
To define the Knowledge GUI Topic Page
1Select the Knowledge GUI Topic page in the Knowledge tree menu.
The Knowledge GUI Topic page appears.
2From the Knowledge Topic Style dropdown list select an option.
• To display one text field, select the Knowledge topic in text with one topic field option.
• To display two text fields, select the Knowledge topic in text with two topic fields option.
Knowledge project administrators may use the Knowledge Access page to create knowledge folders and define access privileges in DevTest Admin.
Figure 12-1: Access Page in DevTest Admin
In the DevTest Knowledge view project members may use knowledge folders to store knowledge items (documents, HTML links, and topics).
To create knowledge folders:
1Select the Knowledge Access page in the Knowledge Tree window.
The Knowledge Access page appears.
2In the Knowledge Folder area select the Knowledge folder.
3Click the New button.
The Add New Knowledge Folder dialog box appears.
4Enter a name for the new knowledge folder in the Folder field.
5Click the OK button.
The knowledge folder appears in the Knowledge tree window.
6Select the new knowledge folder.
7Define read access privileges for the knowledge folder.
Administrators may restrict read access to this knowledge folder using knowledge project access privileges.
8Define build access privileges for the knowledge folder.
Administrators may restrict write access to this knowledge folder using knowledge project access privileges.
E-mail notification allows you to define the triggers, the recipients, and the content of these e-mails. The rules defining these project-specific e-mail notifications are maintained in the E-mail Notification page.
E-mail notification enables project administrators to define triggers for sending e-mail to project members whenever a defined set of conditions are met.
E-mail notification administrative tasks include:
• Enabling e-mail notification and defining e-mail headers
• Defining e-mail notification triggers
• Defining e-mail notification recipients and e-mail conditions
• Defining e-mail formats for auto-e-mail, manual e-mail, and new test cycle e-mail
Project administrators must enable e-mail notification and define e-mail notification properties including the senders address and name using tools in the E-mail Notification page.
Project administrators can define triggers to automatically send e-mail to project members based on eight e-mail notification triggers.
Project administrators may recipients for e-mail notifications and define conditions for each e-mail notification recipient.
Project administrators can pre-define content for three types of notification e-mail: auto-e-mail, manual e-mail, and new test cycle e-mail.
Project administrators can define e-mail notification rules using tools provided in the E-mail Notification page in DevTest Admin.
Project administrators may enable e-mail notification and define e-mail notification properties including the senders address and name using tools in the E-mail Notification page.
• Sender e-mail address
• Sender name
• Notification timer settings
Recipients will see this information in the 'From' section of any auto-e-mails.
Project administrators may also pre-define e-mail notification timer properties. The e-mail notification timer enables the project administrator to define the frequency with which the DevTest system checks for e-mail notification triggers.
Enabling e-mail notification may automatically send e-mail for a large number of past issues. Prior to enabling e-mail notification, project members delete past e-mail notifications.
To delete e-mail notifications for past issues click Clear Old Notification Triggers button in the E-mail Notification page.
To enable e-mail notification:
1Select the E-mail Notification page in the Advanced Feature folder.
2Press the Clear Old Notification Triggers button.
Because enabling e-mail notification could send e-mails for a large number of past issues, delete past e-mail notifications before you enable e-mail notification.
3Select the Enable Auto E-mail Notification check box at the top of the page.
The DevTest Admin warning dialog box appears.
4Enter a number in the Notification Timer field.
The DevTest system will check to see if a notification trigger depending on the number you enter in this field.
5Define the sender e-mail address in the E-mail Address field for all automatic e-mail notifications.
6Define the sender name in the Name field for all automatic e-mail notification
Project administrators may enable e-mail notification and define e-mail notification properties including the senders address and name using tools in the E-mail Notification page.
• Sender e-mail address
• Sender name
• Notification timer settings
Recipients will see this information in the 'From' section of any auto-e-mails.
Project administrators may also pre-define e-mail notification timer properties. The e-mail notification timer enables the project administrator to define the frequency with which the DevTest system checks for e-mail notification triggers.
Enabling e-mail notification may automatically send e-mail for a large number of past issues. Prior to enabling e-mail notification, project members delete past e-mail notifications.
To delete e-mail notifications for past issues click Clear Old Notification Triggers button in the E-mail Notification page.
To enable e-mail notification:
1Select the E-mail Notification page in the Advanced Feature folder.
2Press the Clear Old Notification Triggers button.
Because enabling e-mail notification could send e-mails for a large number of past issues, delete past e-mail notifications before you enable e-mail notification.
3Select the Enable Auto E-mail Notification check box at the top of the page.
The DevTest Admin warning dialog box appears.
4Enter a number in the Notification Timer field.
The DevTest system will check to see if a notification trigger depending on the number you enter in this field.
5Define the sender e-mail address in the E-mail Address field for all automatic e-mail notifications.
6Define the sender name in the Name field for all automatic e-mail notification
A notification trigger identifies the test task management task that is performed in the DevTest client that prompts the e-mail notification action.
Incident notification triggers may be system defined or custom-defined.
DevTest features five system-defined e-mail notification triggers: the New trigger, Forward trigger, New Note trigger, Close trigger, and Reopen trigger.
The New trigger:The New trigger notify the selected recipients whenever a DevTest test task is created.
The Forward trigger: The Forward trigger notifies the selected recipients whenever a test task is forwarded.
The New Note trigger: The New Note trigger notifies the selected recipients whenever a note is attached to a test task.
The Close trigger:The Close trigger notifies the selected recipients when a DevTest test task is closed.
The Reopen trigger:Notify the selected recipients when a test task is reopened.
In addition to the five system triggers, project administrators may define custom state change triggers and field change triggers.
State Change triggers: State Change triggers notify the notification recipients whenever the test task state changes from one specified test task state to another specified test task state.
Field Change triggers:Field Change triggers notify the notification recipients whenever the a specified test task property is changed from one property value to to another specified property value.
State Change triggers notify the notification recipients whenever the test task state changes from one specified test task state to another specified test task state.
Project administrators can define triggers that automatically send e-mail notifications to selected project members whenever there is a change a records progress state.
Using tools in the E-mail Notification page, project administrators can define the two test task states in the transition.
To define test task state change triggers:
1Select Status Change in the Notification Triggers list.
2Press the New button.
The Field Change dialog box appears.
3Select the
4Select a test task state option from the From dropdown list.
The From dropdown list displays administrator-defined test task states.
5Select a test task state option from the To dropdown list.
The To dropdown list displays administrator-defined test task states.
6Click the OK button.
The new status change notification trigger appears in the Notification Triggers list.
Field Change triggers notify the notification recipients whenever the a specified test task property is changed from one property value to to another specified property value.
Using tools in the E-mail Notification page, project administrators may define the test task property values in the transition.
For each defined field change trigger, select the appropriate recipients and conditions.
To define field change triggers:
1Select Status Change in the Notification Triggers list.
2Press the New button.
The Field Change dialog box appears.
3Select a test task property in the Field dropdown list.
4Select a test task property value in the From dropdown list.
The From dropdown list displays property values for the select test task property.
5Select a test task property value in the To dropdown list.
The To dropdown list displays property values for the select test task property.
6Click the OK button.
The new field change notification trigger is displayed in the Notification Triggers list.
A notification trigger identifies the test task management task that triggers an administrator-defined action or set of actions to be executed. Project administrators may choose between six system-defined triggers or define their own custom state change triggers or field change triggers.
DevTest supports three types of triggers:
•System-defined e-mail notification triggersidentify test management tasks that prompt e-mail notification actions.
•State change e-mail notification triggersare administrator-defined rules that identify transitions between test task states as triggers.
•Field change e-mail notification triggersare administrator-defined rules that identify specific changes to test task properties as triggers.
A e-mail notification recipient is, usually, a DevTest project member that is considered to be a stakeholder in a test task. Project members may be defined as e-mail notification recipients based on their account type, group, or their relationship with the test task that prompted the e-mail notification.
For each e-mail notification trigger project administrators may define multiple account types, team groups, and user variables as e-mail notification recipients.
Project administrators can define e-mail recipients for each notification trigger using tools provided in the E-mail Notification page.
{Task Owner} :The project member that currently owns the test task is defined as e-mail notification recipients.
{Task Submitter}:The project member that generated the test task is defined as e-mail notification recipients.
{Last Previous Owner}: The project member that owned the test task prior to the current owner is defined as e-mail notification recipients.
{All Previous Owners}Every project member that has owned the test task at any point in its life cycle is defined as e-mail notification recipients.
{Linked Defect's Owner}: DevTrack project member that own development issues that are linked to the test task are defined as e-mail notification recipients.
{Linked Defect's Submitter}: DevTrack project member that submitted development issues that are linked to the test task are defined as email notification recipients.
{User Defined Address}: The e-mail addresses included in the administrator-defined list are defined as e-mail notification recipients.
{Task Owner's Group E-mail List}:The e-mail addresses included in the task owner-defined list are defined as email notification recipients.
{Linked Template's Owner}:The project member that owns the test template that was used to generate the test task is defined as e-mail notification recipients.
account type: Every project member that belongs to the selected account type is defined as an e-mail notification recipient.
team group: Every project member that belongs to the group e-mail list for the selected team group is defined as an e-mail notification recipient.
Project administrators may define additional e-mail notification conditions for each notification recipient using the E-mail Notification Conditions Manager in DevTest Admin. E-mail conditions ensure that project members only receive notification emails when specified condition are met.
E-mail notifications are not addressed to individual project team members, but rather managed using system-defined variables. E-mail recipients represent different groups of project team members that are associated with each DevTest record.
Project administrators can define e-mail recipients for each notification trigger using tools provided in the E-mail Notification page.
To define e-mail notification recipients:
1Select the E-mail Notification page in the Advanced Feature folder of a work project.
2Select a notification trigger option in the Notification Triggers list.
3Select a recipient option in the Notification Recipients list.
4Click the Edit button.
The E-mail Notification Recipients manager appears.
5Select the E-mail Notification check box
The e-mail addresses included in the administrator-defined list are defined as e-mail notification recipients.
To define a user defined address list:
1Select the E-mail Notification page in the Advanced Feature folder of a work project.
2Select a notification trigger option in the Notification Triggers list.
3Select the{User Defined Address} variable in the Notification Recipients list.
4Click the Edit button.
The User Defined E-mail Address dialog box appears.
5Select the Enable Notification check box.
6Enter one or more e-mail addresses in the Notification Scope multiple-line text box.
Separate e-mail addresses using a semi-colon (;).
7Click the OK button.
The User Defined E-mail Address dialog box closes.
A notification trigger identifies the test task management task that is performed in the DevTest client that prompts the e-mail notification action.
Incident notification triggers may be system defined or custom-defined.
Using e-mail notification conditions project administrators can define sets of rules that must be met before a e-mail notification recipient receives a notification e-mail.
The Task Owner condition,
To define task state e-mail notification conditions:
1Select a recipient option in the Notification Recipients list.
2Click the Edit button.
The E-mail Notification Recipients manager appears.
3Select the E-mail Notification check box.
4Click the Define E-mail Notification Condition button in the E-mail Notification dialog box.
5The E-mail Notification Condition manager appears.
6Select a field option in the Field Name list. Filed options include the Task Owner,
The field option you choose in the Field Name list determines the options available to you in the
7Select a property of the field.
Use the Select/Deselect All check box to quickly select or deselect every field option displayed in the list.
8Use the Search Option radio buttons to include or Exclude the selected fields from the notification condition.
• If you choose the Exclude radio button all selected fields are not included in the notification condition.
• If you choose the Include radio button all selected fields are included in the notification condition.
Search condition appear in the Define Search Logic field.
Using e-mail notification conditions project administrators can define sets of rules that must be met before a e-mail notification recipient receives a notification e-mail.
The keyword condition is based on a search of selected record fields for keywords defined by the project administrator. The condition is met if fields in the record contain the keyword or keyword identified by the condition for the notification recipient.
To define keyword e-mail notification conditions:
1Select a recipient option in the Notification Recipients list.
2Click the Edit button.
The E-mail Notification Recipients manager appears.
3Select the E-mail Notification check box.
4Click the Define E-mail Notification Condition button in the E-mail Notification dialog box.
5The E-mail Notification Condition manager appears.
6Select the Keyword option.
7Enter keywords in the Search field.
8Click the OR radio button or AND search button.
9Select one or more fields to search for keywords.
Search conditions appear in the Search Conditions list.
DevTest features five system-defined e-mail notification triggers: the New trigger, Forward trigger, New Note trigger, Close trigger, and Reopen trigger.
The New trigger:The New trigger notify the selected recipients whenever a DevTest test task is created.
The Forward trigger: The Forward trigger notifies the selected recipients whenever a test task is forwarded.
The New Note trigger: The New Note trigger notifies the selected recipients whenever a note is attached to a test task.
The Close trigger:The Close trigger notifies the selected recipients when a DevTest test task is closed.
The Reopen trigger:Notify the selected recipients when a test task is reopened.
Project administrators can predefine the subject line and the body of the e-mail by introducing placeholders—system variables—that represent test task properties into the subject line and body of the e-mail template.
Whenever the e-mail message template is used to generate an e-mail message, the actual property values of the corresponding test task is substituted for the system variables in the subject line and body of the e-mail message that is sent to the recipient.
Two types of system variables may be introduced into e-mail message templates: field content variables and field name variables.
• Field content variables represent a test task property. Field content variables may be added to the subject line and the body of the e-mail template.
• Field name variables represent the title of a test task property. Field name variables may be added to the body of the e-mail template.
Subject line field content variables enable project administrators to add test task properties to the subject-line of an e-mail message. Each subject line field content variable represents a test task property.
Whenever an e-mail message is created using the e-mail template, the actual property values of the test task is substituted for the field content variables that were built into the e-mail message template.
Subject line e-mail field content variables include:
Task Owner
Expected Result
Test Procedure
Title
Actual Setup Time
Actual Test Time
E-mail body field name variables enable project administrators to display the titles of test task properties to the body of an e-mail message. Each body field name variable represents the title of test task property and identifies that property in the client GUI.
Adding field name variables to the body of e-mail messages enables the author to identify test task properties displayed in the message—such as those introduced using body field content variables.
Body e-mail field name variables include:
Task Owner
Expected Result
Test Procedure
Title
Actual Setup Time
Actual
E-mail body field content variables enable project administrators to show test task properties to the body of an e-mail message. Each body field content variable represents a test task property.
Whenever an e-mail message is created using the e-mail template, the actual property values of the test task is substituted for the field content variables that were built into the e-mail message template.
Body e-mail field content variables include:
Task Owner
Expected Results
Test Procedure
Title
Actual Setup Time
Actual Test Time
[[Change Summary]]
[[Recipient List]]
[[Notes]]
[[History]]
An auto e-mail message template is a predefined e-mail message that is used to create e-mail messages that are automatically delivered to e-mail notification subscribers whenever an e-mail notification rule is triggered.
The subject line and body of the e-mail message may be defined using a combination of plain text and placeholders called system variables. System variables generally represent test task properties.
Whenever the e-mail message template is used to generate an e-mail message, the actual property values of the corresponding test task is substituted for the system variables in the subject line and body of the e-mail message that is sent to the recipient.
To define auto e-mail message templates:
1Click the Auto E-mail Format button in the E-mail Notification page of the Outgoing E-mail subfolder in the Advanced Features folder of a work project.
The Auto E-mail Notification Format manager appears.
2Define the subject line of the e-mail message.
• To add a subject line, input text in the Subject Line text box.
• To add a test task property variable, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
3Define the body of the e-mail message.
• To define the text of the e-mail body, input text in the Subject Line text box.
• To add a test task property variable, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
• To add a test task property content, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
4Click the OK button. The e-mail message template is saved.
A manual e-mail message template is a predefined e-mail message that is used to create e-mail messages that may be manually sent from within the DevTest client.
The subject line and body of the e-mail message may be defined using a combination of plain text and placeholders called system variables. System variables generally represent test task properties.
Whenever the e-mail message template is used to generate an e-mail message, the actual property values of the corresponding test task is substituted for the system variables in the subject line and body of the e-mail message that is sent to the recipient.
To define a manual e-mail message template:
1Click the Manual E-mail Format button in the E-mail Notification page of the Outgoing E-mail subfolder in the Advanced Features folder of a work project.
The Manual E-mail Notification Format manager appears.
2Define the subject line of the e-mail message.
• To add a subject line, input text in the Subject Line text box.
• To add a test task property variable, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
3Define the body of the e-mail message.
• To define the text of the e-mail body, input text in the Subject Line text box.
• To add a test task property variable, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
• To add a test task property content, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
4Click the OK button. The e-mail message template is saved.
An test cycle e-mail message template is a predefined e-mail message that is used to create e-mail messages that are automatically delivered to e-mail notification subscribers whenever a new test cycle is created.
The subject line and body of the e-mail message may be defined using a combination of plain text and placeholders called system variables. System variables generally represent test task properties.
Whenever the e-mail message template is used to generate an e-mail message, the actual property values of the corresponding test task is substituted for the system variables in the subject line and body of the e-mail message that is sent to the recipient.
To define a test cycle e-mail message template:
1Click the Test Cycle E-mail Format button in the E-mail Notification page of the Outgoing E-mail subfolder in the Advanced Features folder of a work project.
The Test Cycle E-mail Notification Format manager appears.
2Define the subject line of the e-mail message.
• To add a subject line, input text in the Subject Line text box.
• To add a test task property variable, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
3Define the body of the e-mail message.
• To define the text of the e-mail body, input text in the Subject Line text box.
• To add a test task property variable, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
• To add a test task property content, click the Add Field Content button and select one or more test task properties in the Add Field for E-mail Content dialog box.
4Click the OK button. The e-mail message template is saved.
Project administrators can specify a unique prefix to be appended to the subject line of each notification e-mail message, based on the trigger type.
For example, all e-mails triggered by a status change can have the text Status Change appended to the current subject line of each e-mail.
The subject line prefix is automatically added to the subject line of all e-mail messages based on the auto e-mail message template—provided that theE-mail Prefix variable is added as a placeholder to the template.
To define e-mail subject prefixes:
1Click the E-mail Subject Prefix button in the E-mail Notification page of the Outgoing E-mail subfolder in the Advanced Features folder of a work project.
The Define E-mail Subject Prefix dialog box appears.
2Select an e-mail notification trigger from the Trigger list.
The Trigger list displays nine e-mail notification triggers.
• On Submit
• On Forward
• On Close
• On Reopen
• On New Note
• On Edit Note
• On New Test Cycle
• On Status Change
• On Field Change
A unique prefix may be defined for eachtrigger type. Unique prefixes may not be created for custom-defined status change triggers or field change triggers.
3Click the Edit button.
The Change Mail Prefix dialog box appears.
4Input text in the Trigger Title text box.
The text is displayed as prefix in the subject line of all e-mail notification messages.
5Click the OK button.
The Change Mail Prefix dialog box closes.
In addition to the five system triggers, project administrators may define custom state change triggers and field change triggers.
State Change triggers: State Change triggers notify the notification recipients whenever the test task state changes from one specified test task state to another specified test task state.
Field Change triggers:Field Change triggers notify the notification recipients whenever the a specified test task property is changed from one property value to to another specified property value.
The E-mail Settings page in the Admin tree menu enables project administrators to define properties for all outgoing e-mail sent from with the DevTest system. Using tools provided in this page project administrators may
• Designate an outgoing SMTP server
• Define e-mail server authentication
• Define the character set and character wrap settings for outgoing e-mail.
The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service.
Each project can also have an e-mail character set defined for outgoing e-mails. All e-mails sent from a project will include this character set in the e-mail message headers. Both automatic e-mail notifications and e-mails sent manually through the DevTest client and DevTest Web will include this character set. Without a specified character set embedded in an e-mail message header, any foreign characters in the e-mail will be lost.
To define general e-mail properties:
1Select the E-mail Setting page from the Outgoing E-mail Settings subfolder beneath the Advanced Folder in the DevTest Admin tree menu.
2Enter the name of outgoing e-mail server in the Outgoing Mail (SMTP) Server field.
3If you want to require outgoing e-mail authentication, you can enable e-mail authentication and define the account name and password in the Outgoing Mail Authentication area:
• Select the My Mail Server Requires Authentication check box.
• Enter the account name in the Account Name field.
• Enter the password in the Password field.
The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service.
4Select a character set option from the Character Set dropdown list.
5Define the number of characters at which e-mail messages automatically wrap.
To define the Incoming Mail Server:
1On the 'Incoming Mail Server' page define the POP3 incoming mail server properties so DevTest can retrieve e-mails from the server.
2Specify the name or the TCP/IP address of the incoming mail server. You must also specify a predefined e-mail account name and password to access the server.
DevTest will use this information to login to the mail server and retrieve any e-mails submitted to the specified account. See the 'E-mail Auto-Submit' section below for more details.
State Change triggers notify the notification recipients whenever the test task state changes from one specified test task state to another specified test task state.
Project administrators can define triggers that automatically send e-mail notifications to selected project members whenever there is a change a records progress state.
Using tools in the E-mail Notification page, project administrators can define the two test task states in the transition.
To define test task state change triggers:
1Select Status Change in the Notification Triggers list.
2Press the New button.
The Field Change dialog box appears.
3Select the
4Select a test task state option from the From dropdown list.
The From dropdown list displays administrator-defined test task states.
5Select a test task state option from the To dropdown list.
The To dropdown list displays administrator-defined test task states.
6Click the OK button.
The new status change notification trigger appears in the Notification Triggers list.
To enable e-mail escalation
1Select the Escalation page in the DevTest Admin tree menu.
The Escalation page appears.
2Select the Enable Escalation check box.
3Define e-mail escalation rules.
4Define e-mail escalation actions for each escalation rule.
The E-mail Escalation Rules Manager enables project administrators to define escalation rules for multiple sets of DevTest records.
Each escalation rule corresponds to an escalation action. Only those records that meet the criteria defined by the escalation rule are subject to the escalation trigger and escalation actions defined in the corresponding escalation action.
Escalation rules are predefined queries for selecting DevTest records. Project administrators may search for and select records based on values stored in three DevTest record fields: the Task Owner field, the
• Task Owner field searches are based the on group folder, group, and account type settings for the project. Project administrators may choose to include or exclude any task owner from the search conditions.
•
•
• Keyword searches are based on the administrator-defined keywords in five different system fields: Title field, Test Procedure field, Expected Result field, Work Description field, Notes title field, and the Notes description field.
The Define Search logic field in the Escalation Rule Manager enables project administrators to define the relationship between multiple search fields. Project administrators may define search criteria for multiple fields and use the AND and OR boolean logical operators to define search logic.
Escalation rules do not define the triggers for escalating DevTest records, but merely enable project administrators to select which records are auto-escalated when the trigger occurs. Project administrators may define escalation triggers and escalation actions using the Escalation Action Manager.
The Escalation Rule Manager enables project administrators to define search criteria for selecting DevTest records of auto-escalation. Only those records that meet the criteria defined in the escalation rule are subject to the corresponding escalation action.
Project administrators may search for and select records based on values stored in three DevTest record fields: the Task Owner field, the
To define escalation rules:
1Click the New Criteria button.
The New Escalation Rule window appears.
2Enter a name for the rule in the Rule Name field.
3Select the Task Owner,
4Select the Include or Exclude radio button.
• Select the Include radio button to include the selected values in the search criteria.
• Select the Exclude radio button to exclude the selected values from the search criteria.
5Select the values you want included in the search conditions from the values displayed in the Search Option list.
• If you want to include all available values in search conditions, select the Select/Deselect All check box.
6Define search logic.
In the search logic field you may change the logic of the query.
To define keyword escalation rules:
1Click the New Criteria button.
The New Escalation Rule window appears.
2Enter a name for the rule in the Rule Name field.
3Select the {Keyword} variable in the Field Name list.
4Enter the keyword in the Keyword field.
5If you wish to enter multiple keywords
• Select the AND boolean to search for both keywords.
• Select the OR boolean condition to search for either keyword.
6Select the record fields to be searched. DevTest searches all selected fields for the keyword or keywords selected.
• Title system field
• Test Procedure system field
• Expected Result system field
• Work Description system field
• Notes (Title and Description) fields
7Define search logic.
In the search logic field you may change the logic of the query.
Project administrators may define escalation actions using tools provided in the Escalation Action Manager.
Escalation actions include the reassigning of records to new owners, changing the progress state of a record, or generating e-mail notifications.
• Sending e-mail notifications
• Reassign DevTest records
• Change record progress states
Project administrators can define when the system sends e-mail notifications, to whom the notifications are addressed, and how frequently they are sent.
Project administrators may define escalation actions that reassign DevTest records to project members.
Project administrators may define escalation actions to change the progress state of DevTest records.
Each escalation action is directly tied to an administrator-defined escalation rule. The DevTest system only executes an escalation action if the criteria defined in the escalation rule are met.
Project administrators may define escalation actions using tools provided in the Escalation Action Manager.
Escalation actions include the reassigning of records to new owners, changing the progress state of a record, or generating e-mail notifications.
• Sending e-mail notifications
• Reassign DevTest records
• Change record progress states
Project administrators can define when the system sends e-mail notifications, to whom the notifications are addressed, and how frequently they are sent.
Project administrators may define escalation actions that reassign DevTest records to project members.
Project administrators may define escalation actions to change the progress state of DevTest records.
Each escalation action is directly tied to an administrator-defined escalation rule. The DevTest system only executes an escalation action if the criteria defined in the escalation rule are met.
DevTest 3 features full integration with TechExcel DevSuite enabling
development organizations to seamlessly integrate DevTest product test case
management and test management with DevSpec requirements and
specifications management and KnowledgeWise knowledge management.
TechExcel DevSpec is an integrated requirements management solution that is
specifically designed to provide visibility, traceability and validation of your
product or project requirements. DevSpec provides a frame work to create new
requirements, specifications and features that can be linked to development and
testing implementation projects.
The DevSpec integration details:
TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work during a development project. Documents are shared with all resources involved in the execution of the project allowing for an uncompromised vision to direct the path of anydevelopment project.
DevTest 3 features improved access to commonly used folder and work item
commands enhances the usability of the DevTest Web client and increases user
efficiency.
Commands which were formally displayed as commands in the Action
dropdown lists are now represented by command buttons in the folder, test
template, and test task tool bars. Users will no longer need to mouse-over the
Action menu to perform most actions.
In DevTest 3, attachments (files that are linked to a test task or test template
note) are automatically deleted when the note itself is deleted. In previous
releases, the files attached to notes remained in the knowledge base.
In DevTest 3, the name given to template folders may contain up to a maximum
of one hundred characters. In previous releases, test template titles were
limited.
In DevTest, every test task is defined by its environment, test procedure, and
one or more expected results - all test task properties are defined in and
inherited from a parent test template.
In DevTest 3.0, project team members with the appropriate privileges may edit
DevTest test templates in theplanning view or task viewof the DevTest Web
Client. In previous releases of DevTest, test templates could be edited only in
the test template view.
In DevTest, the list panel in the DevTrack view displays high-level data about
product defects submitted to an integrated DevTrack project as development
issues. Development issues are organized into rows and columns in a tabular
report. Every row represents a specific development issue. Every column a
development issue property.
Using the User dropdown list, DevTest project team members may filter the
development issues displayed in the list panel by their owner - the DevTrack
project team member that owns the linked defect in the integrated DevTrack
project.
In DevTest 3.0, the User dropdown list displays the name of every project team
member, group folder, andteam group. A team group is an
administrator-defined collection of project members - who do not necessarily
share the same account type - that share common responsibilities in a project.
By selecting a team group in the User dropdown list, the user may view every
development issue that is owned by a member of that team group.
The DevTrack view is an optional view that enables DevTest projects members
to manage and DevTrack development issues from within the DevTest client.
Product defects identified during a test cycle may be submitted to an integrated
DevTrack project from within the DevTest client.
In DevTest 3, project team members may now search for and filter DevTrack
development issues bysubproject. In DevSuite, a subproject organizes
development issues into smaller, more manageable groups of issues based on
component, development team, or any other criteria that is useful to the
business.
Using tools in the Search Manager, project members may define search
conditions based on subprojects, keywords, development issue property values,
and other parameters to display subsets of product defects (DevTrack
development issues) in the list panel of the DevTrack view.
In the knowledge view Description page, project members may now directly
edit URLs in the URL Path text box. In previous versions of DevTest.
Project members may now search for test templates based on environments.
1. Click the Search button from the client to bring up the Search function.
2. Choose the "Environment Option" of "Selected"
3. Select the applicable environments
4. Click "Search"
In DevTest 3, release summary reports may display any or all template folders.
Previously, release summary reports only displayed up to two levels of folders.
In DevTest 3, project team member may now define the order in which test task
folders are displayed in the tree panel of the planning view and test task view
and how report folders and reports are ordered in the report view.
Test template authors may now define a distinct default value template for each
subfolder in the test template tree panel.
How to define a default value template for a subfolder:
1. Right-click on the folder and select Properties.
2. Click the "..." button to edit the "Default Value".
Idle log out messages have been improved so that project members know why
they were logged out of a project.
DevTest 3 features an improved installation wizard that greatly simplifies the
installation and upgrade of DevTest components and modules.
In previous releases, duplicate name restrictions prevented project members
from creating verification point with the same name. VP names may now be
used more than once on a test template or test task.
DevTest 3 introduces multiple language support. All graphical tools in the
client workspace and all project data may be displayed in one of three
languages: Chinese, English, or Japanese.
Project team members may select a preferred language when they log into the
client. All graphical elements in the client are displayed in the language
selected.
DevTest 3 features integration with AutomatedQA TestComplete.
TestComplete saves QA organizations the time and effort required for manual
testing by delivering automated testing tools that facilitate functional, unit,
regression, data-driven, object-driven, stress, and scalability testing.
DevTest web session control tracks and manages access to project resources
through the DevTest Web Server and enables development organizations to
make DevTest data available to project stakeholders throughout the project.
DevTest Web session control is now managed by the DevTest Application
Server. In previous versions of DevTest, web session control was managed by
the DevTest Web Server and all users were automatically logged out of their
projects whenever the web server was restarted. DevTest Web users may now
work without interruption if the web server needs to be restarted.
In DevTest 3, project team members may view high-level information about the
specifications and requirements that have been linked to test templates and test
tasks in DevTest template list reports and test task list reports.
The Primary Links report may only be displayed in projects that have enabled
DevTest-DevSpec integration.
The report displays the requirements and specifications that have been linked
to a test template or test task using primary links. In DevSuite, a primary link
identifies the specification or requirement that defines the ¡°conceptual
product¡± to be implemented in development. Test tasks and test templates may
be linked to multiple primary specifications and primary requirements.
Requirements and Specifications linked as referential work items are not
returned by the report.
Report authors may display primary links in DevTest reports by adding the {All
Links} option to list reports. Primary links may be displayed in detailed reports
only.
DevTest Web now supports Windows NT authentication. 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.
How to enable Windows NT authentication for the Web clients:
System administrators must also configure IIS for either Basic Authentication or
Windows Authentication to use Windows NT user authentication.
In DevTest 3, project administrators may now enable LDAP authentication for
both the Windows and Web clients or for the Windows client alone. In previous
releases LDAP integration always supports both clients.
How to select LDAP authentication scope:
1. From the Admin "System" menu, select System Setting / LDAP Integration
DevTest now supports an optional web logout URL setting which enables the
project administrator to define 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.
How to enable the DevTest Web Logout URL:
1. From the Admin, select "System" menu
2. Select "Web Setup
3. Enter URL in the section titled "Web Logout URL"
In an integrated DevTest-DevTrack environment, QA organizations may
streamline the reporting of product defects 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 be
automaticallycopied from the test task to the newly created development issue.
Test case-bug report field mapping reduces the time required to create issues
and enables them to get back to their primary business of testing.
In DevTest 3, system administrators may map DevTest system lookup fields to
DevTrack system lookup fields.
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 site. Each standard lookup
field defines a set of field values, which may potentially defined that field in the project.
In the 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.
In DevTest 3, system administrators may map DevTest fields to DevTrack custom fields
defined in the Custom Page 4 and Custom Page 5 custom pages of an integrated
DevTrack project.
A custom page is a form conceived, designed, and built by a project administrator that
enables project members to collect, manage, and track project data. DevTrack supports
five custom pages.
In DevTest 3, system administrators may map DevTest system lookup fields to
DevTrack system lookup fields.
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 site. Each standard lookup
field defines a set of field values, which may potentially defined that field in the project.
In the 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.
In DevTest 3, system administrators may map DevTest fields to DevTrack custom fields
defined in the Custom Page 4 and Custom Page 5 custom pages of an integrated
DevTrack project.
A custom page is a form conceived, designed, and built by a project administrator that
enables project members to collect, manage, and track project data. DevTrack supports
five custom pages.
1. From the DevTest Admin, Open any specific DevTest work project
2. Select Project Login Tip
3. From here you can enable/disable the project tip, as well as edit the project tip
1. Open user preferences
2. Select "Other" tab
3. Check or uncheck the "Do not show project tip" option.
DevTest automatic updating enables project team members to automatically
upgrade their DevTest client to the latest edition when they log into a DevTest
project.
The project tip window is an administrator-defined message that is displayed in
the client workspace when a user logs into a DevTest project. The window is
designed to enable project administrators to provide project team members
with information or links to information that will enable them to begin working
in a project.
The project tips window is fully customizable on a project-by-project basis.
Using controls in the Admin client, project administrators may define both the
content and format of the project tip.
1. From the DevTest Admin, Open any specific DevTest work project
2. Select Project Login Tip
3. From here you can enable/disable the project tip, as well as edit the project tip
While performing ‘Group Edit’ operation, user can now choose to append new text to the existing ones. The append option needs to be enabled from the admin panel by selecting ‘Enable appending text for group action’ option for the multiline edit box. Once enabled in the admin, in order to append the text user needs to select the ‘Append option’ from the Group Change dialog box in the web portal.
DevTest now supports integration with Jira, Bugzilla, Mantis and any other system that provides URL for creating, browsing and viewing defects. Once the user enables the integration option with these tools, the DevTrack integration will be disabled automatically. Based on the defect tracking tool selected, user will have to enter the specific URL details for the tool.
In the DevTet web, when the user tries to submit a defect the user can either enter a new Bug from the selected tool or can browse for an existing recorded bug. If user clicks New button, it will open a new browser tab with the New Defect URL defined in the Admin for external defect tracking. If user clicks Browse button, it will open a new browser tab with the Browse Defect URL. In either case, user will need to manually copy the target Defect ID from the external defect tracking system and put it in the Defect ID edit box in order to link it in DevTest. The Defect Note is optional for linked defect display or searching within DevTest.
The Linked Defect page will show linked external defect. When defect is clicked, it will open a browser tab with URL as the View Defect URL plus the linked Defect ID
The defect count can also be included in the planning summary
The task list reports can also contain the Linked Defects information
The user can also define search criteria based on ‘Defect Count’, ‘Defect ID’ & ‘Defect Note’
While creating or editing release and test cycles, the dialog box now supports a multi-select checkbox for group and member selection
User subproject selection pop-dialog box now contains a dropdown menu to select the development space in the selected DevTrack project. The subfolders are then loaded dynamically based on the selection
DevTest now supports the MySQL database
The search ID fields in advanced search can now accept up to 2000 characters
User can now set access control based on account type to enable/disable copying template folder. When unchecked from admin the ‘copy to’ option will not be visible to user in the right mouse menu
The fixed verification point add/edit dialog box now has a back button for easier navigation between multiple VP’s
The DevTest Web now support importing/exporting templates using xml and text files
User can now define a custom email address from the DevSuite Admin panel. This email address can then be used by default to send out email from a different account. User needs to specify this option from the admin panel
When a user submits a defect in DevTrack for a test case failure in DevTest, user has the option to unlink the story for the defect. This helps user to create a standalone bug
From the DevTest admin panel, users now inactivate the environment variables not in use. In the admin panel go to environment variable page, select the environment and click edit. Selecting the inactive checkbox will disable that variable and will not be shown in the web portal.
Users can now edit the linked defects listed in the ‘linked defect’ tab in DevTest task view. Double click on the defect and a pop-up window with an option to edit the defect would open. This window will load details from the DevTrack system since the defect was submitted to one of the DevTrack projects. User can then edit the defect and modify details.
