A framework for improving quality through short, evidence-based cycles. It follows three steps: Question (define a problem worth solving), Evidence (design targeted metrics to measure it), and Develop (run small, time-boxed experiments to test solutions). Each cycle takes 2 to 4 weeks.

How long it takes to recover from a failure in production once it has been detected.

The percentage of deployments that result in a failure requiring remediation, such as a rollback, hotfix, or incident.

The time it takes for a code commit to reach production.

How often a team successfully releases to production within a given period.

Software delivered over the internet on a subscription basis, hosted and maintained by the provider rather than installed locally. Examples include Slack, Jira, and Salesforce.

DORA metrics are four metrics used to understand software delivery performance. They focus on flow, stability, and recovery rather than individual practice. This makes them organisationally useful, but limits how directly they can guide local quality decisions. The four DORA metrics are: Deployment frequency Shows movement, not confidence. A team can deploy often while still relying on late manual checks and unexamined risk. Lead time for changes Highlights where work is slowing down, but rarely shows why. Delays may appear in testing stages, yet closer inspection often shows that feedback is delayed because tests are hard to interpret or failures arrive too late to be useful. Change failure rate Reflects shared system behaviour. Treating it as a testing KPI creates blame rather than learning. Teams can become defensive, and the metric loses its usefulness. Time to restore service Varies widely depending on context. Where tests encode realistic scenarios and systems are observable, diagnosis is faster. When test coverage is shallow, incidents are harder to understand. How DORA metrics are used by Quality professionals Testers and Quality Engineers use DORA metrics as prompts rather than success criteria. A stable deployment frequency raises questions about where risk is being absorbed. A rising lead time invites investigation into feedback delays. A spike in change failure rate becomes a starting point for exploring escaped defects and test blind spots. DORA metrics help teams decide where to investigate, but they do not tell them what to change. They are too abstract to guide specific improvements. Teams often need something more local and more closely tied to the decisions they make during delivery.

A family of delivery approaches where work moves through clearly defined phases in a fixed order, such as requirements, design, development, testing, and release. Each phase must be completed before the next one begins, and changes late in the process are costly because they require revisiting earlier stages. These models assume stability of requirements and low variability in the delivery process.

DevOps is about collaboration and shared accountability. Developers, operations specialists, and Quality Engineers work together to build and operate reliable systems. Success is measured by how smoothly teams deliver change and recover from failure rather than by the volume of work produced.

In Agile teams, quality is part of everyday work rather than a separate step. The team shapes acceptance criteria, tests early, and adapts when something is not meeting expectations. The Quality Engineer helps turn broad quality goals into practical activities that fit the team’s cadence.

Continuous Integration and Continuous Delivery (CI/CD) is not a development model. It is a set of practices that automate the process of building, testing, and deploying software. The aim is to shorten the time between making a change and understanding its impact.Continuous Integration ensures that code changes are tested and merged frequently, preventing integration problems from accumulating. Continuous Delivery makes every build deployable, which turns releasing into a business decision rather than a technical hurdle.

A “greenfield” project means a new software development project or initiative with no prior codebase or legacy system in place, which gives the development team the freedom to design processes and choose tools without the constraints of legacy architecture.The term originates from the concept of building on undeveloped land, and is contrasted by “brownfield” projects, which involve working with existing systems or codebases, and processes and tools needed to accommodate or integrate with existing components.