Test levels and test types

"What is the difference between smoke and sanity testing?" and "how is UAT different from system testing?" are among the most common questions in testing interviews. They check that you know where each kind of testing fits. Two words help: a test level says how big a piece of the product you test and at what stage, and a test type says what quality you check. The two combine freely. You can measure performance on one function or on the whole system.

The five test levels

The ISTQB Foundation syllabus names five levels, from the smallest piece to the whole product.

1. Component (unit) testing checks one function, class or module on its own. Developers usually write these tests.
2. Component integration testing checks that components work together, for example that the cart sends the right items and quantities to the price calculator.
3. System testing checks the whole product from start to finish (end to end) against its requirements, in a test environment close to production. The test team usually does it. A test environment is a separate copy of the setup where tests run, so tests never touch the live system real users use (production).
4. System integration testing checks the product's connections to outside systems, such as a payment gateway (a service that takes card payments) or an SMS provider (a service that sends text messages).
5. Acceptance testing checks whether the product is ready to be accepted. Its forms are user acceptance testing (UAT), operational acceptance (checks that the system can be run and looked after, for example backup and recovery), contract and regulation acceptance, and alpha and beta testing.

UAT and system testing differ in who tests and why. In system testing, testers check the product against the specification to find defects. In UAT, business users or the client try real business tasks to decide whether the product meets their needs. UAT comes later and should find few defects. Alpha testing happens in the developer's test environment with people outside the development team. Beta testing happens on the users' own devices and sites, close to release.

Stubs and drivers

To test a part before its neighbours exist, you need stand-ins, called test doubles. A stub replaces a part that your code calls and returns fixed answers, such as a tax service that always returns 18% so your code can run without the real one. A driver replaces a part that calls your code: it feeds inputs in and starts the code. If the interest calculator is finished but the loan screen that calls it is not, you write a driver. A mock is a test double that also records how it was called, so the test can check those calls. Ask which side is missing: a missing caller needs a driver, a missing callee needs a stub.

Test types

Functional testing checks what the system does: login works, a discount is applied, an email is sent. Non-functional testing checks how well it does it, such as performance, security, usability (including accessibility), compatibility and reliability. "Search answers in under 2 seconds with 500 users online" is non-functional; "a 10% discount applies above 1,000" is functional.

Black box testing designs tests from requirements and behaviour without looking at the code. White box testing designs tests from the code's structure, such as statements (single instructions in the code, often one per line) and branches (the different paths an if can take), and measures coverage, which is how much of the code the tests run. Testers also use grey box testing: call an API (a way for one program to ask another program for data or actions), then check the database to see what was saved.

Smoke, sanity, retesting and regression

These four describe what happens around a new build. The order below is the usual one.

Smoke testing is a quick, broad check of the build: can users log in, open the main pages and finish the core flow, such as placing an order? If it fails, the build goes back and nobody wastes time on it.

Retesting, called confirmation testing by ISTQB, repeats the exact steps from a bug report on the build that has the fix. Sanity testing is a quick, narrow check that a changed area behaves sensibly. "Sanity" is an industry word with no ISTQB definition, and some teams use it as another name for smoke testing, so it is fine to say "in my team, sanity means...".

Regression testing checks that the change did not break anything that used to work, near the change or elsewhere. The suite grows every release and runs often, so it is the best candidate for automation.

How to answer in an interview

For any pair, say what each checks, when it runs, and who does it, then give one example. "After the discount fix I retested the bug with its original steps, then ran the checkout regression set, because pricing touches cart, payment and invoices."

Common mistakes

• Calling retesting "regression". Retesting checks the fix; regression protects the rest.
• Describing UAT as "testing by the QA team at the end".
• Swapping stub and driver.
• Presenting your team's meaning of "sanity" as a universal definition.

Recap

Levels go from unit to integration, system, system integration and acceptance. Types say what you check: functional or non-functional, black box or white box. Smoke decides whether a build is testable, retesting confirms a fix, and regression checks that nothing else broke.