SE: Testing Levels in the SDLC

Testing is executed at multiple hierarchical layers, each focusing on a different scope of software validation.

These layers are known as Testing Levels:

  1. Unit Testing
  2. Integration Testing
  3. System Testing
  4. Acceptance Testing

1. Unit Testing

Unit testing validates the smallest independent piece of software, typically at the function or method level.

Key characteristics:

  • Written and executed by the developer during the build phase
  • Targets isolated modules, logic branches, and data correctness
  • Prevents defects before modules interact
  • Reduces debugging complexity later in the cycle

Example in JavaScript:

js
function add(a, b) {
  return a + b;
}

console.assert(add(2, 3) === 5, "Test Failed: 2 + 3 should equal 5");

Here, we validate pure logic without UI, network, or database dependencies.

Unit tests often run using frameworks like:

  • Jest
  • Mocha
  • Vitest
  • GoogleTest (for C++)
  • Catch2 (for C++)

2. Integration Testing

Integration testing validates interactions between two or more combined modules. The goal is to detect defects that appear when components exchange data or events.

Properties:

  • Treated as a Black-Box test (input → output)
  • Executed after combining modules into subsystems
  • Typically performed by software or RTOS/embedded engineers
  • Focuses on interface contracts, communication, timing, and data format correctness

Example:

If a payment service sends a transaction object:

json
{ "amount": 100, "currency": "EUR", "method": "iDEAL" }

Integration testing verifies:

  • Was it received?
  • Was it parsed correctly?
  • Did the next module handle it without crashing?

In embedded systems, integration testing may validate:

  • UART message format correctness
  • SPI timing alignment
  • Sensor driver + ADC module interaction
  • Task scheduling + queue communication

3. System Testing

System testing validates the entire integrated product as a complete software system. It ensures the final software behaves correctly end-to-end.

Includes:

  • Functional testing
  • Non-functional testing
  • Full workflow validation

Executed on a staging environment identical to production to ensure realistic results.

System testing validates:

  • The software is fully operational
  • All modules cooperate correctly
  • System architecture and requirements were satisfied

Example scenarios:

  • Full IoT dashboard loads correctly and controls devices
  • Firmware update flow works without corruption
  • System handles low memory safely
  • Audio/video pipeline maintains sync

4. Acceptance Testing

Acceptance testing is formal validation performed by customers, stakeholders, or product owners.

Timing:

  • Done during the maintenance stage of SDLC
  • Focuses on business needs, usability, and contractual requirements

Acceptance testing ensures software is:

  • Fit for real user usage
  • Meeting business goals
  • Aligned with user expectations, not just technical correctness

Acceptance testing answers:

  • Do users accept the behavior?
  • Is the system solving their real problem?
  • Does it integrate smoothly into their daily processes?

LevelGoalExecuted ByEnvironment
UnitValidate logic correctness at function/module levelDeveloperLocal build/test phase
IntegrationValidate interfaces between combined modulesEngineer / QAPost-merge environment
SystemValidate full system compliance (functional + non-functional)QA / EngineeringStaging (similar to production)
AcceptanceValidate business needs and stakeholder satisfactionCustomer / StakeholdersProduction or UAT environment

Summary

Software testing is not only about finding bugs — it is about validating engineering contracts, architecture behavior, system resilience, and business value delivery.

A strong tester must understand both:

  • Expected functionality
  • System behavior under real operating conditions
  • Architectural reliability guarantees