A reference from Weave

Find a term

Understand the metrics, models, and methods behind modern engineering. Clear definitions, practical examples, and a closer look at what the numbers actually mean.

Terms beginning with T

155 terms

  • Test execution time

    Test execution time is a software delivery concept used to describe a specific event, interval, control, or operating condition in the path from source change to production behavior. A useful definition names the boundary, unit, and decision the measure supports.

    DORA and DevOps

  • Test failure rate

    Test failure rate is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test failure triage

    Test failure triage is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test fixture

    Test fixture is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test impact analysis

    Test impact analysis is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test isolation

    Test isolation is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test maintenance

    Test maintenance is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test observability

    Test observability is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test oracle

    Test oracle is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test parallelization

    Test parallelization is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test pass rate

    Test pass rate is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test plan

    Test plan is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test quarantine

    Test quarantine is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test refactoring

    Test refactoring is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Test repeatability

    Test repeatability is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test reporting

    Test reporting is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test reproducibility

    Test reproducibility is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test rerun

    Test rerun is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test result

    Test result is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test review

    Test review is a practical concept in a pull-request workflow that shapes how people examine, discuss, own, or integrate a proposed change.

    Code review

  • Test risk

    Test risk is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test run failure rate

    Test run failure rate is a software delivery concept used to describe a specific event, interval, control, or operating condition in the path from source change to production behavior. A useful definition names the boundary, unit, and decision the measure supports.

    DORA and DevOps

  • Test scenario

    Test scenario is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test selection

    Test selection is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test set

    Test set is a defined lens for examining AI system behavior with a stated task, evidence, and interpretation rule.

    Evaluations and benchmarks

  • Test strategy

    Test strategy is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test suite

    Test suite is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test suite optimization

    Test suite optimization is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Test-first development

    Test-first development is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Testability

    The ease with which software behavior can be isolated, stimulated, observed, and checked.

    Code quality and technical debt

  • Testability risk

    The likelihood that important behavior is difficult to verify reliably before release.

    Code quality and technical debt

  • Testability-driven development

    Testability-driven development is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Theory of constraints

    The theory of constraints focuses improvement on the system's current limiting constraint. The familiar cycle is to identify the constraint, use it effectively, align other work, elevate capacity when needed, and repeat when the constraint moves.

    Flow and capacity planning

  • Threshold alert

    Threshold alert is an alert evaluated when a signal crosses a numeric boundary for a defined duration.

    Reliability and observability

  • Threshold metric

    Threshold metric is a defined lens for examining AI system behavior with a stated task, evidence, and interpretation rule.

    Evaluations and benchmarks

  • Throughput

    Throughput is the number of work items completed during a defined period. In software delivery, the item might be a pull request, deployed change, or customer request, and the chosen item boundary determines what the result means.

    Flow and capacity planning

  • Throughput forecast

    Throughput forecast is a concept used in software delivery planning to describe a condition, relationship, estimate, or decision about engineering work.

    Flow and capacity planning

  • Throughput latency tradeoff

    Throughput latency tradeoff is the serving concept concerned with throughput latency tradeoff during AI inference.

    Inference performance

  • Throughput per gpu

    Throughput per gpu is the serving concept concerned with throughput per gpu during AI inference.

    Inference performance

  • Throughput rate

    Throughput rate is completed work divided by the interval in which it was completed. It is a rate version of throughput and requires a stable definition of item, completion, and time period.

    Flow and capacity planning

  • Throughput variability

    Throughput variability is the spread of completed-item counts across time periods for a defined work population. It affects capacity planning and forecasting because the average rate does not describe every interval.

    Flow and capacity planning

  • Time to approval

    Time to approval measures the elapsed period from a proposed change to the point at which required approval is recorded.

    Code review

  • Time to first byte

    Time to first byte is the serving concept concerned with time to first byte during AI inference.

    Inference performance

  • Time to first change

    Time to first change is the elapsed time from a defined starting event, such as joining a team or creating a service, to a developer's first accepted code change in that environment. The start and completion events must be defined for the comparison to be meaningful.

    Developer productivity

  • Time to first review

    Time to first review is the elapsed time between a reviewable change being submitted and the first substantive reviewer response.

    Code review

  • Time to first token

    Time to first token, or TTFT, is the elapsed time from an inference request being accepted until the first output token is delivered. It captures startup and queue delay before generation becomes visible to a user.

    Inference performance

  • Time to last token

    Time to last token is the serving concept concerned with time to last token during AI inference.

    Inference performance

  • Time to merge

    Time to merge is the elapsed interval from a proposed change entering the workflow to its integration into the target branch.

    Code review

  • Time-based segment

    Time-based segment is an analytical concept for separating engineering observations into populations whose differences may matter to a decision.

    Engineering analytics

  • Time-window metric

    Time-window metric groups observations within a defined period.

    Engineering analytics