Software testing levels
A discount is calculated correctly by one function, sent correctly by the pricing service and displayed correctly in the storefront. The final invoice still applies the wrong rule. Saying that the feature was tested hides the question of where the behaviour was observed.
Software testing levels give the same feature several useful viewpoints. They do not create a ranking where one level replaces another. Each level asks what can be learned at its boundary.
Software testing levels: start with a component question
Component testing examines a small unit in isolation. For the discount example, the question might be whether a calculation handles the rule and its inputs. This level is fast and precise, but it does not show whether the component receives the right data from its neighbours.
Use integration testing to inspect the agreement between parts
Integration testing follows the connection between components or services. Check the contract, mapping, timing and error handling at the boundary. A correct function can still fail when a service sends a different currency, rounding mode or identifier.
Use system testing to follow the complete product path
System testing examines the assembled product in a realistic workflow. The discount may travel through catalog, pricing, checkout and invoice generation. The question is not only whether each part works, but whether the user-visible journey preserves the intended behaviour.
Use acceptance testing to connect behaviour to a decision
Acceptance testing asks whether the product meets the agreed business or user need. It can use a concrete scenario, data and outcome that a stakeholder recognises. A system test may pass while the business rule is still interpreted incorrectly.
Do not confuse levels with test types
Functional, performance, usability, security and other test types describe the quality question or purpose. A performance check can exist at more than one level. A functional check can be run against a component or the full system. Keeping the two dimensions separate makes coverage easier to discuss.
Use complementary coverage and name the boundary
For a feature, record which level gave each piece of evidence and which behaviour was deliberately left out. Fast component checks protect local logic; integration checks protect contracts; system and acceptance checks protect the journey and decision. The combination is stronger than any isolated layer.
The useful result is not a list of four labels. It is a map of questions, evidence and remaining uncertainty.
Software testing levels: trace one feature through four questions
Choose one small business rule, such as a discount, search filter or status transition. Write one question at the component, integration, system and acceptance boundary.
For each question, name the smallest evidence you need and the failure that evidence would expose. If two levels ask the same question, revise the wording until their boundaries differ.
Finish by stating which level you did not run and what that limits. This prevents a passing low-level check from being treated as proof of the whole journey.
Questions before the next step
- What can be learned at each boundary?
- Which contract connects the parts?
- What does the user or business need to recognise?
- Which level remains outside the evidence?
Practise testing levels, test types and related concepts with explanations for every answer.
Explore ISTQB Quiz →