Trackers
 |
Since Codebeamer 8.2.0 Test Run and Test Case tracker configuration is more restrictive - it is not possible to define Guards or modify necessary fields anymore for Test Runner but this is configured in general.xml. To enable the configuration of these properties add/edit this option in general.xml.: <testManagement disableEditingBuiltInFieldsName="false"/>
|
Trackers in Codebeamer are used for:
• Managing IT processes.
• Managing Requirements.
• Managing Changes.
• Managing People, relationships.
• Managing Innovation.
• Escalations, SLA.
• Agile (Software) Development.
• Bug tracking.
For other purposes:
Trackers are the equivalent of Tables in a Relational Database or Classes in object oriented programming tracker items are the equivalent of Rows in a Relational Database or Objects in object oriented programming.Trackers define the following:
• Structure (fields).
• Relations to other items (in other trackers) (via reference fields, similar to Foreign Keys).
• Behavior (permissions, aggregation/distribution rules, state transitions, events, actions, escalations, notifications, etc.).
Tracker items represent the State (field/attribute values, including history) of a specific bug, task, requirement, etc. In addition to the configured Relations, you can also create ad-hoc Associations between tracker items and other Codebeamer entities like other items or documents, even with external URLs. Each Tracker has a Stereotype, which defines:
• The basic classification for trackers and items of this type:
◦ Work items: All things, that represent work, that needs to be planned, accomplished and monitored, e.g. a task to execute, a risk to track, a bug to fix.
◦ Configuration item: All things needed to do the work, for example, tools, software, models, and plans, etc., and that need to be managed (CMDB or ITIL).
◦ Source code the result/output of accomplished work (Software Development only), that needs to be managed by SCM
• The basic/core Structure and Behavior (only relevant for top-level/base Trackers, derived Trackers inherit that from their template Tracker).
• The icon/symbol for trackers and items of this type.
• The available Trackers for trackers of this type
See here for an overview of defined tracker stereotypes.
Trackers (similar to Classes in object oriented programming) can be derived from/extend base/template trackers:
• Structure and behavior of the base/template tracker are inherited by derived Trackers.
• Inherited settings can be overloaded/overridden in derived trackers.
• Derived Trackers can add own/additional Structure and Behavior.
• The depth of the inheritance tree is unrestricted.
Trackers are type definitions and item containers at the same time (similar to database tables).
• Therefore Trackers are a special type of Folder/Directory.
• By default, all trackers reside at the top-level of their project's document hierarchy.
• But you can also create trackers in any sub-directory/folder of the document hierarchy (currently disabled via GUI).
• Trackers provide fine-grained access control for items, item fields and state transitions, based on user roles and item state.
• Work and Configuration Item trackers only hold work/configuration items, no files or folders.
• Source Code Repositories (which are an extended type of tracker) are both:
◦ They are Folder/Directory for the source code files.
◦ They are tracker for source code changes (commits and push).
• Tracker items (in the same tracker) can build a parent/child hierarchy of unlimited depth.
• Tracker items can hold any number of files (in form of attachments).
• Trackers (including items) can be copied/moved as any other regular document (currently disabled via GUI).
Please note:
• Work and Configuration item trackers at the top-level of the document tree, are only shown on the Trackers page of the project.
• Source Code trackers (Repositories) at the top-level of the document tree, are only shown on the SCM Repository page of the project.
• Trackers (of any type) in sub-directories/folders are only accessible via their directory/folder under Documents, not via the Trackers or SCM Repository page.
Work and Configuration items can be copied/moved from one tracker to another (compatible) tracker, but because structure and behavior are bound to the tracker and not the item, this always implies a type conversion (attribute mapping), and can therefore inflict data/information loss.
Tracker Summary
On the Tracker Summary page, a summary of the number and status of all issues is displayed. When you click on a tracker name a list of tracker issues will be shown. This list gives a detailed overview of all issues in the tracker.
 |
Different users can see different statistics depending on their roles.
|
Figure: Project Tracker Summary List
