# Software Quality

> A field guide to knowing whether your software works — types, tests, fuzzing, monitoring, proof — with the evidence for each, or a note where there is none.

Ways to find out whether software works: types, static analysis, tests, fuzzing, contracts, formal methods, monitoring — one page each, with the tools that implement the method and the evidence behind it. Recommendations carry their evidence, or a plain note where it is thin; practices that rest on repetition rather than data are named as folklore.

## Overview

- [Home](https://quality.stereobooster.com/index.md): A field guide to knowing whether your software works.
- [Choosing methods](https://quality.stereobooster.com/choosing.md): A step-by-step for deciding which quality checks to add, and in what order.
- [Glossary](https://quality.stereobooster.com/glossary.md): The vocabulary the method pages rely on: terms the project coins or narrows, and the industry shorthand those pages assume.
- [About this project](https://quality.stereobooster.com/about.md): How the content here is checked, and what that checking does not cover.

## Quality dimensions

- [Quality dimensions](https://quality.stereobooster.com/quality-dimensions.md): There is no single measure of quality, only distinct ways it fails.
- [Functionality](https://quality.stereobooster.com/functionality.md): Does the software do what it claims?
- [Security](https://quality.stereobooster.com/security.md): Does it hold up against someone trying to break it?
- [Reliability](https://quality.stereobooster.com/reliability.md): Does it keep working when parts of it fail?
- [Performance](https://quality.stereobooster.com/performance.md): Is it fast enough, and does it stay fast under load?
- [Maintainability](https://quality.stereobooster.com/maintainability.md): Can the next team change it safely?
- [Comparing quality frameworks](https://quality.stereobooster.com/comparison.md): Our dimensions mapped against ISO 25010, CISQ, Garvin, McCall, Boehm, and FURPS.

## The axes

- [The axes](https://quality.stereobooster.com/axes.md): The project classifies every verification method by where its inputs come from and how its output is judged.
- [Input](https://quality.stereobooster.com/input.md): The input is the data the code under test runs on.
- [Oracle](https://quality.stereobooster.com/oracle.md): The oracle is how a method decides an output is correct.
- [Guarantee](https://quality.stereobooster.com/guarantee.md): The guarantee is how strong a claim a passing run makes: from a guess that nothing obvious is broken, up to a proof that the failure cannot occur at all.
- [Effect scope](https://quality.stereobooster.com/effect.md): Effect is what the code under test touches — state, I/O, and nondeterminism.

## Methods

- [Methods — index and classification](https://quality.stereobooster.com/methods.md): This index puts every verification method on a row, classified on the axes from the project's methodology and tagged with the quality dimensions it serves.
- [Types and effects](https://quality.stereobooster.com/types.md): Catching whole classes of error before the program runs.
- [Static types](https://quality.stereobooster.com/static-types.md): Static types declare the shape of every value a program handles, and the compiler enforces that declaration before the program runs.
- [Linear types](https://quality.stereobooster.com/linear-types.md): Linear and substructural type systems constrain not what a value is but how it is used: how many times, and in what order.
- [Effect systems](https://quality.stereobooster.com/effect-systems.md): An effect system extends a function's type to say what the function does, not just what it returns.
- [Refinement and dependent types](https://quality.stereobooster.com/refinement-and-dependent-types.md): Refinement and dependent type systems push the boundary of what a type system can express past shape and into predicates over values.
- [Static analysis](https://quality.stereobooster.com/static-analysis.md): Reading the source without running it, from cheap linters to whole-program dataflow.
- [Linters](https://quality.stereobooster.com/linters.md): A linter scans source a file at a time, matching it against a rule set of suspicious patterns and reporting likely bugs.
- [Secret scanning](https://quality.stereobooster.com/secret-scanning.md): Secret scanning searches a repository for committed credentials, matching each string against regex rules and scoring it for entropy.
- [Deep static analysis](https://quality.stereobooster.com/deep-static-analysis.md): Deep static analysis decides a property of the program by building a model of it first.
- [Dead-code detection](https://quality.stereobooster.com/dead-code-detection.md): Dead-code detection finds code no execution can run and values no execution can read, without running the program.
- [Clone detection](https://quality.stereobooster.com/clone-detection.md): Clone detection is a similarity search over code.
- [Database migration safety](https://quality.stereobooster.com/migration-safety.md): Migration-safety analysis checks a schema migration against a rule set of known hazards, and flags the statements that are unsafe to run online.
- [Example tests](https://quality.stereobooster.com/example-tests.md): An example test pairs a hand-picked input with an assertion about what the code does with it.
- [Snapshot and approval testing](https://quality.stereobooster.com/snapshot-testing.md): A snapshot test, also called an approval test, compares a run's output against a stored capture of that same output taken earlier.
- [Property-based testing](https://quality.stereobooster.com/property-based-testing.md): Property-based testing checks a property the author writes against inputs the framework generates to try to falsify it.
- [Combinatorial and pairwise testing](https://quality.stereobooster.com/combinatorial-testing.md): Combinatorial testing checks every combination of any two parameter values with a small set of test rows, rather than the full product of every option.
- [Fuzzing](https://quality.stereobooster.com/fuzzing.md): Fuzzing is an automated testing method that runs a program on generated inputs and reports a crash, undefined behavior or a sanitizer violation as a failure.
- [Automated test generation](https://quality.stereobooster.com/automated-test-generation.md): Automated test generation builds a runnable test suite without a developer writing the cases by hand.
- [Differential testing](https://quality.stereobooster.com/differential-testing.md): Differential testing runs the implementation under test and a second, independently trusted implementation on the same inputs, then compares outputs.
- [Metamorphic testing](https://quality.stereobooster.com/metamorphic-testing.md): Metamorphic testing checks a program without knowing the right answer, by changing the input in a way whose effect on the output is predictable.
- [Statistical and sampling testing](https://quality.stereobooster.com/statistical-testing.md): Statistical and sampling testing runs the system many times and judges the outcomes together, because one run of a varying system settles nothing.
- [Deterministic simulation testing](https://quality.stereobooster.com/deterministic-simulation-testing.md): A deterministic simulation testing (DST) harness replaces every non-deterministic input with a controlled equivalent driven by a single seed.
- [Chaos engineering](https://quality.stereobooster.com/chaos-engineering.md): Chaos engineering injects faults into a production-like or production system and verifies that the system survives.
- [Fault injection](https://quality.stereobooster.com/fault-injection.md): Fault injection deliberately triggers the failures a system is meant to tolerate, to check that the code written to handle them actually does.
- [Search-based software testing (SBST)](https://quality.stereobooster.com/search-based-software-testing.md): Search-based software testing (SBST) casts a testing activity as an optimization problem.
- [Contracts and runtime assertions](https://quality.stereobooster.com/contracts-and-runtime-assertions.md): A contract attaches preconditions, postconditions, and invariants to a function or interface.
- [Schema and boundary validation](https://quality.stereobooster.com/schema-and-boundary-validation.md): Schema validation checks that data arriving from outside a program satisfies a declared shape and set of constraints before the program acts on it.
- [Monitoring and observability](https://quality.stereobooster.com/monitoring-and-observability.md): Monitoring and observability read what a running system is actually doing from the signals it emits in production.
- [Parallel run](https://quality.stereobooster.com/parallel-run.md): A parallel run is a comparison of two implementations on the same live request. The existing one is the control and the new one the candidate.
- [Change-point detection](https://quality.stereobooster.com/change-point-detection.md): Change-point detection reads the whole series of a metric measured over many commits and locates the point where its distribution shifted.
- [Formal methods](https://quality.stereobooster.com/formal.md): Mathematical reasoning over a specification or program.
- [Model checking](https://quality.stereobooster.com/model-checking.md): Model checking explores every reachable state of a formal, executable model of a system and reports any violation of a stated property.
- [Bounded model checking](https://quality.stereobooster.com/bounded-model-checking.md): Bounded model checking (BMC) unrolls a program to a fixed depth k and asks a SAT or SMT solver whether any execution within that bound violates an assertion.
- [Systematic concurrency testing](https://quality.stereobooster.com/systematic-concurrency-testing.md): Systematic concurrency testing takes control of a concurrent program's scheduler and drives the real implementation through its possible interleavings.
- [Probabilistic model checking](https://quality.stereobooster.com/probabilistic-model-checking.md): Probabilistic model checking computes how likely a system is to meet a requirement, rather than whether it can fail at all.
- [Theorem proving](https://quality.stereobooster.com/theorem-proving.md): Theorem proving establishes that a program meets a specification by machine-checked proof.
- [Symbolic execution](https://quality.stereobooster.com/symbolic-execution.md): Symbolic execution runs a program with placeholders in place of real inputs, and tracks the constraints each path puts on them.
- [Abstract interpretation](https://quality.stereobooster.com/abstract-interpretation.md): Abstract interpretation reasons about every possible run of a program at once, by computing with ranges of values instead of actual ones.
- [Termination analysis](https://quality.stereobooster.com/termination-analysis.md): Termination analysis proves that a program (or a particular loop or recursion) always halts, rather than running forever.
- [Worst-case execution-time analysis](https://quality.stereobooster.com/wcet-analysis.md): Worst-case execution-time (WCET) analysis computes an upper bound on a task's running time, guaranteed by construction rather than measured.
- [Equivalence checking](https://quality.stereobooster.com/equivalence-checking.md): Equivalence checking proves that two implementations compute the same output for every input, rather than testing them on a sample.
- [Decision tables](https://quality.stereobooster.com/decision-tables.md): A decision table is a grid: one row per combination of input conditions, one column per condition, one final column for the decision.
- [Exhaustive coverage (MC/DC, MCC)](https://quality.stereobooster.com/exhaustive-coverage.md): Exhaustive coverage tries every combination of conditions in a decision and checks the correct answer for each.
- [State machines and statecharts](https://quality.stereobooster.com/state-machines.md): A state machine encodes a finite set of states and the legal transitions between them.
- [Executable specifications](https://quality.stereobooster.com/executable-specifications.md): An executable specification is a second implementation that exists to be run — typically slow, obvious, and short.
- [Contracts as specifications](https://quality.stereobooster.com/contracts-as-specifications.md): A contract is a predicate on an interface — what an operation requires of its caller, and what it guarantees in return.
- [Threat modeling](https://quality.stereobooster.com/threat-modeling.md): Threat modeling walks a system's architecture and enumerates what an attacker could do to it.
- [Penetration testing](https://quality.stereobooster.com/penetration-testing.md): Penetration testing puts a human adversary against a running system.
- [Taint analysis](https://quality.stereobooster.com/taint-analysis.md): Taint analysis follows untrusted data through a program and flags any path on which it reaches a dangerous operation unsanitized.
- [Supply-chain hygiene](https://quality.stereobooster.com/supply-chain-hygiene.md): Supply-chain hygiene is the set of practices that keep a project's dependencies from becoming a delivery channel for attackers.
- [Agent security testing](https://quality.stereobooster.com/agent-security-testing.md): Agent security testing checks whether attacker-controlled text can make an agent call a tool the user did not authorize.
- [Verifying safety-critical systems](https://quality.stereobooster.com/safety.md): A safety-critical system is one whose failure can cause physical harm: an aircraft flight controller, an anti-lock brake, an infusion pump, a rail interlocking.
- [Safety analysis](https://quality.stereobooster.com/safety-analysis.md): Safety analysis is the design-time discipline of working out how a system can fail or cause harm, then turning that into requirements and mitigations.
- [Testing autonomous systems](https://quality.stereobooster.com/testing-autonomous-systems.md): Testing an autonomous or cyber-physical system means showing it stays safe across the situations it will meet in the open world.
- [Temporal-logic falsification](https://quality.stereobooster.com/temporal-logic-falsification.md): Temporal-logic falsification searches for an input signal that drives a system to break a requirement about its behavior over time.
- [Algorithmic complexity testing](https://quality.stereobooster.com/algorithmic-complexity.md): Algorithmic complexity is a performance property: how an operation's cost grows with the size of its input.
- [Load and stress testing](https://quality.stereobooster.com/load-and-stress-testing.md): Load and stress testing drives a deployable system with synthetic traffic to measure its behavior under demand.
- [Profiling](https://quality.stereobooster.com/profiling.md): A profiler measures where a program spends its time, memory, allocations, or other resources, and attributes the cost to the code that incurred it.
- [Microbenchmarking](https://quality.stereobooster.com/microbenchmarking.md): A microbenchmark measures the performance of one small unit: a function, an algorithm, a data-structure operation.
- [Testing machine-learning systems](https://quality.stereobooster.com/testing-ml-systems.md): Testing a machine-learning system means testing without an oracle: the model's logic is learned from data, so for most inputs nobody knows the correct output.
- [Testing GUI and mobile applications](https://quality.stereobooster.com/testing-gui-and-mobile-apps.md): Testing a GUI application means driving it through its interface, because that is the only way in.
- [Verifying concurrency](https://quality.stereobooster.com/concurrency.md): A concurrency bug depends on the timing or interleaving of operations that run at the same time.
- [Verifying memory safety](https://quality.stereobooster.com/memory.md): A memory error is a program mishandling its own storage.
- [Verifying numerical code](https://quality.stereobooster.com/numbers.md): A numerical bug is a program that computes the wrong number and returns it without failing.
- [Verifying time and date handling](https://quality.stereobooster.com/time-and-date.md): A time-and-date bug is a program computing the wrong when.
- [The test suite as an object](https://quality.stereobooster.com/test-suite.md): The suite as an object of study: how effective it is, what it costs, and how to keep it healthy.
- [Coverage](https://quality.stereobooster.com/coverage.md): Coverage measures which parts of the program a test suite executed: reachability, not correctness.
- [Mutation testing](https://quality.stereobooster.com/mutation-testing.md): Mutation testing introduces small synthetic bugs (mutants) into the code and runs the test suite against each mutant.
- [Test case prioritization](https://quality.stereobooster.com/test-case-prioritization.md): Prioritization orders the whole suite so that the tests most likely to reveal a fault run first.
- [Regression test selection](https://quality.stereobooster.com/regression-test-selection.md): Regression test selection asks, for a specific change, which tests could behave differently, and skips the rest for this run.
- [Test suite minimization](https://quality.stereobooster.com/test-suite-minimization.md): Minimization is the regression-suite management technique that permanently removes tests judged redundant against a criterion, typically coverage.
- [Flaky tests](https://quality.stereobooster.com/flaky-tests.md): A flaky test passes and fails on the same code, so a red run may mean a defect or may mean nothing, and telling which requires a human to look.
- [Measuring test-suite effectiveness](https://quality.stereobooster.com/measuring-test-effectiveness.md): Test-suite effectiveness is the field's term for how good the tests are: a suite's ability to detect faults.
- [Regression-suite management](https://quality.stereobooster.com/regression-management.md): Regression-suite management takes the suite as its object rather than the code, and decides which of its tests to run, in what order, and which to drop.
- [Code review](https://quality.stereobooster.com/code-review.md): Code review is the practice of developers other than the author reading a change, commenting on it, and approving or blocking it before it lands.
- [Architecture Decision Records](https://quality.stereobooster.com/adrs.md): An Architecture Decision Record is a short document that records one architectural decision.
- [Refactoring practice](https://quality.stereobooster.com/refactoring-practice.md): A refactor reduces accidental complexity: the cognitive cost a program adds beyond what its problem requires. Behavior and delivered capability stay fixed.
- [Git-history hotspots](https://quality.stereobooster.com/git-hotspots.md): A git-history hotspot is a file that changes often and is touched by bug-fix commits.
- [Requirements quality checking](https://quality.stereobooster.com/requirements-quality-checking.md): Requirements quality checking reviews a draft specification against a set of quality rules, before any code is written.
- [Checklists](https://quality.stereobooster.com/checklists.md): A checklist is a fixed list of items, verified in a fixed order at a fixed point in a procedure, by the people carrying that procedure out.

## AI

- [How AI fits into software quality](https://quality.stereobooster.com/ai.md): AI changes the economics of verification, but not uniformly.
- [Agent experience](https://quality.stereobooster.com/ai-agent-experience.md): Agent experience (AX) names the friction between a codebase and an autonomous coding agent working in it.
- [AI tooling for domain-specific methods](https://quality.stereobooster.com/ai-domain.md): Domain-specific methods lean on expert judgment, so AI stands in for the expert rather than feeding a checker.
- [AI tooling for formal methods](https://quality.stereobooster.com/ai-formal.md): The artifact AI produces here is a specification, and an engine that can refuse it stands behind every entry.
- [Bugs in AI-generated code](https://quality.stereobooster.com/ai-generated-code-bugs.md): AI-generated code carries a characteristic failure mode: output that compiles and reads as correct but does the wrong thing.
- [AI tooling for process methods](https://quality.stereobooster.com/ai-process.md): These methods run on human judgment, so AI is taking a turn at the judging rather than automating a check.
- [AI tooling for requirements engineering](https://quality.stereobooster.com/ai-requirements-tools.md): AI tooling for requirements engineering splits in two: gathering produces requirements from informal input, and detection audits the ones that exist.
- [AI tooling for runtime and production](https://quality.stereobooster.com/ai-runtime.md): Runtime methods have little AI-native tooling: what exists is mostly a feature inside a general-purpose assistant, or a classical technique that never needed…
- [AI tooling for signals](https://quality.stereobooster.com/ai-signals.md): Coverage, git-history hotspots, and mutation testing are things AI reads to target where to work next, not oracles.
- [AI static analysis](https://quality.stereobooster.com/ai-static-analysis.md): The analyzer stays the oracle in every entry here, and AI works around it: authoring rules, triaging findings, proposing the fix.
- [AI tooling for tests](https://quality.stereobooster.com/ai-tests.md): AI writes tests here, and the runner that executes them cannot tell whether they assert anything worth asserting.
- [AI tooling for types and effects](https://quality.stereobooster.com/ai-types.md): Every method in this family has a checker that can refuse the answer, so AI proposes and the compiler or the solver decides.

## Conventional

- [Conventional testing vocabulary](https://quality.stereobooster.com/conventional.md): This section connects the vocabulary of the testing literature to the project's framework.
- [Design folklore](https://quality.stereobooster.com/design-folklore.md): Design folklore is a prescription about what good code looks like, repeated as settled practice until the doctrine outruns the evidence.
- [Conventional terminology](https://quality.stereobooster.com/terminology.md): The testing literature has accreted decades of vocabulary — unit test, integration test, regression, acceptance, smoke, mock, stub, golden master.
- [Test smells](https://quality.stereobooster.com/test-smells.md): A test smell is a named pattern in test code held to indicate poor test design.
- [Testing folklore](https://quality.stereobooster.com/testing-folklore.md): Five popular testing prescriptions are folklore, repeated as settled practice without measured support.

## Recipes

- [Recipes — per-tool snippets and configs](https://quality.stereobooster.com/recipes.md): A recipe is practical configuration and code for a specific tool.
- [ESLint](https://quality.stereobooster.com/eslint.md): ESLint matches source against a rule set written over the syntax tree: unused bindings, shadowed names, unreachable code.
- [Monocart](https://quality.stereobooster.com/monocart.md): Monocart (monocart-coverage-reports) collects raw V8 coverage from more than one test runner and merges it into one report.
- [Playwright](https://quality.stereobooster.com/playwright.md): Playwright drives a real browser — Chromium, Firefox, or WebKit — through the actions a user performs.
- [TypeScript](https://quality.stereobooster.com/typescript.md): TypeScript is a gradual type system for JavaScript: annotations are checked before the code runs, then erased.