Release Management

This chapter describes how application administrators can configure Release Manager. It also describes how managers for product marketing, engineering, quality assurance, and technical publications can monitor the progress of their teams and how users (product marketers, engineers, QA testers, and technical writers) can record their development tasks. It includes the following topics:

About Release Manager

The Release Manager module helps to manage new product development and release cycles from start to finish. Release Manager uses data collected in Siebel Field Service to help guide product feature selection and development.

Release Manager assists with numerous release-related activities. Users can perform the following tasks:

Communicate feature descriptions throughout the organization.
Prioritize features to implement the most important features.
Develop marketing requirements documents (MRDs) for engineers to use as product specifications.
Allocate engineering resources and track engineering tasks.
Track QA test plan development and test execution.
Track documentation development.
Track activities associated with release items.
Monitor development status.

The Release Manager and Siebel Quality modules of Siebel Field Service work together. After you release a product, the Siebel Quality module tracks the product improvement process and channels requests for improvements to future releases. For more information about the Siebel Quality module, see Quality Management.

Structure of Release Manager

You can think of a product release as a collection of features. The decision to implement these features generates multiple release items: MRDs to identify the features, engineering tasks to implement the features, QA test plans to test the features, and documentation to describe the features. Siebel Field Service helps to make sure that each task, test plan, and document is linked to at least 1 feature.

In Release Manager, engineering tasks, MRDs, QA test plans, and technical publications documents are linked to associated features. Users gain the following benefits:

Executives can justify decisions about how to allocate engineering resources and schedule QA testing.
Product marketing managers can see the features in MRDs, and determine the development, testing, and documentation status for the features.
Engineering and QA managers can see the new features to incorporate into project plans and test plans.

The following figure shows how the release items are linked to features.

This figure shows an area that represents Release Manager. In this area, tests are linked to test plans, and test plans, engineering tasks, MRDs, and documentation are linked to features at the center.

Product Release Process

The following figure shows the stages in the product release process.

The product release process includes the following stages:

Stage 1. Product Marketing begins the release cycle by defining product features, entering those features in Siebel Field Service, determining the features to implement, and developing marketing requirements documents (MRDs).
Stage 2. Engineering builds the features. Engineering defines the tasks required to implement the features, builds the features, and uses Siebel Field Service to track task completion.
Stage 3. Quality Assurance (QA) defines test plans to test the new features, and uses Release Manager to track the test plan development. QA then tests the features by executing the test plans in various operating environments, and records the details of each test iteration.
Stage 4. Technical Publications documents each feature in the appropriate publication and uses Release Manager to track document development status.

Stage 1 (Product Marketing), Stage 2 (Engineering), Stage 3 (Quality Assurance), and Stage 4 (Technical Publications) lead toward the final stage, Ship. In practice, these stages are not rigidly sequential. At any point in the release development cycle, activities for several of the stages can overlap when teams pursue goals simultaneously.

Scenarios for Using Release Manager

This topic describes how Release Manager might be used. You might use Release Manager differently, depending on your business model. This topic includes the following scenarios:

Managing Administrator Work

Before the release cycle begins, the administrator sets up a master record for the release. Then the administrator defines an access list of employees who are associated with the release. Then the administrator designates the employees on the access list for project teams that are associated with various stages of the release. The administrator also sets up Lists of Values (LOVs) for fields with drop-down lists in the Release Manager views. Finally, the administrator sets up activity templates. Users can use these templates to associate lists of specific activities with certain stages of the release process.

During release work, the administrator might have to perform certain maintenance tasks to make sure Release Manager continues to run smoothly for users. After Engineering completes product builds, the administrator adds product prototype records. Quality Assurance records tests for these records. When product parameters change in the course of development, the administrator might have to add new Area-Subarea combinations to add to the LOVs for Release Manager. When a new release cycle begins, the release administrator determines the need for new and revised test plans and test strategies.

Managing Product Marketing Work

