When I was new to testing, I met a pile of words ending in test: Unit Test, Smoke Test, Static Test, Regression Test, Performance Test. At a glance they looked as if they belonged to one classification table, and learning the table would be the end of it.
There is no magic table.
System Test is about test level. Functional Test is about the characteristic being checked. Static Test is about whether the object runs. Regression Test is about the purpose after a change. One test can wear several labels at once.
For example, a tester reruns a money-transfer flow after a developer changes the fee calculation. That can be system testing, dynamic testing, functional testing and regression testing at the same time. None of those labels punches the others.
Test level is not test type
The four common levels are covered in Testing Levels:
| Level | Common test object | Main goal |
|---|---|---|
| Component testing | Function, class, module or component | Check each part separately |
| Component integration testing | Interface between components | Check how code parts communicate |
| System testing | A reasonably complete system | Check end-to-end behaviour and system characteristics |
| Acceptance testing | Product in its use or operating context | Assess whether the system is ready to be accepted |
Teams still say “this test type is UAT” and people understand. But when an explanation needs to be precise, name the axis you are classifying on.
Static testing and dynamic testing
Static testing
Static testing checks a work product without running the object itself. Requirement reviews, test-case walkthroughs, code reviews and static analysis belong here.
Suppose the requirement says:
A password must be 8 to 16 characters long, and at least 20 characters for an administrator account.
Without a build, we can already see the two rules collide if administrator accounts are still limited to 16 characters. Catch it here and we fix a document. Catch it during system testing and the BA, developer, tester and perhaps the database all get to do the work again.
Static testing finds defects in requirements, design, code and testware. Bug and defect are commonly used as synonyms; there is no rule that bugs live only in code while defects live only in documents. That was covered in Error, Defect and Failure.
Dynamic testing
Dynamic testing runs the test object and observes its behaviour. Calling a function in a unit test, sending a request to an API or tapping an app on a phone are all dynamic testing.
If actual differs from expected, what we observe is a failure. The team then investigates whether the defect is in code, configuration, data or somewhere else.
Functional testing and non-functional testing
Functional testing
Functional testing asks what the system does. It checks business rules, flows, calculations and requested behaviour.
For login:
- Correct username and password allow access to the account.
- Five wrong passwords lock the account according to the rule.
- A locked account cannot create a new session.
Smoke testing usually selects important functions to see whether a build is stable enough for deeper testing. Every company uses sanity test differently; don’t argue from the word alone, ask what the suite actually covers.
Non-functional testing
Non-functional testing asks how well the system works or which quality characteristics it has. Common groups include:
| Group | Example question |
|---|---|
| Performance | How many requests can the API handle, and how quickly? |
| Security | Can someone without permission read this data? |
| Usability | Can users understand and complete the flow? |
| Accessibility | Can keyboard users or screen readers operate it? |
| Compatibility | Does it work on supported browsers, OSs and devices? |
| Reliability | Does it stay stable under the stated conditions? |
UI testing does not fit neatly on one side. Clicking a form-submit button and checking the request is functional; checking focus, contrast and how a screen reader reads the form leans non-functional.
Black-box and white-box
Black-box testing designs tests from inputs, outputs and described behaviour, not internal structure. Equivalence partitioning, boundary value analysis, decision tables and state transition are black-box techniques.
White-box testing uses internal structure such as statements, branches or code paths. Knowing that source code exists does not automatically make a test white-box; the test must actually use that structure to select coverage items.
Between the two is gray-box, a practical term used when a tester knows part of the architecture, database or implementation and uses it during testing. It is not a main CTFL technique group.
Confirmation testing and regression testing
The developer says the bug is fixed. We have two different questions:
- Is the old bug gone?
- Did the change break something else?
Confirmation testing answers the first. Run the conditions that caused the bug and check whether the fix works. People often call this retest.
Regression testing answers the second. Select areas that may be affected and run related tests again. Sometimes the whole suite is needed, but there is no rule that every bug fix pulls the entire test repository out for a start-to-finish run.
Suppose the developer changes the login query:
- Confirmation: use the account that reproduced the bug and see whether login works.
- Regression: also test a normal account, locked account, wrong password, old session and flows sharing the query or authentication service.
Regression scope is an impact-and-risk problem. “Run everything to be safe” sounds safe until the suite takes three days and the release is tonight.
Exploratory, ad-hoc and monkey testing
Exploratory testing is when learning the product, designing tests and executing them happen together. It can still have a charter, timebox, notes and a debrief. No pre-written test case does not mean no thinking.
Ad-hoc testing is less formal and relies more on the tester’s intuition and knowledge at that moment. Monkey testing leans towards random or semi-random actions, sometimes generated by a tool. These three terms are often thrown into one “click randomly” bucket, which removes all their meaning.
Suppose I want to explore-test a file-upload screen for 45 minutes. The charter might be:
Find ways to make upload fail or create a confusing state using file type, file size and loss of network.
From there I try things, learn constraints and record the next route to take. It is freer than scripted testing, but it is not banging the keyboard and hoping a bug appears.
Wrap-up
When someone asks, “What type of test is this?”, ask back:
Are you classifying it by level, quality characteristic, design approach or purpose for rerunning it?
Once the axis is clear, the terminology becomes much less messy. The next article moves from test conditions to high-level test cases and RTM — turning requirements into something whose coverage can be managed.
