B (Visual Studio ALM Glossary)
This glossary defines key terms that are used in the Visual Studio Application Lifecycle Management (ALM) Help.
backlog
The set of work items not yet closed, representing work under consideration or still to be completed.baseline
The original approved plan (for a project, a work package, or an activity), plus or minus approved scope changes. Usually used with a modifier (for example, cost baseline, schedule baseline, performance measurement baseline).beta version
A pre-release version of a product that is sent to customers and partners for evaluation and feedback.black box test
A test that is based on a component's actual behavior without regard to its implementation.bottom-up estimating
A principle of good scheduling. It means having those who do the work estimate the effort, rolling up task-level estimates, and recognizing that experience is the best estimating technique.branch
To allow a collection of files to evolve in two or more divergent paths. Branching is often used when teams need to maintain two or more similar code bases, for example, when a product is released and work needs to begin on the next version. In source control, branching is analogous to a file system copy operation.browser mix
Specifies the probability of a virtual user running a given browser profile. For example: 95% use Internet Explorer 6 and 5% use Pocket IE. Valid only for Web test and coded Web tests See: load test scenario, Web test, coded Web test.browser profile
A collection of HTTP headers to simulate a particular browser, such as Internet Explorer 6 or Netscape 6.bug
A type of work item that records a potential source of dissatisfaction with the product. The common name of a work item type for tracking code defects.bug allotment
A chunk of development time allocated to fix bugs. An allotment is created by leaving slack in the iteration plan.bug convergence
The point at which the rate of fixed bugs exceeds the rate of found bugs. Bug convergence is a visible indication that the team is making progress against the active bug count. It is a sign that the project end is within reach.build
A named set of deliverables (software components) produced, usually by compiling, from a discrete set of source versions.build acceptance test
See build verification test (BVT)build activity
A Windows Workflow Foundation activity that is part of the Team Foundation Server build process. It incorporates the logic that is executed before, during, or after the building of a software application. Post-build activities include automatically creating environments and then deploying and testing applications.build agent
A background process that receives, runs, and reports on Team Foundation Server builds and other property settings on a single computer. The build agent communicates with the build controller, usually located on another computer.build controller
A background process that manages a set of build agents.build cycle
A part of the internal release cycle. It is the process of adding features, creating test cases for each, stabilizing each feature before building new features, and then releasing for evaluation.build definition
A set of a) build activities and b) the conditions under which the workflow is activated, that together build a single solution or a set of solutions in a team project. The definition includes build name, source control workspace for the files to be built, and location of the TFSBuild.proj project file, build agent, build retention policy, and the build trigger. The build definition can also include activities to create environments and deploy newly built applications into those environments.build error
A message that notifies you of an issue that breaks the build.build health
The quality of the as-built software.build verification test (BVT)
Also known as a smoke test. A group of tests used to determine the health of a build at a high level. Typically, these tests exercise the core functionality to help team members determine whether further testing is worthwhile. They are run after the daily build to verify that compilation of source code has been built successfully and is ready for further testing.