Index
A
- acceptance environment
- characteristics of, Control Development, Test, Acceptance, and Production Environments
- feature failures that passed in test environment, Measuring the DTAP Street in Practice
- production environment boundary and, Controlled DTAP Clarifies Responsibilities Between Development Phases
- test environment boundary and, Controlled DTAP Clarifies Responsibilities Between Development Phases
- test environment vs., Objection: There Is No Need to Distinguish Test and Acceptance Environments
- Agile/Scrum methodology, How to Apply the Best Practice
- (see also Scrum)
- Agile planning, Make Definition of Done Explicit
- DoD's origins in, Make Definition of Done Explicit
- short iterations, Make Definition of Done Explicit
- assumptions, about metrics, Make Assumptions about Your Metrics Explicit-Using Norms with the GQM Approach
- automated builds, Requirement: Automated Builds
- automated deployment, Automate Deployment-Metrics Overview
- best practice application, How to Apply the Best Practice
- CI vs., Automate Deployment
- common objections to metrics, Common Objections to Deployment Automation Metrics
- field experience, Metrics Overview
- measurement of process, Measuring the Deployment Process-Measuring the Deployment Process
- measuring reliability gained by, Measuring the Deployment Process
- measuring time gained by, Measuring the Deployment Process
- metrics overview, Metrics Overview
- motivation for, Motivation
- automated testing, Automate Tests-Metrics Overview
- assumptions about metrics, Assumptions Regarding These Metrics
- best practice application, How to Apply the Best Practice-How to Apply the Best Practice
- CI and, Use Continuous Integration, Requirement: Automated Tests
- common objections to metrics, Common Objections to Test Automation Metrics
- field experience, Metrics Overview
- for detecting root causes of bugs, Automated Testing Finds Root Causes of Bugs Earlier with Little Effort
- managing in practice, Managing Test Automation in Practice-Assumptions Regarding These Metrics
- measuring benefits of, Managing Test Automation in Practice
- measuring development effort for, Managing Test Automation in Practice
- metrics overview, Metrics Overview
- motivation for, Motivation
- optimal amount of, Managing Test Automation in Practice
- unit tests for code that already works, Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
- when failed tests have no noticeable effects in production, Objection: Failing Tests Have No Noticeable Effects
- automation, CI as facilitator of, CI Facilitates Further Automation
- automobile industry, Introduction
- averages, outliers vs., Assumption: Averages are more important than outliers
B
- baseline, Measuring the DTAP Street in Practice
- best practices
- automated deployment, How to Apply the Best Practice
- automated testing, How to Apply the Best Practice-How to Apply the Best Practice
- CI, How to Apply the Best Practice
- controlled DTAP, How to Apply the Best Practice
- development standards, Development Standards Help Enforce Best Practices, How to Apply the Best Practice-Code Quality Control
- DoD, How to Apply the Best Practice-How to Apply the Best Practice
- for documentation, How to Apply the Best Practice
- GQM approach, How to Apply the Best Practice-Metric
- implementing one practice at a time, One Practice at a Time
- metric pitfalls and, Avoid the Metric Pitfalls
- overview of, An Overview of the Development Best Practices in This Book
- persistence in application of, Applying the Best Practices Requires Persistence
- third-party code, How to Apply the Best Practice-Manage the Usage and Versions of Libraries and Frameworks Centrally
- version control systems, How to Apply the Best Practice-Integrate Your Code Regularly
- black-box tests, Automate Tests
- branches, long-lived, Integrate Your Code Regularly
- branching, Important Best Practices for CI
- broken windows effect, The Contribution of Each Developer Matters
- bugs, testing for (see automated testing)
- builds
- automated, Requirement: Automated Builds
- average time for, Objection: We Cannot Get Control Over Our Build Time
- CI and, Important Best Practices for CI
- burndown chart, Make Definition of Done Explicit
C
- car industry, Introduction
- changes, tracking, Tracking Changes
- CI (see Continuous Integration)
- classification, scaling of, Assumption: Measurements are comparable
- code integration, regularity of, Integrate Your Code Regularly
- code quality control, Code Quality Control, Metrics Overview
- code, testable, Automated Testing Reduces the Number of Bugs
- codebase, estimating weak spots in, Managing Test Automation in Practice
- coding style, Coding Style
- commit messages, version control systems and, Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
- commits
- CI and, Important Best Practices for CI
- process standards and, Defining Process Standards
- specificity/regularity of, Commit Specifically and Regularly
- time between, Controlling Versions in Practice
- consistency, development standards and, Development Standards Lead to Predictable Software Development
- continuous delivery, CI Facilitates Further Automation
- Continuous Integration (CI), Use Continuous Integration-Metrics Overview
- automated deployment vs., Automate Deployment
- best practice application, How to Apply the Best Practice
- common objections to metrics, Common Objections to Continuous Integration Metrics
- controlling, Controlling Continuous Integration
- dedicated server for, Requirement: CI Server
- field experience, Metrics Overview
- metrics overview, Metrics Overview
- motivation for, Motivation
- control
- defined, Software Development as an Observable Process
- measurement and, Preface, Software Development as an Observable Process
- controlled DTAP, Control Development, Test, Acceptance, and Production Environments-Metrics Overview
- best practice application, How to Apply the Best Practice
- common objections to metrics, Common Objections to DTAP Control Metrics
- development bottleneck discovery with, Controlled DTAP Reveals Development Bottlenecks and Explains Problems More Easily
- field experience, Metrics Overview
- GQM model for measuring in practice, Measuring the DTAP Street in Practice-Measuring the DTAP Street in Practice
- lead time predictions and, Controlled DTAP Allows for Good Predictions
- metrics overview, Metrics Overview
- motivation for, Motivation
- reduction of dependence on specialist knowledge, Controlled DTAP Reduces Dependence on Key Personnel
- separation of concerns between development phases, Controlled DTAP Clarifies Responsibilities Between Development Phases
- speed of DTAP street, Objection: A Controlled DTAP Street Is Slow
- test/acceptance environment separation, Objection: There Is No Need to Distinguish Test and Acceptance Environments
- convention over configuration principle, Coding Style
- cost, automated deployment and, Objection: Automating Deployment Is Too Costly
- coverage, by good tests, How to Apply the Best Practice
- craft, Introduction
D
- decision-making, metrics and, Common Objections to GQM
- Definition of Done (DoD), Objection: DoD Makes the Team Feel Less Responsible
- Agile/Scrum background for, Make Definition of Done Explicit
- best practice application, How to Apply the Best Practice-How to Apply the Best Practice
- common objections to using, Common Objections to Using Definition of Done-Objection: Changing the DoD May Mean Extra Work
- elements of, How to Apply the Best Practice
- extra work with, Objection: Changing the DoD May Mean Extra Work
- field experience with, Objection: Changing the DoD May Mean Extra Work
- making explicit, Make Definition of Done Explicit-Objection: Changing the DoD May Mean Extra Work
- motivation for using, Motivation
- overhead and, Objection: DoD Is Too Much Overhead
- proving success with, With a DoD You Can Track Progress and Prove Success
- software quality assurance, A DoD Focuses on Software Quality
- team responsibility and, Objection: DoD Makes the Team Feel Less Responsible
- technical maintenance and, Objection: With DoD There Is No Room for Technical Maintenance
- tracking progress with, With a DoD You Can Track Progress and Prove Success
- DeMarco, Tom, Preface
- dependency management
- reinstalls, Objection: We Cannot Get Control Over Our Build Time
- third-party code and, Measuring Your Dependency Management-Measuring Your Dependency Management
- deployment issues, Objection: Time Spent on Fixing Deployment Issues Is Increasing
- deployment, automated (see automated deployment)
- derived metrics, Metric
- design decisions
- documentation and, Required Elements of System Documentation
- documentation of, Document Just Enough
- developers, importance of contributions, The Contribution of Each Developer Matters
- development best practices (see best practices)
- development bottlenecks, Controlled DTAP Reveals Development Bottlenecks and Explains Problems More Easily
- development capacity, test capacity balance with, Measuring the DTAP Street in Practice
- development environment
- characteristics of, Control Development, Test, Acceptance, and Production Environments
- test environment boundaries and, Controlled DTAP Clarifies Responsibilities Between Development Phases
- Development Process Assessment (DPA), Measuring and Benchmarking Development Process Maturity
- development standards, Standardize the Development Environment-Metrics Overview
- best practice application, How to Apply the Best Practice-Code Quality Control
- best practices enforced by, Development Standards Help Enforce Best Practices
- choosing combinations of technologies, Considerations for Combinations of Technologies
- code quality control, Code Quality Control
- coding style, Coding Style
- common objections to, Common Objections to Standardization
- controlling using GQM, Controlling Standards Using GQM-Controlling Standards Using GQM
- defining process standards, Defining Process Standards
- developers' opinion inventory, Controlling Standards Using GQM
- discussion overhead and, Development Standards Decrease Discussion Overhead
- documentation and, Standardize Tooling and Technologies—and Document It
- field experience, Metrics Overview
- metrics overview, Metrics Overview
- motivation for, Motivation
- on multiple technologies, Objection: Can You Standardize on Multiple Technologies?
- organizational fit, Objection: Organization Unfit for Standardization
- predictability and, Development Standards Lead to Predictable Software Development
- simplification of process/code, Development Standards Simplify Both the Development Process and Code
- standardization of tooling/technologies, Standardize Tooling and Technologies—and Document It
- violations and, Objection: We Cannot Work Like This!
- Development, Test, Acceptance, and Production (DTAP)
- controlled (see controlled DTAP)
- controlled vs. uncontrolled, Motivation
- Dijkstra, Edsger, Control Development, Test, Acceptance, and Production Environments
- direct metrics, Metric
- distributed version control, Control Code Versions and Development Branches
- documentation, Document Just Enough-Metrics Overview
- best practice application, How to Apply the Best Practice
- common objections to, Common Objections to Documentation
- discussion minimization, Documentation Retains Knowledge and Helps to Avoid Discussion
- field experience, Metrics Overview
- goal assessment and, Documentation Helps You to Know Whether You Are Reaching Your Goals
- keeping current, concise, accessible, Keep Documentation Current, Concise, and Accessible
- knowledge retention, Documentation Retains Knowledge and Helps to Avoid Discussion
- level of detail for, Keep Documentation Current, Concise, and Accessible, Metrics Overview
- maintenance burden of, Managing Your Documentation
- managing, Managing Your Documentation-Managing Your Documentation
- metrics overview, Metrics Overview
- motivation for, Motivation
- required elements, Required Elements of System Documentation
- scattered knowledge about system and, Objection: Knowledge about System Is Scattered
- team disagreements on, Objection: Disagreement in the Team
- testing and, Automated Testing Reduces the Number of Bugs
- time limitations, Objection: No Time to Write Documentation
- DoD (see Definition of Done)
- DPA (Development Process Assessment), Measuring and Benchmarking Development Process Maturity
- DTAP (Development, Test, Acceptance, and Production)
- controlled (see controlled DTAP)
- controlled vs. uncontrolled, Motivation
E
- end-to-end tests, How to Apply the Best Practice
- environments (see also development environment; production environment; test environment; acceptance environment)
- inconsistencies between, Control Development, Test, Acceptance, and Production Environments
- separation of concerns between development phases, Controlled DTAP Clarifies Responsibilities Between Development Phases
- expectations, deviations of metrics from, Find Explanations Instead of Judgments When Metrics Deviate from Expectations
- experienced (subjective) quality, Software Product Quality in ISO 25010
- explanations, judgments vs., Find Explanations Instead of Judgments When Metrics Deviate from Expectations
- external dependencies, third-party code and, Measuring Your Dependency Management
F
- Farley, David, Automate Deployment
- feedback
- average cycle length, Measuring the DTAP Street in Practice
- CI and, CI Gives Feedback Quickly and Thereby Speeds Up Bug Fixing
- integration errors and, Controlling Continuous Integration
G
- generated code, version control and, Control Code Versions and Development Branches
- Git, Control Code Versions and Development Branches
- goal assessment, documentation as means of, Documentation Helps You to Know Whether You Are Reaching Your Goals
- Goal-Question-Metric (GQM) approach, The Goal-Question-Metric Approach
- as means of choosing metrics, Software Development as an Observable Process
- automated deployment, Measuring the Deployment Process-Measuring the Deployment Process
- automated testing, Managing Test Automation in Practice-Assumptions Regarding These Metrics
- best practice application with, How to Apply the Best Practice-Metric
- common objections to, Common Objections to GQM
- controlling development standards with, Controlling Standards Using GQM-Controlling Standards Using GQM
- deriving metrics from measurement goals, Derive Metrics from Your Measurement Goals-Objection: Yes, Good Metric, but We Cannot Measure This
- documentation management, Managing Your Documentation
- for measuring DTAP street in practice, Measuring the DTAP Street in Practice-Measuring the DTAP Street in Practice
- for third-party code dependency management, Measuring Your Dependency Management-Measuring Your Dependency Management
- goal definition with, Goal
- making assumptions about metrics explicit, Make Assumptions about Your Metrics Explicit-Using Norms with the GQM Approach
- metrics in, Metric
- motivation for using, Motivation
- questions in, Question
- using norms with, Using Norms with the GQM Approach
- version control and, Control Code Versions and Development Branches-Metrics Overview
- version control systems, Controlling Versions in Practice-Controlling Versions in Practice
- goals
- definition for GQM, Goal
- deriving metrics from, Derive Metrics from Your Measurement Goals-Objection: Yes, Good Metric, but We Cannot Measure This
- (see also Goal-Question-Metric approach)
- five characteristics of, Goal
- GQM approach (see Goal-Question-Metric approach)
H
- high-level tests, How to Apply the Best Practice
- Humble, Jez, Automate Deployment
I
- inconsistencies
- between environments, Control Development, Test, Acceptance, and Production Environments
- in metrics, Objection: Yes, Good Metric, but We Cannot Measure This
- industrial process, Introduction
- inherent (product) quality, Software Product Quality in ISO 25010
- integration
- speed of, Controlling Continuous Integration
- tests, How to Apply the Best Practice
- ISO 25010, About the Software Improvement Group (SIG)
- quality in use model, Software Product Quality in ISO 25010
- software product quality model, Software Product Quality in ISO 25010
- software quality according to, Software Quality According to the ISO 25010 Standard
- isolation of tests, How to Apply the Best Practice
- issue resolution time, Controlling Versions in Practice, Measuring the DTAP Street in Practice
- iterations, short, Make Definition of Done Explicit
J
- judgments, explanations vs., Find Explanations Instead of Judgments When Metrics Deviate from Expectations
K
- kanban boards, Make Definition of Done Explicit
- Knuth, Donald, Automate Tests
L
- lead time predictions, Controlled DTAP Allows for Good Predictions
- legacy systems, Objection: No Need to Automate Because of Infrequent Releases
M
- maintenance
- development standards and, Development Standards Simplify Both the Development Process and Code
- documentation and, Managing Your Documentation
- of tests, How to Apply the Best Practice
- third-party code and, Managing Usage of Third-Party Code Makes a System’s Behavior More Predictable, Determine the Specific Maintainability Advantages of Using an External Codebase, Objection: Does Third-Party Code Actually Lead to Maintenance Benefits?
- manual merging, CI vs., CI Is More Reliable Than Manual Merging
- maturity of team, Objection: Changing the DoD May Mean Extra Work
- McCabe complexity, Metric
- measured observations, Software Development as an Observable Process
- measurement, Software Development as an Observable Process
- (see also metrics)
- control and, Preface, Software Development as an Observable Process
- scaling of classification, Assumption: Measurements are comparable
- Mercurial, Control Code Versions and Development Branches
- merging
- CI vs. manual, CI Is More Reliable Than Manual Merging
- speed of, Controlling Continuous Integration
- version control systems and, Version Control Allows Automatic Merging of Versions
- metric in a bubble, Motivation
- metric pitfalls, Motivation, Avoid the Metric Pitfalls
- metrics
- assumptions about, Make Assumptions about Your Metrics Explicit-Using Norms with the GQM Approach
- averages vs. outliers, Assumption: Averages are more important than outliers
- common objections to/solutions for, Objection: Yes, Good Metric, but We Cannot Measure This
- common pitfalls in selecting/applying, Motivation
- comparable meanings of, Assumption: Measurements are comparable
- decision-making and, Common Objections to GQM
- deriving from measurement goals, Derive Metrics from Your Measurement Goals-Objection: Yes, Good Metric, but We Cannot Measure This
- (see also Goal-Question-Metric approach)
- finding explanations for deviations from expectations, Find Explanations Instead of Judgments When Metrics Deviate from Expectations
- trends vs. facts, Assumption: Trends are more important than precise facts
- metrics galore, Motivation
- mocking, How to Apply the Best Practice
- modification, independent, Version Control Allows Independent Modification
- Mozi, Standardize the Development Environment
N
- norms, GQM and, Using Norms with the GQM Approach
O
- objective metrics, Metric
- one-track metric, Motivation, Controlling Versions in Practice
- open-source third-party code, Third-Party Code Has at Least Base-Level Quality, Measuring Your Dependency Management
- outliers, averages vs., Assumption: Averages are more important than outliers
- overhead
P
- Pascal, Blaise, Document Just Enough
- patching policies, Metrics Overview
- permission, for deployment, Objection: We Are Not Allowed to Deploy in Production By Ourselves
- personnel, key
- automated deployment and, Automated Deployment Is Fast and Efficient
- controlled DTAP and, Controlled DTAP Reduces Dependence on Key Personnel
- perverse incentives, Avoid the Metric Pitfalls
- planning, Agile, Make Definition of Done Explicit
- portability, automated deployment and, Automated Deployment Is Flexible
- precision, trends vs., Assumption: Trends are more important than precise facts
- predictability
- development standards and, Development Standards Lead to Predictable Software Development
- process and, Introduction
- predictions, lead time, Controlled DTAP Allows for Good Predictions
- process control
- as continuous activity, Software Development as an Observable Process
- defined, Software Development as an Observable Process
- process frameworks, What This Book Is Not
- process standards, Defining Process Standards
- product (inherent) quality, Software Product Quality in ISO 25010
- Product owner, Make Definition of Done Explicit
- production environment
- acceptance environment boundary and, Controlled DTAP Clarifies Responsibilities Between Development Phases
- characteristics of, Control Development, Test, Acceptance, and Production Environments
- importance of resembling test environment, How to Apply the Best Practice
- productivity, functionality implemented as measure of, Controlling Versions in Practice
- progress, tracking with DoD, With a DoD You Can Track Progress and Prove Success
Q
- quality
- DoD and, A DoD Focuses on Software Quality
- experienced vs. inherent, Software Product Quality in ISO 25010
- importance of defining, Objection: DoD Is Too Much Overhead
- ISO 25010 standard, Software Quality According to the ISO 25010 Standard
- unit tests and, Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
- quality champion, Objection: Disagreement in the Team
- quality control
- code standards and, Code Quality Control, Metrics Overview
- documentation and, Quality control is enforced to keep the nonfunctional requirements in check
- third-party code, Third-Party Code Has at Least Base-Level Quality
- questions, in GQM approach, Question
R
- regressions, Control Code Versions and Development Branches
- reinstalls, Objection: We Cannot Get Control Over Our Build Time
- releases, infrequent, Objection: No Need to Automate Because of Infrequent Releases
- reliability, automated deployment and, Measuring the Deployment Process
- responsibility(-ies) of team, Objection: DoD Makes the Team Feel Less Responsible
- rollbacks, automated deployment and, How to Apply the Best Practice
- root cause analysis
- automated deployment and, Automated Deployment Simplifies Root Cause Analysis
- of bugs, Automated Testing Finds Root Causes of Bugs Earlier with Little Effort
S
- sanity tests, How to Apply the Best Practice
- (see also end-to-end tests)
- scaling of classification, Assumption: Measurements are comparable
- scope, DoD and, How to Apply the Best Practice
- Scrum, Make Definition of Done Explicit
- (see also Agile/Scrum methodology)
- short iterations, Make Definition of Done Explicit
- SIG (Software Improvement Group), About the Software Improvement Group (SIG)
- single platform deployment, Objection: Single Platform Deployment Does Not Need Automation
- SMART nonfunctional requirements, Objection: Changing the DoD May Mean Extra Work
- SMART test criteria, Metrics Overview
- smoke tests, How to Apply the Best Practice
- (see also end-to-end tests)
- software development
- as observable process, Software Development as an Observable Process
- best practices overview, An Overview of the Development Best Practices in This Book
- importance of each developer's contribution, The Contribution of Each Developer Matters
- measuring/benchmarking development process maturity, Measuring and Benchmarking Development Process Maturity
- separation of concerns between development phases, Controlled DTAP Clarifies Responsibilities Between Development Phases
- Software Improvement Group (SIG), About the Software Improvement Group (SIG)
- software quality, A DoD Focuses on Software Quality
- (see also quality)
- according to ISO 25010 standard, Software Quality According to the ISO 25010 Standard
- DoD and, A DoD Focuses on Software Quality
- source code, independent modification of, Version Control Allows Independent Modification
- source files, merging of, Version Control Allows Automatic Merging of Versions
- specialist knowledge
- automated deployment and, Automated Deployment Is Fast and Efficient
- controlled DTAP and, Controlled DTAP Reduces Dependence on Key Personnel
- sprint planning, Make Definition of Done Explicit
- stakeholder, Make Definition of Done Explicit
- standardization
- of development (see development standards)
- third-party code and, How to Apply the Best Practice
- static code analysis, Code Quality Control
- story point, Make Definition of Done Explicit
- stubbing, How to Apply the Best Practice
- style checkers, Coding Style
- style of coding, Coding Style
- subjective (experienced) quality, Software Product Quality in ISO 25010
- subjective metrics, Metric
- Subversion, Control Code Versions and Development Branches
- success, proving with DoD, With a DoD You Can Track Progress and Prove Success
T
- TDD (Test Driven Development), Automated Testing Reduces the Number of Bugs
- team maturity, Objection: Changing the DoD May Mean Extra Work
- technical maintenance, Objection: With DoD There Is No Room for Technical Maintenance
- technology choices, documentation of, Keep Documentation Current, Concise, and Accessible
- test capacity, development capacity and, Measuring the DTAP Street in Practice
- Test Driven Development (TDD), Automated Testing Reduces the Number of Bugs
- test environment
- acceptance environment boundary, Controlled DTAP Clarifies Responsibilities Between Development Phases
- acceptance environment failures, Measuring the DTAP Street in Practice
- acceptance environment vs., Objection: There Is No Need to Distinguish Test and Acceptance Environments
- characteristics of, Control Development, Test, Acceptance, and Production Environments
- development environment boundaries, Controlled DTAP Clarifies Responsibilities Between Development Phases
- importance of resembling production environment, How to Apply the Best Practice
- test failures, How to Apply the Best Practice
- test maintenance, How to Apply the Best Practice
- testing approach
- automated (see automated testing)
- black-box tests, Automate Tests
- end-to-end tests, How to Apply the Best Practice
- high-level tests, How to Apply the Best Practice
- sanity tests, How to Apply the Best Practice
- smoke tests, How to Apply the Best Practice
- third-party code, Objection: Safety and Dependability of Third-Party Libraries
- unit tests (see unit tests)
- third-party code
- base-level quality of, Third-Party Code Has at Least Base-Level Quality
- best practice application, How to Apply the Best Practice-Manage the Usage and Versions of Libraries and Frameworks Centrally
- central repository for, Manage the Usage and Versions of Libraries and Frameworks Centrally
- change of library source code by developers, Do Not Let Developers Change Library Source Code
- common objections to metrics, Common Objections to Third-Party Code Metrics
- dependency management measurement, Measuring Your Dependency Management-Measuring Your Dependency Management
- dependency updates, Ensure Quick Response to Dependency Updates
- determining maintainability advantages of, Determine the Specific Maintainability Advantages of Using an External Codebase
- field experience, Metrics Overview
- maintenance benefit determination, Objection: Does Third-Party Code Actually Lead to Maintenance Benefits?
- management of usage, Manage Usage of Third-Party Code-Metrics Overview
- metrics overview, Metrics Overview
- motivation for using, Motivation-Managing Usage of Third-Party Code Makes a System’s Behavior More Predictable
- predictability of system behavior, Managing Usage of Third-Party Code Makes a System’s Behavior More Predictable
- safety/dependability, Objection: Safety and Dependability of Third-Party Libraries
- time/effort savings with, Using Third-Party Code Saves Time and Effort
- update management, Keep Third-Party Code Up-to-Date
- update problems, Objection: We Cannot Update a Particular Library
- tooling
- automated deployment and, How to Apply the Best Practice
- standardization of, Standardize Tooling and Technologies—and Document It
- treating the metric, Motivation, Controlling Versions in Practice
- treemap report, Managing Test Automation in Practice
- trends, precise numbers vs., Assumption: Trends are more important than precise facts
U
- unit tests, Automate Tests, How to Apply the Best Practice
- for code that is already working, Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
- quality and, Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
- third-party code and, Ensure Quick Response to Dependency Updates
- unsupported libraries, Keep Third-Party Code Up-to-Date
- updates
- deployment automation and, Metrics Overview
- third-party code, Keep Third-Party Code Up-to-Date
- user acceptance, DoD and, Make Definition of Done Explicit
- user stories, Make Definition of Done Explicit
V
- velocity, of a development team, Make Definition of Done Explicit
- version control systems
- automatic merging, Version Control Allows Automatic Merging of Versions
- basics, Control Code Versions and Development Branches
- best practice application, How to Apply the Best Practice-Integrate Your Code Regularly
- CI and, Requirement: Version Control
- code integration and, Integrate Your Code Regularly
- commit messages and, Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
- commits and, Commit Specifically and Regularly
- common objects to metrics for, Common Objections to Version Control Metrics
- field experience, Metrics Overview
- GQM and, Control Code Versions and Development Branches-Metrics Overview
- in practice, Controlling Versions in Practice-Controlling Versions in Practice
- inconsistent use of, Objection: We Use Different Version Control Systems
- metrics overview, Metrics Overview
- motivation for using, Motivation
- recommendation measurement, Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
- versions, automatic merging of, Version Control Allows Automatic Merging of Versions
- violations, development standards and, Controlling Standards Using GQM-Controlling Standards Using GQM, Objection: We Cannot Work Like This!
- Voltaire, Next Steps
W
- Whistler, James McNeill, Manage Usage of Third-Party Code
- white-box tests, Automate Tests
- Wilde, Oscar, Introduction, Control Code Versions and Development Branches, Manage Usage of Third-Party Code
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.