At the beginning of a release cycle, Product Marketing defines a set of release-defining features, which are product requirements and enhancements that are based on customer needs. After prioritizing and finalizing the detailed features list, Product Marketing enters the features into Release Manager as feature records. If a feature is complex with multiple components, then Product Marketing enters each component as a feature record, and then designates the main feature as its parent feature.

After entering the features for a release, Product Marketing writes Marketing Requirement Documents (MRDs) and enters the documents into Release Manager. Product Marketing creates a new record for each MRD or logical group of MRDs. After creating the MRD records, Product Marketing links the MRD document files to respective MRD records as attachments. Finally, Product Marketing links the MRDs to the features that they reference.

Managing Engineering Work

After Product Marketing defines release features, Engineering writes engineering tasks to implement those features in the product. Engineering enters each task as an individual record in Release Manager, and links each task to the features it is designed to implement. If a task is complex with multiple components, then Engineering enters each component as a subtask record, then links it to the main engineering task.

Managing Quality Assurance Work

After Product Marketing defines release features and Engineering implements the features, Quality Assurance writes test plans to validate the features. QA enters each completed test plan as an individual record in Release Manager, and links each test plan to the features it is designed to validate.

Next, Quality Assurance creates test strategies, which are logical groupings of test plans. (For example, Quality Assurance might group together all test plans for an application module as a test strategy. Alternatively, Quality Assurance might group together all test plans to execute on the same platform and browser combination as a test strategy.) QA enters each completed test strategy as an individual record in Release Manager, and links each test strategy to the test plans that it groups together.

After defining test strategies, Quality Assurance runs test plan executions, or test passes. QA logs each test plan execution as a test pass record. When recording the test passes, Quality Assurance links the test pass records to respective test plans. QA records the defects found during testing as change request records and links the records to the associated test passes.

During and after testing, Quality Assurance managers can run various reports about test pass results to monitor the health and progress of the product release effort.

Managing Technical Publications Work

When the other teams design, implement, and test the release features, Technical Publications writes technical documents to describe the product and explain how to use it. Technical Publications enters each technical document as an individual record in Release Manager, and links each technical document to the features it describes. Technical Publications then links an activity plan with standard milestones and deadlines to each technical document record. After creating the technical document records, Technical Publications links the technical document files to respective records as attachments.

Process of Administering Release Manager

Administrators must set up several areas of Release Manager in advance to make sure that product marketers, quality assurance testers, engineers, and technical writers can use Siebel Field Service. They must also perform some Release Manager maintenance tasks as needed.

Depending on your company structure and policies, these activities might be the duties of the Release Manager, application administrator, or another person who sets up Siebel Field Service. For convenience and brevity, this chapter refers to this person as the administrator.

To administer Release Manager, administers perform the following tasks:

Setting Up Releases

When entering a release item, a user must associate the release item with a release. In Release Manager, a release is a type of project. For more information about setting up projects, see Siebel Project and Resource Management Administration Guide.

Releases include the following types:

Future Releases. Because you must associate each release item with a release, you must set up the release (project) before entering any records. Although only a single active release can be in progress, you must also set up records for future releases. Consequently, the product marketing manager can immediately target a deferred feature to a specific future release.
Unspecified Releases. Frequently the appropriate future release for a feature or other release item is unknown. Because you must associate all release items with a release, set up an artificial release named Unspecified Release or a similar term. You can link orphan release items to this release. When you determine the appropriate future release, you can then retarget an item to that release.

This task is a step in Process of Administering Release Manager.

Setting Up Access Lists

Release Manager includes the concept of an access list. Each project includes a group of employees (the employees on its access list) who are associated with a release. You can include in the release access list only an employee who is associated with a release project. For more information about adding employees to an access list, see Siebel Project and Resource Management Administration Guide.

To add a person to an access list, you must first set up the person as an employee. For more information about setting up employees, see Siebel Security Guide.

This task is a step in Process of Administering Release Manager.

Setting Up Project Teams

Release Manager includes the concept of project teams. Each project includes a group of employees (the project team) who own, approve, or are associated with each release item (feature, MRD, engineering task, QA test plan, QA test, or document). You can associate only an employee who is a member of the project team with a release item. For more information about setting up project teams and adding employees to these teams, see Siebel Project and Resource Management Administration Guide.

