Testing asks one question: does this software do what it should, and does it avoid doing what it should not? Two words frame everything. Verification asks whether the product is built right, meaning it matches its specification. Validation asks whether the right product was built, meaning it meets the user's real needs. A program can pass verification and still fail validation if the specification itself misunderstood the user.
Testing happens in levels. Unit testing checks single functions or modules in isolation. Integration testing checks modules working together. System testing checks the whole product against its requirements. Acceptance testing checks whether the customer accepts it. Two strategies cut across these levels. Black-box testing uses only inputs and expected outputs, without looking at the code. White-box testing uses the internal structure, for example designing tests that execute every branch. A useful rule: black-box tests find missing functions and wrong behaviour, white-box tests find hidden paths and logic errors. Neither replaces the other.
Worked example — black-box versus white-box. A login form accepts passwords of 8 to 16 characters. A black-box tester tries 7, 8, 16 and 17 characters, because boundaries are where errors hide. A white-box tester looks at the code, sees an if-statement checking password length and another checking for a digit, and designs tests that take each branch both ways. Together they cover what the code does and what the user experiences.