Glossary
Software and quality terms, clearly defined
A reference for testing, security, accessibility and delivery discussions. Each term explains the concept, its practical use and the boundaries that matter when agreeing scope.
A shared vocabulary for delivery decisions
A scope discussion works better when everyone uses the same definition. Regression testing, acceptance testing and a security assessment answer different questions. Confusing those terms can leave one team expecting release assurance while another has planned only a narrow set of checks.
These entries explain what each concept includes, where it is useful and what it does not establish. Use the related terms and service links to move from a definition to the relevant implementation or buying decision. Legal and technical meanings are distinguished where they overlap.
All terms
44 matching items
Accessibility tree
The structured model a browser builds from the DOM and hands to screen readers and other assistive technology.
Authentication vs authorisation
Authentication establishes who is making a request; authorisation decides what that identity is allowed to do.
BDD and Gherkin
A practice of agreeing examples of behaviour before building, and the given-when-then syntax used to write them down.
Black box vs white box testing
Whether the person designing the tests works from the specified behaviour or from the code that implements it.
Boundary value analysis
A design technique that concentrates test cases at the edges of a range, where defects cluster.
Code coverage
The share of your code that was executed while the tests ran, usually reported by line, branch or function.
Continuous integration
The practice of merging every change into one shared branch quickly, with an automated build and test run on each merge.
Contract testing
Verifying that two services still agree on the shape of the messages between them, without running both together.
Core Web Vitals
Google’s three field metrics for loading, responsiveness and visual stability, measured on real visits rather than in a laboratory.
Cross-site request forgery (CSRF)
An attack that makes a logged-in visitor’s browser issue a state-changing request they never intended.
Cross-site scripting (XSS)
A flaw that lets an attacker run their own JavaScript in another visitor’s browser, inside your site’s origin.
CVE
A public identifier assigned to one specific vulnerability, so that everybody discussing it means the same thing.
CVSS
An open standard for scoring the technical severity of a vulnerability on a scale from zero to ten.
Data subject access request
A request under Article 15 of the GDPR from an individual asking what personal data you hold about them, and for a copy of it.
Defect life cycle
The agreed set of states a bug moves through from the moment it is reported to the moment it is closed.
EN 301 549
The European accessibility standard for ICT products and services, covering web content, software, documents and support.
Equivalence partitioning
Dividing possible inputs into groups the system should treat identically, then testing one value from each.
Exploratory testing
Testing in which design, execution and learning happen at once, with each observation choosing the next step.
Flaky test
A test that both passes and fails against identical code, so its result carries no information.
Load vs stress testing
Load testing measures behaviour under expected demand; stress testing pushes past it to find where and how the system fails.
Mocking vs stubbing
Both replace a real dependency inside a test; a stub supplies prepared answers, while a mock also asserts how it was called.
OWASP Top 10
OWASP’s periodically revised awareness list of the most critical categories of web application security risk.
Page object model
An automation pattern that gathers the selectors and interactions for one screen into a single class, so tests read as behaviour.
Penetration test
An authorised, goal-driven simulated attack run to demonstrate what somebody could actually achieve against a system.
Pseudonymisation
Replacing identifiers so data cannot be attributed to a person without separately held information, which leaves it personal data under GDPR.
Regression testing
Re-checking behaviour that already worked, to show that a change made elsewhere has not broken it.
SAST vs DAST
Static analysis reads the code without running it; dynamic analysis attacks the running application without reading the code.
SBOM (software bill of materials)
A machine-readable inventory of every component in a piece of software, with versions, suppliers and licences.
Security headers
Response headers that instruct the browser to enforce restrictions the application cannot enforce on its own.
Server-side request forgery (SSRF)
A flaw that persuades your server to make an attacker-chosen request from inside your own network.
Severity vs priority
Severity describes how badly a defect breaks the product; priority describes how soon anybody intends to fix it.
Shift left
Moving testing, security and accessibility work earlier in delivery, where defects are cheapest to fix.
Smoke testing
A short, broad check that a build works at all, run before anybody spends time testing it properly.
Software composition analysis (SCA)
Tooling that inventories the third-party components in a build and reports the known vulnerabilities affecting them.
SQL injection
A flaw that lets input alter the structure of a database query rather than only supplying its values.
Test case vs test scenario
A scenario names something worth checking; a case specifies the steps, data and expected result that check it.
Test fixture
The known starting state a test needs, together with the code that creates it and clears it away afterwards.
Test plan
The document that records what will be tested, what will not, by whom, and what would stop a release.
Test pyramid
A guide to suite shape: many fast low-level tests, fewer integration tests, and a small number of end-to-end ones.
Test quarantine
A holding area for tests known to be unreliable: still run and still tracked, but no longer able to fail a build.
Threat modelling
A structured session at design time asking what could go wrong with a system and what you intend to do about it.
User acceptance testing (UAT)
The final check, run by the people who asked for the software, that it does what they needed rather than what was specified.
Visual regression testing
Comparing rendered screenshots against approved baselines to catch appearance changes that functional tests ignore.
WCAG conformance levels
WCAG sorts its success criteria into three levels, A, AA and AAA, and a conformance claim has to name the one it meets.
Contact
Still not sure which one you need?
Describe the problem in your own words. Translating it into whichever discipline actually applies is our job, not yours.