Learn the vocabulary of isolating an intermittently failing test without losing its coverage entirely.
0 / 5 completed
1 / 5
At standup, a dev mentions a test that intermittently passes or fails with no change to the underlying code, undermining trust in what a red CI run actually means. What is this kind of test called?
A flaky test intermittently passes or fails with no change to the underlying code, undermining the team's trust in what a red CI run actually signals. A regression test, by contrast, is specifically meant to fail only after a real behavioral change has been introduced, which is exactly the reliable signal a flaky test fails to provide. This intermittent, code-independent failure is what distinguishes a flaky test from a genuinely broken one.
2 / 5
During a design review, the team wants a known flaky test moved into its own tracked suite that doesn't block a pull request's main CI signal, rather than either deleting it outright or leaving it in the main suite. Which capability supports this?
Quarantining the flaky test moves it into its own separately tracked suite that doesn't block a pull request's main CI signal, while still keeping it visible and scheduled for investigation rather than simply deleted. Leaving the flaky test in the main suite keeps blocking every pull request's signal indefinitely, which is exactly the trust problem quarantining is meant to solve. This separate tracking is what lets a team keep CI trustworthy without losing the flaky test's coverage outright.
3 / 5
In a code review, a dev notices a quarantine dashboard listing each flaky test alongside an assigned owner and a deadline to either fix or remove it, rather than a list a team simply forgets about. What does this represent?
Owned, time-bound tracking of a quarantined flaky test assigns a specific owner and a deadline to either fix or remove it, ensuring the quarantine suite doesn't quietly become a permanent graveyard of ignored tests. Quarantining with no owner or deadline assigned leaves that test unaddressed indefinitely, which defeats the purpose of quarantining it in the first place. This accountability is what keeps quarantine a temporary holding area rather than a place tests go to be forgotten.
4 / 5
An incident report shows a genuine regression shipped to production because the team had grown accustomed to ignoring CI failures and simply rerunning until green, since a known flaky test had never been separated from the main suite. What practice would prevent this?
Quarantining a known flaky test into its own tracked suite restores the main CI run's reliability, so a red result there once again means a genuine failure worth investigating. Continuing to leave a known flaky test in the main suite is exactly what trained the team to ignore CI failures in this incident, letting a real regression slip through unnoticed. This separation is essential for keeping a team's trust in its CI signal intact over time.
5 / 5
During a PR review, a teammate asks why the team quarantines a flaky test into a separately tracked suite instead of just deleting it outright once it starts causing trouble. What is the reasoning?
Deleting the test outright loses whatever real coverage it did provide, even if its flakiness currently makes that coverage unreliable to depend on for CI gating. Quarantining preserves that coverage in a non-blocking suite while assigning an owner and a deadline to actually fix the underlying flakiness, rather than losing the test's intent entirely. The tradeoff is the ongoing discipline required to keep the quarantine suite from silently accumulating tests nobody ever circles back to fix.
What does the "Flaky Test Quarantine Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to flaky test quarantine 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 — this module shares real-world context with 9 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
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.