There are two sets of terms a beginner encounters right away and often mixes up. The first is about how much you know about the internals of a program when you check it (the boxes). The second is about why you are running a particular test pass (smoke, regression, sanity). Let's go through both — they are straightforward.
Black box: checking from the outside
Black box — you do not know and do not look at how the program is built inside. You work with it like a regular user: there is an input (what you typed, what you clicked) and an output (what you got). The internals are a "black box" — not visible.
Example: you are checking a login form. You enter a username and password and see whether you are let in. How exactly the code checks the password does not matter to you. What matters is the behavior from the outside.
This is the main approach of a manual tester. Most of your checks are black box: you look at the product through the eyes of a user, not at the code.
White box: checking from the inside
White box — the opposite: you can see the code and you check its internal logic — did all the "if–then" branches execute, are there any forgotten cases? You need to be able to read code to do this.
This is mainly the work of developers (unit tests are a classic example of white box testing). A manual tester usually does not need to dig into the code, but it is useful to know that this perspective exists and that some bugs are caught there, even before they reach you.
Grey box: knowing a little about the internals
Grey box — the middle ground. You check from the outside, like a user, but you also know something about the internals and use that knowledge.
Example: you are checking order placement as a user (black box), but at the same time you look in the database — was the order actually saved there with the correct status? Or you look in the browser's Network panel to see what request was sent to the server. You are not reading code, but you are using your knowledge of what happens where.
In practice, an experienced manual tester almost always works in grey box mode: checking behavior from the outside while using internal tools to confirm what actually happened.
Smoke, regression, sanity — the purpose of a test run
These three words describe not what is being checked, but why a set of checks is being run.
- Smoke testing. A quick check that the product is alive and hasn't crashed: does it open, do the main features work? Like "switch the device on and see if smoke comes out". Run it first on a new build: if smoke testing fails, there is no point testing further — get it fixed first.
- Regression testing. Checking that after new changes the old things still work. The most common trap in development: fix one thing — break something else. Regression catches that. Regression testing is what is most often automated, because it is run again and again.
- Sanity testing. A narrow, fast check of a specific fix or a small feature: does the exact thing that was just corrected actually work, without running the full suite?
And one more term in the same area:
- Re-testing (re-test). Checking a specific bug after it has been marked as fixed: is it gone? Do not confuse this with regression: re-test is "was this bug fixed?", regression is "did fixing it break anything else?"
Where this applies
These terms are the language your team will use with you. "Run smoke on the new build", "we need a regression pass before the release", "do a re-test on this bug" — you need to understand what is being asked of you without having to ask back. And understanding the boxes determines what tools you use: just the interface, or also the database and network panel.
Where beginners stumble:
- Confusing re-test and regression. They check that the bug is gone and think they are done — while something nearby has already broken.
- Skipping smoke and starting detailed testing on a build that does not even start correctly.
- Limiting themselves to black box, even though a quick look in the database or network panel would immediately show the cause of strange behavior.
What to learn next. The theory is done — let's move to practice. Next up: how to write a test case — how to turn "we need to check registration" into specific step-by-step checks.