Build fluency in the vocabulary of feeding a program random and mutated inputs to trigger unanticipated bugs.
0 / 5 completed
1 / 5
At standup, a dev mentions automatically feeding a program huge volumes of randomly generated or mutated inputs to try to trigger crashes, hangs, or memory-safety bugs that hand-written test cases never happened to cover. What is this technique called?
Fuzz testing is exactly this: fuzz testing automatically feeds a program huge volumes of randomly generated or mutated inputs, often guided by code coverage feedback, to try to trigger crashes, hangs, or memory-safety bugs that hand-written test cases never happened to cover. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This generate-and-mutate-inputs approach is exactly why fuzz testing regularly finds edge-case bugs, especially in code that parses untrusted input, that manual test-writing missed entirely.
2 / 5
During a design review, the team adds fuzz testing to a parser that handles untrusted input, specifically because generating huge volumes of random and mutated inputs can surface edge cases that a fixed, hand-written set of test cases never anticipated. Which capability does this provide?
Fuzz testing here provides Discovery of unanticipated edge-case bugs at scale, since randomly generated and mutated inputs explore combinations a hand-written test suite never thought to include, especially in code that parses untrusted input like file formats or network protocols. A fixed, hand-written set of test cases can only cover the edge cases someone actually thought of in advance. This large-scale, unanticipated-input exploration is exactly why fuzz testing is standard practice for parsers and other code that handles untrusted input.
3 / 5
In a code review, a dev notices a parser handling untrusted input is tested only with a fixed, hand-written set of test cases covering the edge cases the author happened to think of, with no fuzz testing generating additional random or mutated inputs. What does this represent?
This is a missed fuzz-testing opportunity, since generating huge volumes of random and mutated inputs would surface edge cases the hand-written test suite never anticipated, especially in code parsing untrusted input. A cache eviction policy is an unrelated concept about discarded cache entries. This fixed-test-suite-only pattern is exactly the kind of coverage gap a reviewer flags once the code in question parses input from an untrusted source.
4 / 5
An incident report shows a parser crashed in production on a malformed input that no hand-written test case had ever covered, because the team relied only on a fixed, hand-written test suite with no fuzz testing. What practice would prevent this?
Adding fuzz testing surfaces edge cases a hand-written suite never anticipated by exercising huge volumes of random and mutated inputs. Continuing to rely only on a fixed, hand-written test suite regardless of how much untrusted or malformed input the parser actually receives is exactly what caused the issue described in this incident. This fuzz-testing practice is the standard fix once a parser is confirmed to handle untrusted or malformed input in production.
5 / 5
During a PR review, a teammate asks why the team adds fuzz testing on top of an already thorough hand-written unit test suite. What is the reasoning?
A hand-written unit test suite only covers edge cases a person thought to write, while fuzz testing generates huge volumes of random and mutated inputs that can surface crashes and memory-safety bugs no one anticipated, making the two complementary rather than redundant. This is exactly why thorough test strategies combine both, rather than treating either one as a full substitute for the other.
What does the "Fuzz Testing Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to fuzz testing vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.