To add a person to a project team, you must first add the person to the release access list. For more information, see Setting Up Access Lists.

This task is a step in Process of Administering Release Manager.

Setting Up Lists of Values

The administrator typically sets up Lists of Values (LOVs) for use in Siebel Business Applications. Although all types of release items share the Status field, the LOVs for the Status field are likely specific to each release item.

For example, while the Status values for an engineering task typically relate to the development phase of the task (Unit Test, Final, and so on), the Status values for a technical publications document typically relate to the production phase of the document (Draft, Final Edit, and so on). So that users do not have to review long LOVs for phases that are related to their work, you might have to restrict the views where specific LOVs appear. For more information about setting up LOVs and restricting the views associated with specific LOVs, see Siebel Applications Administration Guide.

The following table describes the LOVs to set up before using Release Manager. In this table, the Type column denotes the drop-down list record in the List of Values view.

Table Release Manager LOVs

View Label	Associated Release Items	Type	Description	Typical Values
Client OS	QA Tests	PSTASK_CLIENT_OS	The type of operating system running on the client.	Windows 2000, Mac OS
Client Type	QA Tests	PSTASK_CLIENT_TYPE	The type of test computer used by the tester.	HTML
Database	QA Tests	PSTASK_CLIENT_DB	The type of database running in the test environment.	IBM DB2, Microsoft SQL Server 7.0
Effort	Engineering Tasks	PSTASK_ENGINEER_EFFORT	The amount of effort required of the engineer to complete the task.	High, Low, 1 Man Month
Priority	Features	PSTASK_PRIORITY	The relative importance of the feature.	High, Medium, P1. Critical
Revenue	Features	PSTASK_REVENUE	The amount of expected revenue if the feature is implemented.	High, Low, >5M, <1M
Risk	Engineering Tasks	PSTASK_ENGINEER_RISK	The amount of risk to destabilizing the product by undertaking the engineering task.	High, Low
Server OS	QA Tests	PSTASK_SERVER_OS	The type of operating system running on the server.	Windows NT
Source	Features	PSTASK_SOURCE	The source of the feature.	Customer Input, Market Survey
Status	All	PSTASK_STATUS	The current implementation or development phase of the release item.	Draft, Unit Test, Final
Test Class	QA Tests	PS_QA_TEST_STRATEGY_ TEST_CLASS	The sequence category of the test.	Certification Pass, Full Pass, Final Pass, Acceptance Pass, Browser Certification
Test Set	QA Tests	PS_QA_TEST_PLAN_TEST_ SET	The product area applicable to the test.	Install, Upgrade, Report, Charts, General
Type	QA Tests	PSTASK_ALT_TYPE	The type of test that is conducted.	Blitz, Ad Hoc, Detailed, White Glove

This task is a step in Process of Administering Release Manager.

Lists of Values for Special Tag Fields

You must also add a List of Values (LOV) for the Special Tag field in the QA Test Plans view. The following table shows an example of how you might set the fields of several new LOV records to populate the Special Tag field with values.

Table Special Tag LOV Examples

Field	Record 1	Record 2	Record 3	Record 4
Type	LOV_TYPE	PS_TEST_PLAN_SPEC_TAG	PS_TEST_PLAN_SPEC_TAG	PS_TEST_PLAN_SPEC_TAG
Display Value	PS_TEST_PLAN_SPEC_TAG	Browser Specific	EBIZ Specific	Config. Specific
Language-Independent Code	PS_TEST_PLAN_SPEC_TAG	Browser Specific	EBIZ Specific	Config. Specific
Language Name	English-American	English-American	English-American	English-American
Active	True	True	True	True
Replication Level	All	All	All	All

Setting Up Activity Templates

The QA and technical publications teams can access activity templates. An activity template contains multiple predefined activities to associate with a release item. Users can use these templates instead of manually entering each activity, and these templates help to standardize activities for groups or teams. If user teams need activity templates, then create the templates before anyone uses Release Manager. For more information about how to create activity templates and add activities to these templates, see Process of Administering Service Activities.

