Test types: functional vs non-functional
A test type answers: "which quality characteristic am I checking?"
- Functional testing — WHAT does the system do? Business rules, calculations and flows against the requirements.
- Non-functional testing — HOW does it do it? Speed, security, comfort, compatibility, language support.
An insurance portal example: "the motor policy premium is calculated correctly" — functional. "the premium is calculated in under 3 seconds" — non-functional (performance). Both concern the same feature but ask different questions.
| Functional type | What it checks | When it runs |
|---|---|---|
| Smoke | Is the build usable and testable at all (broad, shallow) | On every new build, before deeper testing |
| Sanity | Does a specific change/fix behave sensibly (narrow, deeper) | After a small change or a bug fix |
| Re-test (confirmation) | That a specific bug is really fixed — with the same steps | When a bug moves to "Fixed" |
| Regression | That the change didn't break OTHER working areas | Before releases and after significant changes |
| Integration | Data exchange between modules and external systems | As modules become ready (e.g. policy service ↔ payment gateway) |
| UAT (acceptance) | That the product meets the real business need | Before release, by the business/customer |
| Non-functional type | The question it answers | A manual QA's practical check |
|---|---|---|
| Performance | How fast, and under how many users? | Measuring page/request response time, behaviour on slow networks |
| Security | How well are data and access protected? | Opening a URL with someone else's policy ID, a token-less request, an XSS input |
| Usability | Can the user reach their goal easily? | Clarity of error messages, number of steps, ability to go back |
| Compatibility | Does it work the same across browsers/devices/OS? | Chrome/Safari/Firefox, iOS/Android, small screens, older OS versions |
| Localisation / i18n | Are language, date, currency and format rules correct? | AZ/EN switching, untranslated strings, special characters, currency format, long text overflowing buttons |
| Reliability / recovery | Does the system recover after a failure? | Network loss mid-payment, request retry (double-charge check) |
The most confused point: level ≠ type.
- A level says at which layer of the system the test runs: unit → integration → system → acceptance.
- A type says which quality characteristic the test looks at: functional, performance, security and so on.
The two dimensions cross each other: at system level you can run both functional and security tests. So "which level is performance testing?" is a badly formed question — performance is a type and can be executed at several levels.
The word integration appears in both lists, which is exactly why it confuses people: it is both a level (the layer between modules) and the name of the functional testing done at that layer.
Interview tactic: the smoke/sanity/regression/re-test quartet is asked in almost every manual QA interview. Keep them ready as one sentence + one example, e.g.: "Re-test — I verify the specific bug is fixed; regression — I verify that fix didn't break the premium calculation." Contrasting two concepts on the same example is the strongest answer.