esting has a lot of terminology, and much of it makes testing sound more complicated than it is. Plenty of teams test software well without using most of these words - and some get talked into processes they didn't need because the vocabulary sounded official. So this is an opinionated glossary. Each entry explains what a term means, then tries to put it in its place: some of these ideas are essential, some are useful in the right context, and some mostly make testing sound harder than it is. Underneath the vocabulary, testing is a simple idea: find out as much as you can about your product, so everyone can answer "are we ready yet?". If a term helps you do that, use it. If it doesn't, ignore it, whatever the textbooks say.
Acceptance testing is usually identical in meaning to User Acceptance Testing. It can, however, sometimes refer to the more general process of agreeing (through verification checks) that the requirements of a product have been met, whoever is performing those checks.
Ad-hoc testing is testing without any plan or documentation - someone sits down and pokes at the software, following their nose. There are no test cases, no charters, and no record of what was tried.
Don't let it be the whole strategy forever: with nothing written down, you can't say what was tested. But doing ad-hoc testing is infinitely better than doing zero testing, and it's a fine starting point - the journey of iterating on your test process usually begins here. Write down what you tried as you go and you're already most of the way to a reusable checklist.
"Ad hoc" is Latin: "for this" - something improvised for the purpose at hand.
Ad-hoc testing is often described dismissively, as the unprofessional cousin of exploratory testing, but the two are close relatives. The difference is that exploratory testing works from at least a lightweight plan and leaves a record of what was covered; ad-hoc testing does neither.
Agile testing is testing done the agile way: continuously through development, inside the team, rather than as a separate phase at the end handled by a separate department. Whoever's testing - dedicated testers, developers, or a mix - works alongside the code being written, testing each slice of functionality as it's built.
The word carries an ambiguity worth knowing about (our agile testing guide unpacks it): capital-A Agile is the formal methodology world of ceremonies, sprints and frameworks; lowercase agile is the broader working style - short cycles, feedback, working software over comprehensive documentation. Agile testing splits the same way: there's a formal school with its own quadrants and vocabulary, and there's the everyday sense of testing continuously with lightweight plans that change as the product does.
Since almost everyone now develops in something they call agile, for most teams agile testing is simply testing. The useful core is the Manifesto's trade applied to testing: time spent learning about the product beats time spent maintaining paperwork about the product.
The name traces to the Agile Manifesto (2001), whose "working software over comprehensive documentation" is the trade agile testing applies.
Alpha testing is the final phase of testing a product internally, before releasing it for real users to try in a "beta testing" phase - at least, that's the usual definition where one is attempted. Some teams instead use "alpha testing" to simply mean "very early testing" within the development lifecycle, possibly even conducted during ongoing development.
In truth it isn't a well-defined concept for many teams, nor a critical one to worry about per se. What matters more is that you have comprehensive internal testing comprising unit tests, integration/system tests, and exploratory testing. Ideally, the bulk of this testing should happen on stable release candidates just before releasing (either as a general release or during a beta testing phase).
Rather than getting caught up in terminology, focus on ensuring your product works as intended through whatever testing methods make sense for your team and project. The label "alpha testing" is less important than having effective testing processes in place at the appropriate stages of your development cycle.
The names come from IBM, where "alpha" was the pre-announcement test and "beta" the test that a product was ready for release - terminology in use since at least the 1950s, and adopted industry-wide after IBM itself dropped it.
Alpha testing happens inside: your own team testing a nearly-finished product. Beta testing happens outside: a limited group of real users trying the product before general availability. The Greek letters just mark the order - alpha first, internal; beta second, external.
also test automation
Automated testing is testing where a program executes the tests and checks the results, instead of a person working through them. Code exercises the product, compares what happens against expected outcomes, and reports pass or fail - typically on every change, as part of a build pipeline.
Automation is at its best where checks are exact and repetitive: unit tests, API checks, and regression suites that would bore a human into mistakes. Once written, an automated test runs the same way every time, at a speed and frequency no team of people can match.
What automation can't do is notice what it wasn't told to check. An automated suite verifies the outcomes someone thought to encode; it takes a person to spot the confusing workflow, the broken layout, or the behavior that's technically correct and obviously wrong. Most teams need both: automation for the checks a machine can verify, people for the judgment calls.
In TestpadTestpad is built for the manual side of testing, but includes an API that lets CI systems post their results into Testpad, displaying the results of both human and machine testing side by side.
Beta testing is when you release your product to a limited group of real users before making it generally available. It's essentially a controlled first exposure to actual users in their real environments, allowing you to gather feedback and catch issues that internal testing might have missed.
While many companies make beta testing sound formal with elaborate "beta programs," at its core, it's simply getting your software into the hands of people who aren't part of your development team. These users will inevitably use your product in ways you didn't anticipate and on configurations you hadn't considered.
Beta testing is most valuable for products with large or diverse user bases where internal testing can't realistically cover all usage patterns. For simpler products or those with a small, well-understood user base, an extensive beta phase might be unnecessary. Some teams use "beta" labels primarily as risk management - signaling to users that they should expect some issues.
Alpha testing happens inside: your own team testing a nearly-finished product. Beta testing happens outside: a limited group of real users trying the product before general availability. The Greek letters just mark the order - alpha first, internal; beta second, external.
Black box testing is testing a product without knowledge of its internal code or structure. You interact with the software purely as a user would, focusing on inputs and outputs rather than how the system processes information. You're essentially treating the software as a "black box" where you can't see inside.
This approach is particularly valuable for finding usability issues, verifying that the software meets requirements from the user's perspective, and catching problems that might occur in real-world usage. Most manual testing is naturally black box testing - testers work through features, trying different inputs and checking if the outputs match expectations.
Black box testing is especially effective when performed by people who weren't involved in development, as they don't have preconceptions about how things should work. This often leads to discovering unexpected bugs that developers might miss because they test according to how they built the system rather than how users might actually use it.
While understanding the code can sometimes help testers be more thorough (see White Box Testing), black box testing remains essential because it mirrors how your actual users will experience the product.
From engineering's "black box": a device you can only judge by its inputs and outputs, because you can't see inside.
Black box testing means testing without seeing the internals, as a user would; white box testing means testing with full knowledge of the code; gray box testing sits in between, using partial knowledge of the internals to aim the testing while still approaching the product from outside.
also BVA
Boundary value analysis is testing at the edges of your input groups (see equivalence partitioning): for an 18-and-over age field, try 17, 18, and the extremes - because bugs cluster at boundaries.
If the terminology reminds you to try zero, negative one, the maximum, the maximum plus one, and the empty input, it has done its job.
also bug tracker
Bug tracking tools and issue tracking tools are two names for the same category of tool - see Issue Tracking Tools.
Continuous integration (CI) is the practice of merging code changes into a shared repository frequently - usually many times a day - with an automated build and test suite run on every change. The point is to catch integration problems within minutes of the code being written, instead of discovering weeks of accumulated divergence when everyone finally merges.
CI is a development practice more than a testing one, but it changes the testing picture: the automated checks (mostly unit tests, perhaps some integration tests) act as a constant safety net, so obviously-broken builds rarely reach human testers.
What CI doesn't do is replace testing the product. The suite only checks what someone thought to automate. New features, usability, and the "does this feel right?" questions still need humans - ideally testing release candidates that CI has already confirmed are stable enough to be worth the time.
Grady Booch coined the phrase in 1991; Extreme Programming later turned it into the many-merges-a-day practice the name now implies.
Continuous integration is a development practice: merge frequently, and build and run automated checks on every change. Continuous testing is the broader idea of testing at every stage of the delivery pipeline. In practice CT mostly describes what a good CI setup already does, with more vocabulary.
In TestpadTestpad connects to a CI pipeline through its API - which can create scripts, tests and runs and receive automated results - and through webhooks that fire on run and result events.
Continuous testing (CT) is the idea of testing continuously throughout development, rather than saving it all for a phase at the end. In practice the term usually means running automated tests at every stage of a delivery pipeline - on every commit, every merge, every deployment - so feedback about quality arrives constantly rather than in one late batch.
It's a sensible idea wrapped in an unnecessary label. Testing early and often has been good advice for decades; "continuous testing" mostly restates it in DevOps vocabulary, sometimes in aid of selling tooling.
Take the substance and skip the ceremony: automate the checks that are worth automating, run them often, and keep some human testing in the cycle for each release. Whether you call the result continuous testing doesn't matter.
Continuous integration is a development practice: merge frequently, and build and run automated checks on every change. Continuous testing is the broader idea of testing at every stage of the delivery pipeline. In practice CT mostly describes what a good CI setup already does, with more vocabulary.
A defect - or bug, the word everyone actually says - is a flaw in the software: it does something wrong, or fails to do something it should. The two terms mean the same thing; "defect" is just the formal version you'll find in textbooks and process standards.
Some methodologies draw fine distinctions between errors (the human mistake), defects (the resulting flaw in the code) and failures (the flaw showing itself when the software runs). It's a tidy chain of causation, and knowing it might help you pass an ISTQB exam, but no working team talks this way.
What matters more than the terminology is a good bug report: what you did, what happened, what you expected to happen. A clear reproduction beats any amount of classification.
Engineers were calling faults "bugs" back in Edison's day, but the famous one was literal: a moth found in a relay of Harvard's Mark II computer in 1947, taped into the logbook as the "first actual case of bug being found."
Defect density is the number of defects found per unit of software size - classically bugs per thousand lines of code, sometimes per module or feature. The idea is to compare components or releases: a module with unusually high defect density might need a rewrite, extra review, or extra testing.
As a rough pointer to where the risky code lives, it has some value. As a quality metric, it falls apart quickly: it counts bugs found (which measures the testing as much as the code), every bug counts equally (a typo and a data-loss bug are each "one"), and lines of code is a poor measure of size to begin with.
For most small teams this is metrics theater. You already know which module everyone's scared to touch; you don't need a ratio to tell you. Unless you're in an organization that requires reporting it, you lose nothing by ignoring it.
The defect life cycle is the sequence of states a bug moves through from discovery to closure. A typical version: new, confirmed, assigned to a developer, fixed, verified by a tester, closed - with detours available for "won't fix," "can't reproduce" and "duplicate." Every issue tracker implements some flavor of this as a workflow.
The useful part is the reminder that "fixed" isn't the end. Someone should verify the fix actually works before the bug is closed, and skipping that step is how bugs come back.
Beyond that, don't over-engineer the workflow. Small teams do fine with three states (open, fixed, closed), and elaborate ten-state life cycles with strict transition rules mostly generate admin. Use whatever your issue tracker does by default and spend the saved effort on testing.
Edge-case testing is testing scenarios that are unusual, extreme, or at the boundaries of normal usage. Edge cases are situations that might be rare but could still occur, like entering the maximum possible value in a field, testing with unusually large files, or trying operations with poor network connectivity.
While it's important to verify edge cases work correctly, don't get carried away trying to test every conceivable unusual scenario. Focus on edge cases that are reasonably likely to occur and would have significant impact if they failed. For example, testing how your e-commerce site handles a shopping cart with 1000 items might be less valuable than testing what happens when a payment transaction times out.
Equivalence partitioning is dividing the possible inputs into groups the software should treat the same (valid ages, ages too low, ages too high) and testing one value from each group instead of hundreds.
Of the formal test design vocabulary, this describes something experienced testers do by instinct: don't test fifty middling values that all take the same path through the code. You don't need to document which technique each test used; knowing the name mostly helps with exams and with reading other people's test plans.
Its natural partner is Boundary Value Analysis - once you have the groups, the interesting values sit at their edges.
Exploratory Testing is a type of (manual) testing where the tester is free to explore the product, inventing tests as they go, hunting for issues and inconsistencies, and crucially, reacting to how the product is behaving.
Exploratory testing can be contrasted with fully-scripted testing where every action to perform is defined by the test instruction (usually a detailed Test Case as part of Test Case Management).
Exploratory testing is easily the best kind of manual testing. It takes advantage of the tester's tenacity and intuition, and their experience of what the product did last time vs is doing this time. Exploratory testing allows for hundreds more test ideas to be carried out in the same time as there's no documentation overhead to write (and maintain) a Test Case per test idea.
A common formalization of Exploratory Testing is Session Based Test Management, characterized by directing test sessions with charters (a list of topics to investigate, along with time allocations for each) and testers documenting their test ideas and the results as free-form notes as they proceed.
The term was coined by Cem Kaner in 1984, giving a name (and legitimacy) to the skilled improvised testing good testers were already doing.
Exploratory testing and ad-hoc testing are close relatives: both invent tests as they go rather than follow a script. The difference is that exploratory testing works from at least a lightweight plan and leaves a record of what was covered; ad-hoc testing does neither.
In TestpadExploratory testing in Testpad works from a lightweight outline of prompts - specific enough to direct the session, open enough to explore within - with results marked pass/fail against each prompt as you go, which keeps the testing easy to plan, track and report on without losing its exploratory nature.
Functional testing verifies your software does what it's supposed to do - the basic "does it work?" testing that most people think of when they hear "testing." It focuses on checking features against their requirements or expected behavior.
While it sounds formal, functional testing is just checking if your software's features work correctly. This could be verifying a login form accepts valid credentials and rejects invalid ones, checking that a shopping cart calculates totals properly, or ensuring a document editor can actually save files.
Most testing is functional testing, even if teams don't call it that. If you're verifying features work as intended, you're doing functional testing.
This differs from non-functional testing like performance testing (is it fast enough?), security testing (is it secure?), or usability testing (is it easy to use?).
also grey box testing
Gray box testing is a hybrid approach that sits between black box and white box testing. Testers have partial knowledge of the internal workings of the software, but don't need complete access to or understanding of the source code. They understand the general architecture, data flow, and algorithms without necessarily examining the code line-by-line.
This approach is particularly useful when testers need enough structural knowledge to create more effective tests but don't require (or have access to) the full codebase. For example, understanding the database schema can help testers craft better tests for data integrity, even if they can't see the application code that interacts with the database.
Gray box testing often occurs naturally in smaller teams where testers work closely with developers and gain familiarity with the system architecture over time. It's also common in security testing, where testers need to understand system components to identify potential vulnerabilities, but approach the system from an external perspective.
The benefit of gray box testing is that it combines the user-focused perspective of black box testing with enough technical understanding to target likely problem areas more efficiently. This makes it particularly valuable for complex systems where purely external testing might miss important scenarios.
Black box testing means testing without seeing the internals, as a user would; white box testing means testing with full knowledge of the code; gray box testing sits in between, using partial knowledge of the internals to aim the testing while still approaching the product from outside.
Integration testing is testing how different parts of your software work together, rather than testing them in isolation. While it sounds formal, it's really just checking that when you connect different pieces of your system - whether that's different services, APIs, or third-party tools - everything still works as expected.
Where System Testing looks at the complete product working as a whole, Integration Testing focuses more narrowly on the connections between specific components. However, in practice, the distinction often blurs - if you're testing your product as users would actually use it, you're already testing both how components integrate and how the whole system works.
The distinction becomes more relevant when you're specifically focusing on testing components separately (Unit Testing) or when you have complex systems with many external connections that need special attention. For most teams, especially those with straightforward products, you don't need to treat Integration Testing as a separate process. Just make sure your normal testing includes checking any connections between different parts of your system, particularly after making changes that affect how these parts interact.
also issue tracker
Issue tracking tools (also called bug tracking tools) are tools for recording and managing the software issues found during development and testing. Issues are often bugs (defects), but can also be features, roadmap ideas, enhancements and other items of work relating to the development of the software.
They help teams track issues from discovery through to resolution, storing details like severity, steps to reproduce, screenshots, and discussions about the software changes required.
Traditional issue trackers are standalone tools focused solely on issue (defect) management. Modern development platforms often include integrated issue tracking as part of broader project management features - think Jira, GitHub Issues, or GitLab - allowing teams to manage issues alongside code, features and other work items.
Key features typically include assignment to owners, status tracking, and reports showing trends over time. The best tools let teams quickly capture issues without excessive form-filling while still maintaining enough detail for developers to understand and get to work on the issue.
Test management tracks what's being tested in the current release; issue tracking manages issues throughout their lifecycle, often spanning multiple releases until they're fixed.
Load testing is seeing how your software performs under heavy usage - in particular, whether it copes with the peak loads you expect in production, like many users working simultaneously or large amounts of data being processed.
While specialized tools exist to simulate many users or process large amounts of data, even basic testing with multiple team members can reveal important performance issues. The key is understanding your usage patterns and testing within - and beyond - those boundaries.
Load testing checks the software handles its expected peak usage; stress testing deliberately pushes beyond that, increasing load until performance degrades or something breaks, to find where the limits are. The two names get used interchangeably, and often it's the same tooling - only the intent differs.
Manual testing is testing performed by humans rather than by automated scripts or programs. Testers directly interact with the software by clicking, typing and observing behavior. Manual testing covers a spectrum from fully-scripted test case execution (following precise steps) through to exploratory testing (reacting and adapting to what's found).
The exploratory form of manual testing is particularly valuable as it leverages human intuition and adaptability to discover unexpected issues that would be difficult to find through scripted or automated approaches.
While automation can be more efficient for repetitive checks, manual testing often remains more practical. The effort to automate some tests may outweigh their value, especially for features that change frequently or are difficult to verify programmatically.
Mean time to failure (MTTF) is the average time a system or component runs before it fails. It's a reliability-engineering measure at heart: if you make hardware, MTTF (and its repairable-system cousin MTBF, mean time between failures) is how you predict how long units will survive in the field, plan warranty periods, and decide how long a soak test needs to run.
Hardware teams meet these numbers for real: burn-in and soak testing exist precisely to catch the early failures that drag the average down, and results recorded per unit per revision are the raw material the figures get computed from.
Software teams mostly meet MTTF secondhand in SLAs. Software doesn't wear out the way components do - it fails when it hits a state or input nobody tested - so the average time between failures says little about where the next one will come from. Knowing what the term means is usually enough.
MTTF (mean time to failure) is the average life of something you replace rather than repair; MTBF (mean time between failures) is the equivalent for systems that get repaired and keep going; MTTR (mean time to repair) is how long the repair takes. They fit together: MTBF = MTTF + MTTR.
Mean time to repair (MTTR) is the average time it takes to restore a system after a failure - from things-are-broken to things-work-again. Like MTTF and MTBF it comes from reliability engineering, and it shows up in SLAs and DevOps metrics dashboards (it's one of the DORA metrics, as "time to restore service").
Of the mean-time family, this one has the most practical use, because it measures something you can improve: how fast you notice failures, diagnose them, and ship a fix. A team that can recover in minutes can afford to move faster than a team that takes days.
For a small team, though, formally tracking the number is usually metrics theater. You already know whether recovering from problems feels fast or agonizing. Put the effort into the things that improve it - monitoring, deployment speed, the ability to roll back - not into the measuring.
MTTF (mean time to failure) is the average life of something you replace rather than repair; MTBF (mean time between failures) is the equivalent for systems that get repaired and keep going; MTTR (mean time to repair) is how long the repair takes. They fit together: MTBF = MTTF + MTTR.
A mind map is a way to organize ideas visually, in a branching diagram that expands out from a central concept. In testing, mind maps are particularly valuable for breaking down complex products into testable areas - starting with core features at the center and branching out to the different aspects that need testing.
A mind map starts with your product's core features or capabilities at the center, then branches out to explore related areas, test scenarios, and potential risks. It's a natural way to develop test plans - you can keep expanding branches as you think of new things to test, and the visual structure helps identify gaps in your testing strategy.
While mind maps are great for brainstorming test ideas, you don't need special diagramming tools to create test plans this way. The same structure works as a simple indented list, with main features as top-level items and related tests nested underneath. As you think of new test ideas, you can add them at any level - just like drawing new branches on a mind map. This makes it practical to turn your test ideas into executable plans.
The term (and the colorful radial style) was popularized by Tony Buzan in his 1974 BBC series Use Your Head, though branching diagrams go back centuries.
Performance testing is testing your software's performance characteristics - for example: speed, responsiveness, stability and scalability. It helps identify how your software behaves under different conditions, from normal loads to peak loads and beyond, to better understand its limits.
In web apps, performance testing might look at factors like how quickly pages load, how many users can be supported simultaneously, and whether the software remains stable during extended use. It helps find issues like slow response times, resource constraints and breaking points before they impact real users.
While dedicated performance testing tools exist for simulating heavy loads and gathering detailed metrics, basic performance issues can often be uncovered through manual testing.
Pragmatic exploratory testing is not an industry term - it's Testpad's label for our (fairly obvious) take on how to approach exploratory testing with practicality: make it manageable by adding just enough structure, through detailed (but not too detailed!) test prompts. Rather than "test the login system" as you might find in a high-level charter, prompts break testing down into specific aspects like "check password complexity rules" or "verify account lockout behavior."
Test prompts are therefore more specific ideas of what to investigate but leave the exact approach up to the tester. They avoid the rigid step-by-step instructions of scripted test cases, preserving the tester's freedom to explore while ensuring important functionality isn't overlooked.
Results can be collected as simple pass/fails against each prompt, creating a clear visual overview of what's working and what isn't, while additional comments and bug links capture any specific problems. This structure makes it easier to plan testing scope, track progress, generate clear reports, and reuse test ideas in future releases - all without losing the key benefits of exploratory testing's human-driven discovery process.
Quality assurance is the whole topic: making sure that what gets built is built well. It spans the processes, standards, and habits of everyone involved - from the requirements and their translation into a product concept, through design, implementation, and testing, to the iteration on all of it.
In everyday use the term has drifted: most teams say "QA" to mean the testers and the testing itself (strictly, that activity is quality control). The broader meaning survives in job titles: a "QA engineer" on some teams is expected to improve how things get built, not just test what got built.
Quality control checks what has been built; quality assurance shapes how it gets built. Testing is quality control.
Quality control is checking what has actually been built: examining the product itself to find defects before release. Testing, whether manual or automated, is quality control.
The distinction from quality assurance matters mostly in formal and regulated settings, where the two are audited separately. Day to day, the useful takeaway is just that "checking the product" and "improving the process" are different jobs, even when the same people do both.
Regression testing is testing to make sure that things which used to work still work - in particular, that problems you've fixed previously stay fixed. Think of it like a growing checklist: every time you find and fix a significant bug, you add a test to catch it if it reoccurs. No product is bug-free, but having the same bugs reappear is embarrassing and suggests a team that doesn't learn from its mistakes.
While often associated with automation, regression testing doesn't have to be automated to be valuable. Some tests are difficult or impractical to automate, and manual regression testing is better than none at all. The key is having these checks in place, whether they're automated or done by hand.
The name is literal: the software has regressed - gone backward - to a state where something that used to work no longer does.
Not necessarily to be confused with automated testing: regression testing often is, and ideally should be, automated - but it doesn't have to be. Running regression manually first, then promoting the tests that prove automatable into the CI framework, is a good practice.
In TestpadIn Testpad, the regression suite is last release's script: copy it to start testing the new release, and let the checklist grow as bugs teach you new tests to keep.
Root cause analysis (RCA) is digging past a bug's symptom to find the underlying cause - and, done properly, asking why the process let that cause through. The classic technique is the "five whys": keep asking why until you hit something fundamental. The report timed out; why? The query was slow; why? The table had no index; why? Nobody reviews query performance before shipping; and so on.
For most bugs, full RCA is overkill: find it, fix it, add a regression test, move on. Save the deeper analysis for the bugs that matter - the outage, the data corruption, the same class of bug appearing for the third time. Those are the ones where fixing only the symptom guarantees a repeat.
When you do it, keep it blameless. The interesting answer is rarely that someone made a mistake; it's whatever made the mistake easy to make and hard to catch.
The "five whys" came off Toyota's factory floor - part of its production system decades before software borrowed the technique.
Sanity testing is a quick check that the most basic, core functionality of your software works, done before investing time in deeper testing. If users can't log in, or the main page won't load, there's no point proceeding with more detailed testing of advanced features or edge cases.
While "sanity testing" sounds formal, it's really just common sense - check the obvious things first. Some teams treat it as a distinct phase with its own test plan, but that's usually overkill. Simply having experienced team members quickly verify basic functionality before starting full testing is often enough. The goal is to save time by catching major issues early, not to create extra processes.
Smoke testing and sanity testing mean close enough to the same thing: a quick pass over the basics before deeper testing. Where teams do distinguish them, a smoke test checks a new build starts and runs at all, while a sanity check confirms a specific change or fix behaves before wider testing resumes. Few teams are that precise, and nothing is lost by treating them as synonyms.
Security testing is testing to find vulnerabilities in your software that could be exploited by malicious users. It ranges from basic checks like ensuring passwords are properly encrypted and users can only access their own data, to sophisticated penetration testing that actively tries to break into the system.
While specialized security firms offer comprehensive testing services using advanced tools and techniques, development teams should still perform fundamental security checks throughout development. Essential areas include input validation, authentication, access control, and data protection - especially for sensitive information.
The goal is identifying and fixing security holes before attackers find them. This applies not just to obvious entry points like login screens, but to the entire system including APIs, databases, and infrastructure.
Session-based test management (SBTM) is a structured approach to exploratory testing in which testing is organized into time-boxed sessions, each guided by a charter. The charter defines what aspects of the product should be explored in the session and how long to spend on each aspect.
During testing, testers maintain a detailed journal of their activities, observations, and any issues discovered. These session notes form the primary output and documentation of the testing performed.
SBTM helps make exploratory testing more manageable by providing a framework for planning sessions and tracking progress. However, the reporting quality depends heavily on testers' note-taking skills, and the session notes don't easily provide quick summaries of testing status or product readiness.
Devised by Jonathan and James Bach in 2000 as a way to make exploratory testing plannable and accountable without scripting it.
Severity is how bad a bug is; priority is how soon it should be fixed. They often align but don't have to. A crash in a feature nobody uses is high severity, low priority; a typo in your pricing headline is low severity, high priority.
The distinction is worth keeping in your head because it dissolves a common argument: testers rate impact (severity), whoever owns the product decides order (priority). A tester saying "this is severe" and a product owner saying "not this release" can both be right.
Don't build a bureaucracy around it. Five-point scales for each, matrices mapping one onto the other, mandatory fields on every bug - most teams need nothing more than a plain note of how bad it is and someone deciding what gets fixed first.
Smoke testing is a quick check that basic functions work before proceeding with more thorough testing. It's about making sure there aren't any major showstoppers in a build - it won't start, nobody can log in - before investing time in detailed testing of everything else.
In software development, smoke testing is essentially the same as Sanity Testing: verifying nothing obviously broken has made it into the build. Rather than being a formal process, it's about efficiently catching major problems early - if the software is clearly unstable, you can fix those issues before spending time on more nuanced testing.
The term can sometimes be used to mean "soak testing" - running systems for prolonged periods to find stability issues that only emerge over time - but the "sanity testing" interpretation is the more common one.
From hardware testing: power the board on, and if it starts smoking there's no point testing anything else yet.
Smoke testing and sanity testing mean close enough to the same thing: a quick pass over the basics before deeper testing. Where teams do distinguish them, a smoke test checks a new build starts and runs at all, while a sanity check confirms a specific change or fix behaves before wider testing resumes. Few teams are that precise, and nothing is lost by treating them as synonyms.
Stress testing is seeing how your software performs under loads beyond what you expect - deliberately increasing usage until performance degrades or something breaks, to find the system's limits.
While specialized tools exist to simulate many users or process large amounts of data, even basic testing with multiple team members can reveal important performance issues. The key is understanding your usage patterns and testing within - and beyond - those boundaries.
Load testing checks the software handles its expected peak usage; stress testing deliberately pushes beyond that, increasing load until performance degrades or something breaks, to find where the limits are. The two names get used interchangeably, and often it's the same tooling - only the intent differs.
System testing is testing your complete software product as a whole, rather than testing individual components in isolation. It looks at how all the pieces work together - from user interfaces through to databases and external integrations. It's about verifying the entire system works correctly in a realistic environment.
Most testing is system testing, even if teams don't call it that. Unless you're specifically testing isolated components (unit testing) or how your system connects with others (integration testing), you're probably doing system testing. Don't get hung up on the term - it's just testing your actual product the way it will be used, which is exactly what most teams need to focus on.
A test bed is the configured setup automated tests run on - hardware, software versions, data. In practice it means much the same as Test Environment, and in automated contexts it overlaps with the Test Harness.
You'll hear all three used loosely; the distinction rarely matters.
Borrowed from engineering, where a test bed is the physical rig a prototype gets mounted on for trials.
A test case is a single test instruction: one instruction out of the many that need to be performed as part of the testing process. It could be just a prompt or idea for something to look at, or it could be more elaborate, with formal structure and step-by-step detail.
When formally structured, test cases typically include:
Whether to use shorter or longer test cases depends on the context the test team is working in. In a process-heavy environment, where teams are using traditional Test Case Management tools, they will probably be required to structure each test case with many of the above elements. In a more agile environment, especially when the testing is more exploratory in nature, test cases can be just brief prompts of aspects of the product to remember to take a look at.
If you're new to testing, and/or don't have to use a Test Case Management tool, then we'd strongly steer you toward keeping your test cases (prompts) as short and simple as possible. They're much faster to write and much easier to maintain.
A test case is one test; a test script (or suite) is a collection of them; a test plan is either the strategy document for the whole testing effort or, used loosely, just the list of tests itself. Our post comparing test cases and checklists looks at how much detail each test actually needs.
Test coverage is a measure of how much of something your tests exercise. For automated tests it usually means code coverage: the percentage of lines or branches executed when the suite runs. For manual testing it's fuzzier - coverage of features, requirements, or risks.
The number is seductive and mostly misleading. "85% coverage" sounds like a fact about quality, but it only says those lines were executed, not that anything meaningful was checked - a test can run code and assert nothing. And coverage of what? Lines of code, features, requirements, browsers, user types? Each gives a different number, and none of them is "how tested is this product."
Coverage is useful as a gap-finder: a module at 0%, a feature nobody has looked at. Treat it as a way of spotting what you've missed rather than a score to maximize. Chasing a coverage target produces tests that satisfy the metric, which is not the same as tests that find bugs.
Test data is the data used during testing to verify how software behaves with different inputs. This could be sample customer records, transaction histories, or any other information needed to exercise the software's functionality.
Creating good test data is often overlooked but important - you need enough variety to test different scenarios while keeping it manageable. Rather than creating massive datasets, focus on having representative examples that cover key use cases and edge conditions. For example, an e-commerce site might need just a few orders with different payment methods and shipping options rather than thousands of transactions.
Most teams benefit from maintaining a core set of reusable test data, supplemented as needed for specific test scenarios, and iterated on over time as experience grows from release to release.
A test environment is the setup your tests run against: hardware, operating systems, browsers, databases, configuration, test data, and any connected services. "Works on my machine" is the classic symptom of a test environment not matching the real one.
The pragmatic goal is an environment that's realistic where it matters and convenient everywhere else. A staging setup resembling production (same versions, sensible data) covers most needs. Perfect production parity is expensive and rarely necessary; what you want to avoid is testing against a setup so unlike production that the results don't transfer.
Two things are worth doing. Record the environment alongside the results, because "passed" means little without knowing where it passed. And keep the environment somewhere near reality as the product evolves - environment drift is a slow leak, where each release the staging setup gets a little less like production until bugs start slipping through.
A test harness is the framework that runs automated tests and collects their results - the scaffolding around the tests rather than the tests themselves.
If you're not writing the automation yourself, the useful summary: automated tests run inside a harness against partly simulated surroundings, which makes them fast and repeatable - and is also why a passing automated suite doesn't prove the fully assembled product works. Testing the real thing, connected to real things, is still a job.
Test management tools help teams organize and track their testing process. They typically store test plans, record results, and generate reports to show testing progress and product quality. The category spans everything from heavyweight test case management platforms to lightweight checklist tools.
Traditional test management tools are built around formal "test cases" - requiring detailed documentation of steps, expected outcomes, and other metadata for each test. While this structured approach suits some contexts (especially highly regulated industries), it can be unnecessarily rigid and time-consuming for many teams.
Modern alternatives take a more flexible approach, letting teams create simple checklists of what needs testing, add detail where valuable, and generate clear reports showing what works and what doesn't. This lighter approach particularly suits exploratory testing, where testers benefit from the freedom to investigate and react to what they discover rather than following rigid scripts.
The best tool choice depends on your needs. Spreadsheets work well for simple testing. Traditional test case management tools suit process-heavy environments. Lighter tools like Testpad offer middle ground - more capable than spreadsheets but without the complexity of traditional platforms.
In TestpadTestpad's model: a test is one line of plain text, a script is a checklist of prompts with indentation for structure, a run is a column of results next to the tests, and reports are shared by link.
A test plan is either the high-level document setting out the approach a team will use for a whole testing project, or simply the list of test instructions a team will work through. Both usages are common, which makes it an ambiguous term - check which one your team means.
As the high-level document, think of it as the strategy document, setting out the bigger picture and answering the "what," "why," and "how" of the testing effort, aligning stakeholders and setting expectations.
As just a list of test instructions, it's essentially the same as a Test Script.
A test case is one test; a test script (or suite) is a collection of them; a test plan is either the strategy document or, used loosely, just the list of tests itself. When someone says "write the test plan," find out whether they mean strategy or checklist before you start typing.
In TestpadIn Testpad, a test plan is a script: a checklist of one-line prompts, indented to give it structure.
A test prompt is a short test instruction describing what to test without spelling out how - "password reset with an expired link" rather than ten numbered steps. It is a test case stripped back to the idea itself.
The concept travels beyond any one tool. Whether you call them prompts, checks, or one-line test cases, terse instructions that trust the tester to fill in the details are faster to write, easier to maintain, and leave room for the tester's exploratory instincts.
Getting the level of detail right takes a little practice. "Test login" is too vague to direct anyone; full numbered steps are too rigid. A good prompt names one specific aspect and implies its expected outcome - specific enough that a competent tester knows what to look at, open enough that they choose how.
In Testpad"Prompt" is Testpad's word for the lines in a script: each line is a prompt, and prompts nest in an outline so related ideas sit together.
also test summary report
A test report summarizes a round of testing: what was tested, what was found, and whether the product looks ready to release. The formal version is often called a test summary report (there's an IEEE template) and includes scope, environments, results by area, outstanding defects, deviations from the plan, and a recommendation.
A good test report efficiently conveys what was tested, what's working, and what's broken, and thereby gives stakeholders what they need to make good decisions about what happens next - which is usually releasing, or making further fixes first.
Test reports don't need to be complicated. Charts and counts can bury the useful part: exactly what passed and what failed, presented in a format that is easy to digest. (More in our post on simple test reports.)
In TestpadIn Testpad, a report is a link you can share rather than a document you compile. Reports show all the tests with all the results in one big, easy-to-scan grid. This makes it easy to see both what is, and what isn't, working.
A test run is a single run-through of a test plan or script, collecting results, bugs, notes and perhaps other evidence (e.g. screenshots) along the way. Think of it as one column next to your list of tests, recording what happened when someone worked through them - what passed, what failed, and any observations made.
During the testing of a product, as part of one release cycle, you might make multiple test runs through your tests, covering different:
Some teams (or indeed tools) build lots of processes around a test run, with effort spent preparing them and getting sign-off when completed etc. Depending on your process requirements and context, this can easily be overkill. What matters is having a clear record of what was tested, when, by whom and with what result.
In TestpadIn Testpad this is literal: a test run is a column of pass/fail results next to the tests, and adding another run adds another column.
A test script is a collection of test instructions: either a sequence of steps and prompts for a human tester to follow as part of manual testing, or the code used to define automated tests. In both senses it's the unit of testing you work through and record results against.
Test Scripts can sometimes be confused with Test Suites, but the distinction doesn't really matter. A Test Suite is usually only used for a collection of Test Cases as part of Test Case Management. Whereas a Test Script is more likely to mean either a piece of the code in an automated test environment or a list of test instructions for a human to follow.
A test case is one test; a test script (or suite) is a collection of them; a test plan is either the strategy document for the whole testing effort or, used loosely, just the list of tests itself. The terms blur in practice, and little hangs on the distinction.
In TestpadIn Testpad, a script is the list of instructions for a human to follow - formatted as a checklist with outline structure, where each line is one test and indenting nests related lines together.
A test suite is a collection of related test cases or test scripts, typically grouped by feature, component, or testing objective. While some tools and processes make formal distinctions between suites, scripts, and plans, these terms often mean similar things in practice - they're just ways to organize collections of tests.
Unit testing is automated testing at the code level, where individual components (functions, classes, modules) are tested in isolation to verify they work as intended. Unit tests are often written by developers alongside their code and can be run automatically whenever code changes, typically as part of continuous integration.
While valuable for catching issues early in development, unit testing only verifies individual pieces work correctly, not how they work together or how the complete product behaves. Additionally, since unit tests are usually written by the same developers writing the code, they may embed the same incorrect assumptions about how components should behave.
Unit tests complement rather than replace system-level testing of the whole product.
Usability testing is testing how easy and intuitive your software is to use, typically by observing users attempting specific tasks. It can be performed at any stage - early in development using prototypes (even paper mockups) to validate design choices before implementation, or later with beta/released versions to identify improvements needed.
The scope can vary from informal observations by coworkers to formal studies with recruited participants representing your target users, complete with video recording and eye tracking. Many companies now outsource this to specialist usability testing services that handle participant recruitment and provide detailed analysis of user behavior.
The key is watching users interact with your software without helping them, noting where they get confused or stuck. These insights help improve the user experience before and after release.
User acceptance testing (UAT) is testing to verify software meets its intended purpose, typically near the end of development. In a client project, this means the client checking the delivered product matches what they ordered. For end-user products, it means verifying the software works effectively for its target users - either through testing with actual users or by having the test team work through realistic user scenarios.
Neither approach needs complex processes or special tools - what matters is getting meaningful feedback about whether the software truly works for its intended audience before release. This could be as simple as observing users interact with the software or having clients verify their requirements have been met.
Acceptance testing and user acceptance testing usually mean the same thing. Strictly, acceptance testing is the general activity of verifying that requirements have been met, whoever performs the checks; UAT is the version where the users, or the client, do the checking themselves.
In TestpadIn Testpad, client UAT typically runs on guest testers: the client joins a test run from an emailed link - no login, no paid seat - and works through the checklist, with their results recorded in the run like anyone else's. (Team plans and up.)
White box testing is testing with full knowledge of the code and internal structure of the software. Instead of just looking at inputs and outputs, testers examine how the software processes information, often with access to the source code, data structures, and algorithms used.
This approach is valuable for ensuring all code paths are tested, finding issues with specific functions or modules, and verifying that internal operations work as intended. Unit testing is a common form of white box testing, where developers test individual components in isolation.
White box testing is typically performed by developers or technical testers who understand the codebase. It's particularly effective at finding issues like memory leaks, security vulnerabilities, and edge cases that might be difficult to trigger through regular usage.
Both white box and black box testing have their place in a comprehensive testing strategy. White box testing helps ensure technical correctness, while black box testing confirms the software actually meets user needs.
Black box testing means testing without seeing the internals, as a user would; white box testing means testing with full knowledge of the code; gray box testing sits in between, using partial knowledge of the internals to aim the testing while still approaching the product from outside.