glossary
The words behind shipping good software.
Plain-language definitions of the code review, testing, security and performance terms you'll meet on this site.
- Auto-merge
- Merging a pull request automatically once it meets conditions the team has agreed on, such as a clean review, passing tests and a match against the spec. Learn more →
- Autofix
- Automatically writing the code change that resolves a review finding. A safe autofix is checked (type-checked and built, for example) before it is committed, rather than committed on trust. Learn more →
- CLS (Cumulative Layout Shift)
- A Core Web Vital that measures how much visible content unexpectedly moves while a page loads. Lower is better; 0.1 or less is considered good. Learn more →
- Code review
- Examining a proposed code change before it is merged, to catch bugs, security problems and deviations from team conventions, and to share knowledge across the team. Learn more →
- Core Web Vitals
- A set of user-centred performance metrics for loading (LCP), interactivity (INP) and visual stability (CLS). They tell you how fast and smooth a page feels. Learn more →
- CSP (Content Security Policy)
- An HTTP response header that tells the browser which sources of scripts, styles and other content a page may load. A strict CSP limits the damage of cross-site scripting. Learn more →
- CVE (Common Vulnerabilities and Exposures)
- A public catalogue of known security vulnerabilities, each with a unique identifier. Scanners flag libraries in your app that have known CVEs. Learn more →
- DAST (Dynamic Application Security Testing)
- Testing a running application from the outside by sending it crafted requests, the way an attacker would. Because it can be intrusive, it should only run against systems you own. Learn more →
- Diff
- The set of lines added, removed or changed by a code change. Reviewing only the diff misses how the change affects code elsewhere in the repository.
- Domain verification
- Proving you control a domain, typically by adding a DNS TXT record or serving a known file. It is the safeguard that stops active security tests from being pointed at someone else’s site. Learn more →
- Emulator
- Software that imitates a phone on a computer. Useful for quick checks, but it can hide bugs that only show up on real hardware: timing, keyboards, permissions and manufacturer quirks. Learn more →
- End-to-end test
- A test that drives the whole application the way a user would, through the interface and across the backend and data, to confirm a complete flow works. Learn more →
- Exploratory testing
- Testing without a fixed script: exploring the product to discover behaviour nobody thought to check. Automated exploratory testing does this on a schedule and files what it finds. Learn more →
- Flaky test
- A test that sometimes passes and sometimes fails without any change to the code, usually because of timing or shared state. Flaky tests erode trust in the whole suite. Learn more →
- HSTS (HTTP Strict Transport Security)
- A response header that tells browsers to only ever connect to a site over HTTPS, protecting users from downgrade and interception attacks. Learn more →
- INP (Interaction to Next Paint)
- A Core Web Vital that measures how quickly a page responds visually after a user clicks, taps or types. 200 milliseconds or less is considered good. Learn more →
- LCP (Largest Contentful Paint)
- A Core Web Vital that measures how long the largest visible element on a page takes to render. 2.5 seconds or less is considered good. Learn more →
- Lighthouse
- An open-source auditing tool that scores web pages for performance, accessibility, best practices and SEO, with specific recommendations. Learn more →
- Load testing
- Simulating many users at once to measure how response times and error rates hold up under traffic. On the CodeReviewer roadmap.
- Merge conflict
- What happens when two branches change the same lines in different ways and version control cannot combine them automatically. Someone has to decide which change wins. Learn more →
- MITRE ATT&CK
- A public knowledge base of real-world attacker tactics and techniques. Mapping threats to it tells defenders exactly which behaviours to watch for. Learn more →
- OWASP Top 10
- A widely used list of the most critical web application security risks, such as broken access control and injection, published by the Open Worldwide Application Security Project. Learn more →
- OWASP ZAP
- An open-source web application security scanner used for dynamic testing. It can crawl an app and actively probe it for common vulnerabilities. Learn more →
- Passive security scan
- A security check that only looks at normal responses (headers, cookies, transport settings and library versions) without sending any attack traffic. Safe to run against any site. Learn more →
- Performance budget
- A limit a team sets on a performance metric, such as LCP under 2.5 seconds for a page. When a change breaks the budget, it is flagged as a regression. Learn more →
- Pull request
- A request to merge a set of code changes from one branch into another, where the changes are discussed, reviewed and tested before being accepted. Learn more →
- RBAC (Role-based access control)
- Granting permissions based on a person’s role (admin or member, say) rather than one by one. Fine-grained RBAC also controls individual actions such as merging or triggering runs. Learn more →
- Real-device testing
- Running mobile tests on physical phones rather than emulators, so the results reflect the hardware, operating system builds and conditions real users have. Learn more →
- Regression
- A bug where something that used to work stops working after a change. Regression testing re-runs existing tests to catch these before release. Learn more →
- Replay
- Re-running a recorded test against the current version of the application. Once a test is authored, replays can run on a schedule or on demand. Learn more →
- Requirements traceability
- Linking each requirement in a spec to the work that delivers it, so a team can show what is done, what is partial and what is missing. Learn more →
- SAST (Static Application Security Testing)
- Analysing source code for security weaknesses without running it. It complements dynamic testing, which examines the running application.
- Self-healing test
- An automated test that is repaired when the application changes (a renamed button, for example) and re-verified before it counts again, instead of simply failing. Learn more →
- STRIDE
- A threat-modelling framework that groups threats into six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Learn more →
- Test quarantine
- Temporarily separating a flaky test from the main suite so its random failures don’t turn the whole run red, while it is retried and investigated on its own. Learn more →
- Threat model
- A structured view of how a system could be attacked: what is valuable, where the entry points are and which threats apply, so defences can be prioritised. Learn more →
Give every PR the review it deserves.
Start your 15-day free trial. We onboard a few teams every week.