Unit 1.1: Introduction to Software Testing

1. What is Software Testing?

Definition: Software testing is a process of executing a program or application with the intent of finding the software bugs. It involves the execution of a software component or system component to evaluate one or more properties of interest.

2. Why is Testing so Hard?

• Complexity: Modern software is incredibly complex with millions of lines of code. Even a small app has thousands of states.
• Infinite Paths: The number of possible input combinations and execution paths is practically infinite. You cannot test everything.
• Hidden Defects: Some bugs only appear under very specific, rare conditions (race conditions, memory leaks over time).
• Changing Requirements: Software evolves rapidly. New features can break old ones (Regression).
• Human Factor: Developers cannot effectively test their own code due to "Confirmation Bias" (seeing what they expect to see). They unconsciously avoid edge cases that might break their logic.

3. Goals of Testing

1. Find Defects: The primary goal is to catch bugs before the customer does.
2. Prevent Defects: QA starts early. Reviewing requirements can find ambiguity before a single line of code is written.
3. Ensure Quality: To gain confidence in the level of quality.
4. Verification: Confirming that the software meets specific requirements ("Are we building the product right?").
5. Validation: Confirming that the software meets user needs ("Are we building the right product?").

4. Seven Principles of Software Testing

These are the core guidelines for effective testing:

1. Testing shows the presence of defects, not their absence: Testing can prove bugs exist, but cannot prove that software is 100% bug-free.
2. Exhaustive testing is impossible: Testing everything (all combinations of inputs) is not feasible except for trivial cases. We use risk analysis to focus testing.
3. Early testing: Testing should start as early as possible in the SDLC (Requirement Analysis phase) to save cost.
4. Defect clustering: A small number of modules usually contain most of the defects (Pareto Principle: 80% of bugs are in 20% of code).
5. Pesticide paradox: If the same tests are repeated over and over, they will eventually stop finding new bugs. New tests must be written.
6. Testing is context dependent: Testing a safety-critical medical app is different from testing a mobile game.
7. Absence-of-errors fallacy: Finding and fixing bugs doesn't help if the system built is unusable or doesn't fulfill the user's needs.