System Testing

System testing evaluates the complete, integrated software system against its specified requirements. It is the first testing level where the entire system is tested as a whole—not individual modules or component interactions, but the fully assembled application operating in an environment that resembles production. System testing answers the question: "Does this complete system do what the requirements specification says it should do?" It validates both functional requirements (features work correctly) and non-functional requirements (performance, security, usability, reliability meet specified thresholds).

Position in the Testing Hierarchy

System testing occupies a critical position between integration testing and acceptance testing:

By this stage, individual components are verified (unit tested), their interactions are verified (integration tested), and system testing validates the assembled whole. Defects found at this level are typically systemic issues—performance bottlenecks, security gaps, workflow problems, or requirement misinterpretations that only manifest when all components operate together under realistic conditions.

Types of System Testing

Functional Testing verifies every requirement in the specification. Testers execute scenarios from the requirements document and verify correct behavior. For an e-commerce system: Can a user search products? Add to cart? Complete checkout? Receive confirmation? Each documented requirement has corresponding system test cases.

Performance Testing verifies the system meets speed, capacity, and scalability requirements:

• *Load testing:* System behavior under expected user load (1,000 concurrent users)
• *Stress testing:* System behavior beyond expected capacity (what happens at 10,000 users?)
• *Endurance testing:* System stability over extended periods (24-hour continuous operation)
• *Spike testing:* System response to sudden traffic bursts

Security Testing verifies the system resists unauthorized access, data theft, and malicious attacks. Penetration testing, vulnerability scanning, and access control verification are performed.

Usability Testing evaluates whether real users can accomplish tasks effectively. Observed user sessions reveal confusing interfaces, unclear workflows, and accessibility barriers.

Compatibility Testing verifies operation across different browsers, operating systems, devices, and screen sizes.

Recovery Testing verifies the system recovers gracefully from failures—database crashes, network outages, server restarts. Does data remain intact? Does the system resume operation correctly?

Reliability Testing measures system stability over time—mean time between failures, error rates under normal operation, and graceful degradation under partial failures.

Real-World Example: Banking Application System Testing

A new online banking platform undergoes system testing:

Functional Tests (200 test cases):

• Account balance displays correctly after deposits, withdrawals, and transfers
• Fund transfers between accounts update both balances atomically
• Bill payment schedules execute on the correct date
• Statement generation includes all transactions within the date range
• Multi-factor authentication enforces policy correctly

Performance Tests:

• 5,000 concurrent users performing balance inquiries: response time < 2 seconds
• 500 simultaneous fund transfers: all complete within 5 seconds, zero data corruption
• Month-end statement generation for 100,000 accounts completes within the batch window (4 hours)
• Login page handles 1,000 requests/second during morning peak without degradation

Security Tests:

• SQL injection attempts on all input fields are blocked
• Session tokens expire after 15 minutes of inactivity
• Failed login attempts trigger account lockout after 5 tries
• Sensitive data (SSN, account numbers) is encrypted in transit and at rest
• Penetration test finds no exploitable vulnerabilities

Recovery Tests:

• Database failover to replica completes in under 30 seconds with zero transaction loss
• Application server crash during fund transfer: transaction either completes fully or rolls back (no partial transfers)
• Network partition between application and database: queued operations resume correctly when connectivity restores

System Test Planning

A system test plan defines:

• Scope: Which requirements and features are tested (and which are explicitly out of scope)
• Entry criteria: Prerequisites for beginning system testing (all integration tests pass, environment is configured)
• Exit criteria: Conditions for declaring system testing complete (all critical tests pass, defect density below threshold)
• Environment: Hardware, software, network configuration, and test data requirements
• Schedule: Timeline for test execution, defect fixing, and retesting
• Resources: Team members, tools, and infrastructure needed

Test Environment

System testing requires an environment that closely mirrors production: same operating system versions, same database configurations, same network topology (even if scaled down), same security settings, and realistic data volumes. Differences between the test environment and production are a primary source of "works in test, fails in production" problems.

Defect Reporting and Tracking

System testing typically reveals the most diverse defects. Each defect report includes: severity (critical/high/medium/low), steps to reproduce, expected behavior, actual behavior, environment details, and supporting evidence (screenshots, logs). Defects are prioritized for fixing, and each fix requires retesting the specific defect plus regression testing to ensure the fix did not introduce new problems.

Entry and Exit Criteria

Entry criteria (start system testing when): All integration tests pass. Test environment matches configuration checklist. Test data is loaded and verified. Test team has reviewed requirements and test cases.

Exit criteria (system testing is complete when): All planned test cases executed. All critical and high-severity defects resolved. Defect discovery rate has stabilized (no new critical defects in final cycle). Performance metrics meet specified thresholds. Stakeholder sign-off obtained.