To learn more, see Day in the life of a Developer: Suspend work, fix a bug, and conduct a code review. Feedback requests track requests for feedback generated through the feedback request form. See Get feedback. A feedback response is created for each person and for each item for which feedback is provided through the Microsoft Feedback Client. Shared steps are used to repeat tests with different data. Shared Parameters specify different data and parameters for running manual test cases.
See Repeat a test with different data. Each test case defines a manual test. Test plan group test suites and individual test cases together. Test plans include static test suites, requirement-based suites, and query-based suites. To learn more, see Create test plans and test suites. Test suites group test cases into separate testing scenarios within a single test plan. Grouping test cases makes it easier to see which scenarios are complete.
See Create test plans and test suites. Ideally, work items are only created from the specific tool designed to support their usage. So, to prevent users from creating work items manually, there's a Hidden Types category. All of the categories listed in the previous table are added to the Hidden Types category except for the Test Case category. Each work item supports tracking data contained in work item fields.
Also, it captures changes as updates are made within the History field and comments made in the Discussion section. To learn more about each field, see Work item field index. Also, it captures changes as updates are made within the History field. Each form contains multiple controls, as shown below and described in Work item form controls. The new form and its corresponding features are available from the web portal. The new form is automatically available when you add projects to a new collection.
For existing projects, an admin is required to enable the new form. The new web form provides multiple experiences not provided with the old web form. To learn more, see New work item experience. You can add and update work items from the web portal.
To track work using other clients, see Best tools for adding, updating, and linking work items. You can add and update work items from the web portal and various clients. For an overview of all clients that connect to your project, see Tools and clients that connect to Azure DevOps. Many Scrum teams treat bugs the same as any backlog item or user story. Others see bugs as work that belongs to implementing a story, and then treat them as a task.
Bugs, like product backlog items PBIs and user stories, represent work that needs doing. So, should you track your bugs along with other items in the product backlog items? Or, should you track your bugs as tasks linked to those backlog items? How does your team estimate work? Based on how your team answers these questions, they can choose how they want to track bugs from one of these three choices. To change the team setting, see Show bugs on backlogs and boards.
For an overview of all team settings, see Manage teams and configure team tools. You can only assign a work item to one person at a time.
The Assigned To field is a person-name field designed to hold a user identity recognizable by the system. Within the work item form, choose the Assigned To field to select a project member. Or, you can begin typing the name of a project member to quickly focus your search to a select few.
Anyone who has write access to a project can assign work items, including users with Basic and Stakeholder access. When your system is configured with Azure Active Directory Azure AD , then the system will synchronize person-name fields with these directories. You can grant access to a project by adding security groups that you created in Azure AD or by adding accounts to existing or custom groups defined from the collection setting Security pages.
For more information, see Add or delete users using Azure Active Directory. Work item templates are distinct from process templates. For information on process templates, see Choose a process template or these specific topics for the default process templates: Basic , Agile , Scrum , or CMMI. The availability of template task options depends on the client and platform version available to you.
Add and manage work item templates from the web portal or from Visual Studio or earlier versions. These templates only appear in your view of Team Explorer. Make sure that you've selected the content version based on your platform version.
Manage work item templates Define, edit, delete, copy link, create copy, and rename. The templates you define through the web portal are distinct from those you define through Visual Studio.
Web portal templates can only be managed and applied to work items through the web portal. Similarly, Visual Studio templates can only be managed, viewed, and applied to work items in Visual Studio. However, you can use the URLs of both template types to add work items through the web portal. To add, capture, edit, or delete work item templates through the web portal, you must be a member of the team under which you add them.
To apply a work item template, you must be a Contributor of the project and a member of the team under which the work item template is defined. To add, capture, edit, or delete work item templates through the web portal, you must be a team administrator. To apply a team template, you must be a Contributor of the project and a member of the team under which the work item template is defined. Choose the actions icon to open the menu. Choose Templates and then Capture. Name the template, select the team for which you want to save it under, and optionally define or clear fields.
Save the template when finished. Once you've saved the template, choose Copy link to capture the URL for the template. You can paste the URL link into a browser to create a work item, or provide it to others for their use to add work items.
For example, you can add it as a hyperlink to a project wiki , a dashboard via a markdown widget , or other shared network resource. Use the URL whenever you want to add a work item of the type you've defined with its predefined values.
Within the web portal, work item templates are associated with a team. Only those templates that are defined for a team are accessible when you go to apply a template to work items using the web portal.
Name the template and optionally define or clear fields. The template is saved under the team you selected in the first step.
Once you've saved the template, choose Copy link to capture the URL for the template that you can use to add work items using the template. If you connect to an on-premises TFS and primarily create work items working in the web portal, you can create a hyperlink that captures the default values you specify for a template. Choose the hyperlink, and it opens the template in the web portal.
Fill in the default values you want the template to specify. You can leave required fields empty, or place some text in them. Here, we fill in several values, including tags, but leave the Title blank. When you're done, copy the URL for the template. The URL won't contain defaults defined for the work item type.
To specify a default field value, see Add or modify a field. Also, there is a character limit imposed by some browser clients with no work around. If you primarily work in Visual Studio or Team Explorer, and want to create work items from templates that you access from the Work Items page, you can create work item template files extension.
Right-click the work item of the type and whose fields you want to capture, and select Capture Template from the context menu. In the dialog, use the checkboxes to select all the fields you want to save in the template. Then, add a name and optionally description to the template.
Save the template and it will appear in the root of the Team Explorer pane under the Templates section. You can view the list of templates defined for each work item type, and also add, edit, copy, delete, rename, and copy the link of a template. All templates are defined and managed for a team.
Expand Boards and choose Team configuration. If you need to switch to a different team, use the team selector. You manage templates from team settings. All templates are defined for a team. If you're not a team administrator, get added as one. If you want to become familiar with the file structure of a process template, review a description for each file or download a process template. You can modify the processes for your project after it is created. As you work with a project, the initial settings that the process template defined may no longer meet your needs.
If you're most interested in customizing objects used to track work, which includes test plans, test suites, and test cases, review Customize your work tracking experience. The customizations you make by modifying an XML definition file for a project are the same types of customizations you make in a process template file. If you want to add or modify types of work items , you can achieve this without changing the whole process template.
You can make and test changes by using an existing project. For the On-premises XML process model, you can use the witadmin exportwitd and importwitd command-line tools to download and upload the XML definition files for work item types.
If you need to update a custom process template to support using the Configure Features wizard after a TFS upgrade, see Configure features after an upgrade. To use the available updated templates and to access customizations that you made previously, you may need to add customizations provided with the new templates.
If you're considering making extensive customizations, review how the changes you make will impact maintenance and upgrade of your projects. Process templates consist of nine plug-ins. Each plug-in defines a set of tasks that will be run and the screens that appear when you launch the New Team Project wizard.
Tasks set permissions, create folders, upload files, activate sites, or set other configurable variables. Plug-ins also specify the dependencies that a task has on the successful completion of other tasks. When you create a project from the web portal, several process template files are ignored. Specifically, the files that would create a Report Manager site and a SharePoint project portal aren't supported. If you want these features to be created for a project on your on-premises TFS, then create your project from Visual Studio or Team Explorer.
For details, see Process template and plug-in files, Client support for project creation. The Build, Portal, and Reporting plug-ins require the following resources have been installed and configured. To customize a process template, you customize one or more files associated with a functional area. While customizing any one object is fairly simple, you'll want to make sure that you don't break any interdependencies when you customize.
The ProcessTemplate. This file contains all the task groups that you want to run to create a project. Each task group references a subordinate XML plug-in file where the specific tasks for that plug-in are defined. Because the process template touches on many components of a team's process, you may want to plan, coordinate, and track the changes that you will make. In particular, you may want to check with project leads, test leads, development leads, and release managers before you change the default configuration of any one area.
For example, work item queries defined for the Agile process template use the iteration nodes that are defined in the Classification. If you change the iteration node definitions, you must modify the work item queries on which they rely.
You can find these queries by searching for the following macros in the. For an overview of required plug-ins and plug-in dependencies, see Define dependencies for task groups and tasks. When you add objects to a process template, you will want to make sure that you label them correctly so that you avoid XML validation errors.
Restrictions are put on the names or labels of most Team Foundation objects. For an overview of naming restrictions that apply to process templates, security groups, area and iteration nodes, work item types, and work item fields, see Naming restrictions.
Most process template components that you customize will affect only the project that you create by using the process template. The exceptions to this rule are global lists, link types, and work item fields. These objects are defined for a project collection. Each work item field has an associated field reference name that uniquely identifies each field. The reference name cannot be changed after it is assigned. In addition, a work item field can have a reporting name that is assigned to it. The reporting name must match across all work item types that are defined for a project collection.
If they do not, validation errors might occur when you upload the process template, or conflicts might occur in the data warehouse databases.
0コメント