Study Guide: Software Testing in 40 Flashcards — Unit, Integration and 30 More Test Types

Deck MN2918 "Testing: Unit & Integration" has 40 cards, but only two of them are about unit and integration testing. The rest is a compact map of the whole software-testing vocabulary: 30+ testing types, the test pyramid, coverage metrics and a few classic principles. That's good news if you're preparing for a QA interview, an ISTQB-style exam or a CS course — as long as you study it as a taxonomy, not as a unit-testing tutorial.

Sample cards from the deck

Everything the deck covers

Static vs dynamic testing, white-box, black-box and grey-box testing, regression, smoke and sanity testing, acceptance, alpha and beta testing, exploratory testing, TDD, functional vs non-functional testing, performance, load and stress testing, continuous testing, mutation testing, fault injection, fuzzing, API testing, component interface testing, compatibility, usability, security and installation testing, destructive testing, A/B testing, concurrency testing (deadlocks, race conditions), code coverage, test oracles, and the fundamental limit of testing: you can never test every combination of inputs.

Study it by axes, not alphabetically

Forty "X testing" cards blur together fast. Sort them into four questions before your first review:

1. How much do you see of the code? white-box / grey-box / black-box.
2. What level? unit → integration → system → acceptance (alpha, then beta).
3. What quality? functional vs non-functional (performance → load → stress, security, usability, compatibility).
4. When does it run? smoke and sanity (before deeper testing), regression (after changes), continuous (in the pipeline).

Then drill the look-alike pairs as pairs: smoke vs sanity (smoke = "does it even start?", sanity = "is this build worth testing further?"), load vs stress, verification vs validation, alpha vs beta.

Two cards to rewrite

• Mutation testing (card 26) and fault injection (card 35) share the same back. They're different: mutation testing makes small edits to the code (flip > to >=) and checks whether your test suite fails — a surviving mutant reveals a weak test. Fault injection breaks the running system (failed disk, dropped network call) to test robustness. Fuzzing is closer to neither: it throws random or malformed inputs at the program.
• TDD (card 17) misses the key point: in test-driven development you write the failing test before the code, then make it pass, then refactor (red → green → refactor).

Continuous testing only makes sense inside a pipeline — pair this deck with our CI/CD study guide, and for testable code design see Design Patterns and SOLID.

Find deck MN2918 in the library on Flip It.