Testing and Debugging

This lesson covers the types of software testing, testing strategies, and the use of appropriate test data. The OCR H446 specification requires you to understand unit, integration, system and acceptance testing, black-box and white-box testing, alpha and beta testing, and the three types of test data.

---

Why Testing Matters

Testing is essential to:

• Find defects (bugs) before the software is released to users.
• Verify that the software meets its requirements specification.
• Validate that the software does what the user actually needs.
• Improve quality and reliability.
• Reduce cost — finding bugs early is far cheaper than fixing them after release.

---

Levels of Testing

Testing is carried out at different levels, from individual components to the complete system.

Unit Testing

Aspect	Detail
What is tested	Individual components — typically a single function, method or class
Who does it	The developer who wrote the code
When	During development, as each unit is written
Goal	Verify that each unit works correctly in isolation
Tools	Automated testing frameworks (e.g. JUnit, pytest, NUnit)

Integration Testing

Aspect	Detail
What is tested	The interactions between two or more units/modules when they are combined
Who does it	Developers or a dedicated testing team
When	After unit testing, as modules are combined
Goal	Verify that modules work together correctly — data is passed correctly between components
Common issues found	Interface mismatches, incorrect data formats, timing issues, missing error handling between modules

Approaches to Integration Testing

Approach	Description
Top-down	Start with the highest-level module and progressively integrate lower-level modules. Use stubs (dummy modules) for modules not yet integrated
Bottom-up	Start with the lowest-level modules and progressively integrate higher-level modules. Use drivers (dummy callers) for modules not yet integrated
Big bang	Integrate all modules at once and test. Simple but harder to isolate faults

System Testing

Aspect	Detail
What is tested	The complete, integrated system as a whole
Who does it	A dedicated testing team (not the developers)
When	After integration testing
Goal	Verify that the entire system meets the requirements specification
Types	Functional testing (does it do what it should?), performance testing (is it fast enough?), security testing, usability testing

Acceptance Testing

Aspect	Detail
What is tested	The system in the context of real user requirements
Who does it	The client or end users
When	After system testing, before deployment
Goal	Validate that the system meets the client's actual needs and is acceptable for deployment
Types	User Acceptance Testing (UAT) — end users test in a real-world scenario. Contract acceptance — tested against the agreed contract specification

---

Testing Strategies

Black-Box Testing

Aspect	Detail
Approach	The tester does NOT look at the internal code. Tests are based only on the inputs and expected outputs described in the specification
Also called	Functional testing, specification-based testing
Advantage	Tests what the software should do from the user's perspective
Disadvantage	May miss internal errors that do not affect outputs for the tested inputs
Used at	System testing, acceptance testing

White-Box Testing

Aspect	Detail
Approach	The tester HAS access to the internal code. Tests are designed to exercise specific code paths, branches and conditions
Also called	Structural testing, glass-box testing
Techniques	Statement coverage (every line executed at least once), branch coverage (every if/else path taken), path coverage (every possible route through the code)
Advantage	Thorough — can test all code paths
Disadvantage	Time-consuming; does not test whether the specification itself is correct
Used at	Unit testing, integration testing

Black-Box vs White-Box Comparison

Feature	Black-Box	White-Box
Code access	No	Yes
Based on	Specification / requirements	Code structure
Tests	Inputs and outputs	Code paths and branches
Tester knowledge	No programming needed	Must understand the code
Best for	Functional correctness	Code coverage and logic errors

---

Alpha and Beta Testing

Alpha Testing