This task is a step in Process of Administering Release Manager.

Adding Product Prototypes

As a product progresses through the release cycle, increasingly advanced product prototypes are available for testing. (In the case of software development, these prototypes are builds.) When QA testers execute a test plan, they select the version number of each tested prototype. When each new prototype is available, enter it into Release Manager so that QA can record tests for it.

You enter builds as products in the Release Product Administration view of the Quality screen.

This task is a step in Process of Administering Release Manager.

Adding Area-Subarea Combinations

Area and Subarea fields are linked so that the values available in the Subarea field change dynamically according to the selected value in the Area field. These Lists of Values (LOVs) appear in both the Release Manager and Siebel Quality modules. In Release Manager, an Area field value is associated with a feature. For more information about adding Area-Subarea combinations, see Mapping Area-Subarea Combinations.

When product parameters change in the course of development, you might have to add new Area-Subarea combinations to Release Manager.

This task is a step in Process of Administering Release Manager.

Updating Test Plans and Test Strategies

When a new release cycle begins, some test plans and test strategies from the previous release are relevant to the new release, while some are not relevant. The QA release administrator must review existing test plans and test strategies for relevance to the new release, and update the relevant ones. The QA release manager must also identify and fill gaps in the existing resources with new test plans and test strategies. For more information about adding and linking test plans and test strategies, see Managing Quality Assurance Work for Release Manager (End User).

This task is a step in Process of Administering Release Manager.

Process of Managing Release Manager

The following list shows the tasks that end users typically perform to manage Release Manager. Your company might follow a different process according to its business requirements.

To manage Release Manager, end users perform the following tasks:

Managing Product Marketing Work for Release Manager (End User)

After administrators configure Release Manager, product marketers can record the progress and results of product design efforts in Siebel Field Service. Their managers can monitor the information that they enter.

This topic contains the following related information:

This task is a step in Process of Managing Release Manager.

Creating Features and Subfeatures

Product marketing managers can use Release Manager to enter new product features and, if appropriate, subfeature components of these features.

To create a feature and subfeatures

Navigate to the Release screen, then the Features view.

Add a new feature record, and complete the fields as appropriate.

Some fields are described in the following table.

Field	Comments
Status	Select the status of the feature, which can be one of the following values: Green. Approved for the release. Yellow. Can include in the release. Red. Not included in the release
Priority	Select the priority of the feature relative to other features targeted for the same release.
Release	Select the name or number of the product release for the feature.
Product Line	Displays the product line. The value in the Subarea field determines this field value.
Area	Select the product area associated with the feature.
Subarea	Select the product subarea associated with the feature. The list of subarea values depends on the value in the Area field.
EAT Completion Date	Select the Engineering Acceptance Test completion date.
Source	Select the source of the idea for this feature.
Account	Select the account that requested the feature or the account to which your company is contractually obligated to deliver the feature.
Associated Parties	Select the individuals associated with the feature. Set the product marketing manager who manages the feature as Primary.
Revenue	Select the amount of revenue tied to delivering this feature in the targeted release.

If you want to add subfeatures to the feature, then complete the following steps:
1. Drill down on the Feature field, and click the Subfeatures view tab.
2. Create new subfeature records, and complete the fields as appropriate.

Adding MRDs and Linking Features

Product marketing managers can group similar features together into an MRD and track the development of the MRD in Release Manager. Authors of the MRDs can attach electronic copies to MRD records.

To add an MRD and link features

Navigate to the Release screen, then the Marketing Requirement Documents view.

Add a new MRD record, and complete the fields as appropriate.

Some fields are described in the following table.

Field	Comments
Associated Parties	Select the individuals associated with the MRD. Set the author as Primary.
Release	Select the name or number of the product release associated with the MRD.

