A reference from Weave

Find a term

Understand maintainability, code structure, and the costs of decisions that make future changes harder. Learn what quality signals can and cannot establish.

Terms beginning with R

14 terms

  • Recovery testing

    Recovery testing 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

  • Refactoring backlog

    Refactoring backlog 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

  • Refactoring safety

    The confidence that a structural code change preserves externally observable behavior.

    Code quality and technical debt

  • Regression testing

    Regression testing repeats relevant tests after a software change to detect unintended effects on behavior that previously worked. It can use unit, integration, system, or end-to-end tests selected according to the change and the risks it may affect.

    Code quality and technical debt

  • Release debt

    Release debt 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

  • Reliability testing

    Reliability testing 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

  • Remove duplication

    Remove duplication 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

  • Rename refactoring

    Rename 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

  • Resilience debt

    Resilience debt 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

  • Resilience testing

    Resilience testing 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

  • Response for a class

    A measure of the number of methods potentially executed in response to a message received by a class.

    Code quality and technical debt

  • Rework rate

    Rework rate is the proportion of work that must be repeated or revised because the earlier result was incomplete, incorrect, or no longer suitable. Its calculation depends on the work unit and the evidence used to identify rework.

    Code quality and technical debt

  • Risk-based testing

    Risk-based testing 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

  • Rule suppression

    An explicit instruction that prevents a static-analysis rule from reporting a selected code location.

    Code quality and technical debt