If you want to associate features with the MRD, then complete the following steps:
1. Drill down on the MRD number (#) field, and click the Features view tab.
2. Create new feature records, and complete the fields as appropriate.

Monitoring Features and MRDs

As a release progresses, product marketing managers can use Release Manager to track the status of features and the related release items. In addition, product marketing managers can monitor the features to make sure that they do not overlook important features.

Monitoring Release Items

During the release process, product marketing managers can monitor features to make sure they meet the following criteria:

MRDs properly specify the features.
Engineering implements the features.
QA test plans test the features.
Technical publications documents describe the features.

Product marketing managers can run queries to identify features that do not meet these criteria. The procedures that follow provide examples.

To query for features without corresponding MRDs, perform the following procedure.

Note: You can follow similar procedures to query for features without corresponding engineering tasks, test plans, or technical publications documents.

To identify features without linked MRDs

Navigate to the Release screen, then the Marketing Requirement Documents view.
Launch a query with the following parameters:
- In the Release field, select the current release.
- In the MRD field, enter NOT(EXISTS(LIKE*)).

During the release process, engineering managers can monitor development plans to make sure that their teams are not working on tasks without corresponding features. To query for engineering tasks without linked features, perform the following procedure.

Note: You can follow similar procedures to query for MRDs, test plans, or technical publications documents without corresponding features.

To identify engineering tasks without linked features

Navigate to the Release screen, then the Engineering Tasks view.
Launch a query with the following parameters:
- In the Release field, select the current release.
- In the Related Features field, enter NOT(EXISTS(LIKE*)).

Managing Engineering Work for Release Manager (End User)

After product marketing manager enter features and MRDs in Release Manager, engineers can begin recording the progress and results of development efforts in Siebel Field Service. Their managers can monitor the information that they enter.

This topic contains the following related information:

This task is a step in Process of Managing Release Manager.

Adding Engineering Tasks and Linking Features

After product marketing managers enter some features and corresponding MRDs into Release Manager, engineering managers can begin analyzing the development work and identifying the discrete tasks required to implement the features. They can enter these tasks directly into Release Manager. When engineering managers create engineering task records, they link the records to the appropriate features.

The product marketing and engineering managers match the requested features with the available engineering resources. During this process, they weight the relative importance of the features with the required investment to implement the features. They might defer some features to a future release. Consequently, the necessary engineering resources are available for the final set of release features.

To add an engineering task and link features

Navigate to the Release screen, then the Engineering Tasks view.

Create a new engineering task record, and complete the fields as appropriate.

Some fields are described in the following table.

Field	Comments
Related Feature	Select the features to associate with the engineering task.
Engineering Group	Select the engineering group that manages the task. Usually, the engineering manager (owner) of the task belongs to this group.
Target Date	Select the expected date of the task completion.
Release	Select the name or number of the product release associated with the engineering task.
Parent Task	Select the parent task for the current task. You can use this field to set up a hierarchy of parent tasks and child subtasks.
Effort	Select the level of effort required from the engineer to complete the task.
Risk	Select the level of risk of destabilizing the product by undertaking this engineering task.
Comp %	Type the percentage of the task that is completed to date.
Design Review	Select the date when the design review occurs.
Code Review	Select the date when the code review occurs for software releases.
Associated Parties	Select the individuals associated with the engineering task. Set the engineering manager who manages the task as Primary.

Adding Subtasks to Engineering Tasks

If a task is complex with multiple components, then Engineering enters each component as a subtask record, then links it to the main engineering task.

To add a subtask to an engineering task

Navigate to the Release screen, then the Engineer Task - Subtasks view.
Create a new subtask record, and complete the fields as appropriate.

Monitoring Engineering Tasks

During the development process, engineering managers can use Release Manager to track the status of the tasks that are underway. They can conduct and record design reviews and (for software releases) code reviews. For each task, they log the portion completed and the target completion dates so that they can address potential issues before they are critical.

Managing Quality Assurance Work for Release Manager (End User)

After Engineering enters engineering tasks in Release Manager, QA testers can begin recording the progress and results of testing efforts in Siebel Field Service. Their managers can monitor the information that they enter.

This topic contains the following related information:

This task is a step in Process of Managing Release Manager.

Creating Test Plans and Linking Features

After QA identifies the features for a release, QA can begin revising existing test plans or developing new plans to exercise new product functionality. QA tracks test plan development in Release Manager. The test plan available as an attachment to the test plan record. Parties such as product marketers who are associated with the development of the test plan are linked to the record, they can record their approvals.

For each test plan, QA logs the portion completed and the target completion dates so that potential issues are addressed before they are critical. The QA manager determines whether they must run a test plan to validate 1 or more test strategies, and if so, then specifies those strategies.

To create a test plan and link features

Navigate to the Release screen, then the Test Plan Administration view.

Create a new test plan record, and complete the fields as appropriate.

Some fields are described in the following table.

Field	Comments
Target Date	Select the expected date of the test plan completion.
QA Owner	Select the employee who performs the testing.
Release	Select the name or number of the product release associated with the test plan.
Suggested Strategies	Select the test strategies to apply to the test plan. Available selections come from test strategy records that the administrator enters in the Strategy Administration view. For more information, see Creating Test Strategies.
Test Set	Select the grouping of tests for the test. Groupings might reflect, for example, the parts of the product that apply to multiple tests.
Special Tag	Select the tags that your company defines for convenience in grouping or querying tests. You can specify multiple tags. For more information about defining special tags, see Setting Up Lists of Values.
Tag Summary	Displays all of the tags that you select in the Special Tag field. This field is for convenience in querying for the tags in the Special Tag field.
Related Feature	Select the features to associate with the test plan.
Product Line	Displays the product line. The values in the Area and Subarea fields determine this field value.
Complete %	Type the percentage of the test plan that is completed to date.
Test Plan Owner	Select the individuals associated with the test plan. Set the author of the test plan as Primary.
Automated	Select this check box to indicate the test is automated.
% Auto	Type the percentage of the test that is automated.
% Auto Platforms	Type the percentage of platforms that is automated for the test.
% Auto Horizontal	Type the percentage of the cross-industry version of the product that is automated for the test.
% Auto-International	Type the percentage of the international version of the product that is automated for the test.
Tools	Select the software used to automate the test.
Auto Complete Date	Select the date the automated test is completed.

An activity plan originates from a predefined activity template. An activity template contains multiple predefined activities to associate with a release item. Users can use activity templates instead of manually entering each activity, and activity templates help to standardize activities for QA teams.

To add an activity plan to a test plan

Navigate to the Release screen, then the QA Test Plans view.
Drill down on the Test Plan number (#) field for a selected a test plan, and click the Activity Plans view tab.
Create a new activity plan record, and complete the fields as appropriate.
When you associate the activity plan with the test plan, all the activities in the activity plan are associated with the test plan and appear in the Activities view.

Creating Test Strategies

At the beginning of a release cycle, you define a set of criteria (or matrix) that identifies the various combinations for running any QA test plan. For example, the matrix for a software product might include criteria such as Server, Database, Browser, and so on. These criteria sets are test strategies.

To create a test strategy

Navigate to the Release screen, then the QA Test Strategies view.
From the visibility filter, select Strategy Administration.

Create a new strategy record, and complete the other fields as appropriate.

Some fields are described in the following table.

Field	Comments
Release	Select the name or number of the product release associated with the test strategy.
Test Class	Select the type of test pass for the test strategy.
Web Srv App	Select the application that runs on the selected Siebel Application Interface.

After you save the test strategy, it appears as a choice in the Suggested Strategies field in the Strategy Test Plan Admin view.

Drill down on the Title field to access the QA Test Plans view if you want to associate test plans with the test strategy.
Select the test plan you want to associate to the current test strategy.

Recording Test Passes and Linking Test Plans

After a complete QA test plan is associated with a test strategy, you can run tests to validate the test plan. Because test plans are linked to features in Release Manager, QA managers can focus efforts of their teams on those test plans that are associated with the greatest number of new features. After executing each test, QA testers record the results in Release Manager and link each test pass to the test plan that it executes.

To record a test pass and link a test plan

Navigate to the Release screen, then the QA Tests view.

Create a new QA test record, and complete the fields as appropriate.

Some fields are described in the following table.

Field	Comments
Tester	Select the individuals associated with the test. Set the individual who conducted the test as Primary.
Release	Displays the name or number of the product release associated with the test.
Date	Select the date and time when you conduct the test.
Status	Select the prototype stability that you assess during the test.
Cover %	Type the percentage of the test plan that test covers.
Pass %	Type the percentage of the test plan that passed the test.
Type	Select the type of test that you conduct.
Build	Select the product prototype that you test.
Server OS	Select the type of operating system running on the server computer in the test environment.
Client OS	Select the type of operating system running on the client.
Database	Select the type of database running in the test environment.
Client Type	Select the type of test computer that you use.

Drill down on the Test Plan field if you want to associate tests with the test plan.

Associating Change Requests with Test Passes

While performing a test pass, QA testers might encounter product defects and ideas for design improvements. QA testers record these defects and ideas as change requests and associate the change requests with the test pass where they find them. For more information about entering change requests, see Quality Management.

To associate a change request with a test pass

Navigate to the Release screen, then the QA Test Defects view.
In the Change Requests view, select the change requests that you want to associate with the test pass.

Monitoring Test Results

QA managers can then review test summary information to assess overall product quality and determine when the product is ready to ship.

In the QA Test Plans view, the tester assesses the number of test plan executions (passes) and the status of the last test plan execution. The more test plan passes and the higher the stability of the tested area, the greater the overall product quality.

QA managers can run queries on fields to pinpoint areas of risk to product quality. To identify the new product features that are minimally tested, and the features that might be unstable, complete the procedure in this topic.

To monitor test results

Navigate to the Release screen, then the QA Test Plans view.
In one of the following fields, create a query to identify the features that are incompletely tested or unstable:
- In the Passes field, enter < n, where n is the minimum number of test iterations that you think is adequate at this point in the release.
  In each test plan the query returns, click the Related Features field to display the features that are at risk because they are not fully tested.
- In the Last Build field, enter Unstable or another value in the Status field on the QA Tests view that represents a low-quality assessment.
  In each test plan the query returns, click the Related Features field to display the features that are at risk because they were not functional in the most recent test.

Managing Technical Publications Work for Release Manager (End User)

When users enter design, development, and test data in Release Manager, technical writers can begin recording the progress and results of documentation efforts in Siebel Field Service. Their managers can monitor the information that they enter.

This topic contains the following related information:

This task is a step in Process of Managing Release Manager.

Creating Technical Documents and Linking Features

After they identify release features, Technical Publications can begin revising existing documentation or developing new documents to describe new product functionality.

Technical Publications can track documentation development in Release Manager. The document available as an attachment to the record. Technical Publications links the document with associated features. Product marketers who are associated with the development of the document are linked to the record, and they can record their approvals. For each document, Technical Publications logs the portion completed and the target completion date so that they can address potential issues before they are critical.

To create a technical document

Navigate to the Release screen, then the Technical Documents view.

Create a new technical document record, and complete the fields as appropriate.

Some fields are described in the following table.

Field	Comments
Target Date	Select the expected date of the document completion.
Complete %	Type the percentage of the document that is completed to date.
Release	Select the name or number of the product release associated with the document.
Est Pages	Type the estimated number of pages for the completed document.
New %	Type the percentage of the document that is new in this version of the document.
Associated Parties	Select the individuals associated with development of the document. Set the author as Primary.

Adding Activity Plans to Technical Documents

An activity plan comes from a predefined activity template. An activity template contains multiple predefined activities to associate with a release item. Users can use activity templates instead of manually entering each activity, and activity templates help to standardize activities for technical publications teams.

To add an activity plan to a technical document

Navigate to the Release screen, then the Technical Document Activity Plans view.
Select a technical document record.
In the Activity Plans view, create a new activity plan record, and complete the fields as appropriate.
When you associate the activity plan with the technical document, all the activities in the activity plan are associated with the technical document and appear in the Activities view.