Unit I - Introduction | Software Testing

📌 Syllabus Topics Covered

5 Hrs Weightage

1.1 Introduction
1.2 Basics of Software Testing
1.3 Testing Principles (Goals, Testing Life Cycle, Phases of Testing)
1.4 Defects (Defect Life Cycle, Defect Report)
1.5 Test Plan (IEEE format)
1.6 Verification and validation

📖 Comprehensive Theoretical Notes

Exam-Oriented Theory

1.1 & 1.2 Basics of Software Testing & Quality Assurance

Software Testing: The systematic process of executing a software application with the intent of finding bugs, errors, and discrepancies between expected behavior and actual behavior, thereby verifying that the system satisfies specified requirements.

Fundamental Taxonomy of Software Flaws:

Error (Mistake): A human action by a developer, analyst, or designer that produces an incorrect result (e.g., programming typo, logical misconception).
Fault / Bug / Defect: A manifestation of an error in software source code, documentation, or design schema.
Failure: The dynamic operational deviation of the software from its expected behavior during runtime execution visible to users.

1.3 Testing Principles & Software Testing Life Cycle (STLC)

7 Fundamental Principles of Software Testing (ISTQB):

Testing shows the presence of defects, not their absence.
Exhaustive testing is impossible (risk-based testing is required).
Early testing saves time and money (shifting left).
Defect clustering (Pareto Principle: 80% of bugs reside in 20% of modules).
Pesticide paradox (repeating identical tests loses bug-finding effectiveness).
Testing is context-dependent (e-commerce vs banking vs medical devices).
Absence-of-errors fallacy (a bug-free system is useless if it fails user business needs).

Phases of STLC: 1. Requirement Analysis $\rightarrow$ 2. Test Planning $\rightarrow$ 3. Test Case Design $\rightarrow$ 4. Test Environment Setup $\rightarrow$ 5. Test Execution $\rightarrow$ 6. Test Closure & Reporting.

1.4 - 1.6 Defect Life Cycle, IEEE 829 Test Plan, and V&V

Defect Life Cycle (Bug Life Cycle): New $\rightarrow$ Assigned $\rightarrow$ Open $\rightarrow$ Fixed $\rightarrow$ Pending Retest $\rightarrow$ Retest $\rightarrow$ Verified $\rightarrow$ Closed (Alternative branches: Rejected, Duplicate, Deferred, Reopened).

IEEE 829 Standard Test Plan Format (16 Sections): Test Plan Identifier, Introduction, Test Items, Features to be Tested, Features not to be Tested, Approach / Strategy, Item Pass/Fail Criteria, Suspension/Resumption Criteria, Test Deliverables, Testing Tasks, Environmental Needs, Staffing & Training Needs, Responsibilities, Schedule, Risks & Contingencies, Approvals.

Verification vs Validation:

Verification ('Are we building the product right?'): Static evaluation of documents, designs, and code without running programs (Reviews, Walkthroughs, Inspections).
Validation ('Are we building the RIGHT product?'): Dynamic evaluation of actual executing software to ensure it satisfies user expectations (Functional, System, UAT).

🔑 Key Concepts & Examination Keywords

Quick Terminology

Defect Life Cycle

The journey of a defect through various states from discovery by a tester to resolution and closure by developers.

IEEE 829

The international standard defining the formal 16-section structure and content of software test documentation.

Verification

Static checking of work products (code, design, SRS) without executing code to verify compliance with specifications.

Validation

Dynamic testing of the running software against user business requirements and operational expectations.

🎯 High-Yield Important Examination Questions

8–10 Descriptive Points Each

Q1. Explain the complete Software Testing Life Cycle (STLC) step-by-step with entry criteria, exit criteria, and deliverables for each phase.

10 MarksSTLC PhasesCore

▼

📝 Detailed Examination Answer (10-Point Model):

Overview of STLC: The Software Testing Life Cycle is a structured sequence of specific testing activities conducted systematically to ensure software quality goals are met.
Phase 1: Requirement Analysis: Testers review SRS and architectural documents to identify testable requirements, acceptance criteria, and create the Requirement Traceability Matrix (RTM).
Phase 2: Test Planning: Test Lead estimates testing effort, determines test scope, selects testing strategy, allocates resources, defines toolsets, and authors the IEEE 829 Test Plan.
Phase 3: Test Case Development: Testers author detailed test cases, prepare test data, specify preconditions, expected results, and review test scenarios with business analysts.
Phase 4: Test Environment Setup: Configures hardware, server operating systems, database schemas, test data dumps, and network infrastructure; verified via Smoke / Sanity testing.
Phase 5: Test Execution: Testers execute test cases against the build, log actual results (Pass/Fail), document defects in tracking tools (Jira/Bugzilla), and perform regression testing on fixes.
Phase 6: Test Closure & Reporting: Testing team analyzes test metrics (Defect Density, DRE), prepares the final Test Summary Report, documents lessons learned, and archives test assets.
Entry and Exit Criteria Discipline: Each phase has explicit prerequisites (Entry Criteria) and completion deliverables (Exit Criteria) before advancing to subsequent stages.
Continuous Defect Retesting: When developers mark bugs 'Fixed', testers re-execute failed test cases and run automated regression suites to ensure no ripple-effect defects.
Shift-Left Testing Alignment: Modern STLC starts simultaneously with SDLC requirement phases to catch defects when they are cheapest to rectify.

Q2. Explain the Defect Life Cycle (Bug Life Cycle) in detail with a state transition diagram and describe the standard contents of a Defect Report.

10 MarksDefect Life Cycle & Reporting

▼

📝 Detailed Examination Answer (10-Point Model):

Definition of Defect Life Cycle: The formal journey of a discovered software bug through various operational states from initial identification to final verification and closure.
State 1: New / Logged: A tester discovers a defect during test execution and logs it into the bug tracking system with evidence.
State 2: Assigned & Open: Test Lead / Dev Lead reviews the bug and assigns it to a specific developer; developer investigates root cause (State: Open).
Triage Decisions (Rejected, Duplicate, Deferred): Developer may mark bug: `Rejected` (not a bug), `Duplicate` (already logged), or `Deferred` (postponed to future release).
State 3: Fixed: The developer refactors source code, commits changes, and marks the defect as `Fixed` in the new build.
State 4: Pending Retest & Retest: The bug moves to the tester's queue for verification against the patched software build.
State 5: Verified & Closed: If the bug no longer occurs and functionality passes, the tester changes the state to `Verified` and then `Closed`.
Alternative State: Reopened: If the defect persists or causes a regression in the new build, the tester marks the bug as `Reopened` and routes back to the developer.
Defect Report Essential Fields: Defect ID, Title/Summary, Description, Steps to Reproduce (1..N), Expected Result, Actual Result, Severity, Priority, Environment/OS, Build Number, Screenshots/Logs, Reporter, Assignee.
Distinction: Severity vs Priority: Severity measures the technical impact on system operation (Crash/Fatal); Priority measures the business urgency for immediate fixing.

Q3. Describe the 16 sections of an IEEE 829 standard Test Plan and explain the difference between Verification and Validation.

10 MarksIEEE 829 Test Plan & V&V

▼

📝 Detailed Examination Answer (10-Point Model):

IEEE 829 Standard Test Plan Purpose: Provides a comprehensive formal blueprint detailing the scope, approach, resources, schedule, and management of software testing activities.
Test Plan Sections 1-4 (Scope & Objectives): 1. Test Plan Identifier (unique ID), 2. Introduction, 3. Test Items (modules/versions to test), 4. Features to be Tested.
Test Plan Sections 5-8 (Strategy & Criteria): 5. Features Not to be Tested, 6. Approach (testing types/tools), 7. Item Pass/Fail Criteria, 8. Suspension & Resumption Criteria.
Test Plan Sections 9-12 (Deliverables & Setup): 9. Test Deliverables (cases, logs, reports), 10. Testing Tasks, 11. Environmental Needs (hardware/software/network), 12. Responsibilities.
Test Plan Sections 13-16 (Management & Approvals): 13. Staffing & Training Needs, 14. Schedule & Milestones, 15. Risks & Contingencies, 16. Approvals & Sign-offs.
Verification Definition & Question: Verification asks: 'Are we building the product right?'; it is a static inspection process evaluating artifacts without running code.
Verification Techniques: Includes peer code reviews, formal inspections, architectural walkthroughs, and automated static code analysis (SonarQube).
Validation Definition & Question: Validation asks: 'Are we building the right product?'; it is a dynamic testing process executing software to ensure customer requirements are fulfilled.
Validation Techniques: Includes Black-Box testing, White-Box testing, System testing, Performance testing, and User Acceptance Testing (UAT).
Cost of Defects Rule: Catching defects during Verification (Requirement/Design phase) costs up to 100x less than finding them during late Validation or Production.

⚖️ Comprehensive Comparison & Difference Tables

8+ Comparison Criteria

📊 Verification vs Validation in Software Engineering

Comparison Parameter	Verification (Static)	Validation (Dynamic)
Core Question	Are we building the product RIGHT?	Are we building the RIGHT product?
Execution Nature	Static testing performed WITHOUT executing program code.	Dynamic testing performed BY EXECUTING program code.
Primary Objective	Ensures software conforms to specification documents (SRS/Design).	Ensures software fulfills user expectations and business needs.
Techniques Used	Code reviews, walkthroughs, formal inspections, static analyzers.	Black-box, white-box, unit, integration, and system testing.
Timing in SDLC	Performed early throughout requirement and design phases.	Performed after code units and builds are compiled.
Artifacts Evaluated	SRS documents, architectural designs, database schemas, code syntax.	Compiled binary executables, APIs, and graphical user interfaces.
Performed By	Software developers, architects, and business analysts.	Dedicated QA engineers, test automation engineers, and end-users.
Target Identification	Discovers inconsistencies, ambiguities, and syntax errors.	Discovers functional failures, performance bottlenecks, and regressions.

📊 Quality Assurance (QA) vs Quality Control (QC)

Comparison Parameter	Quality Assurance (QA)	Quality Control (QC)
Core Focus	Process-oriented: focuses on preventing defects in the development process.	Product-oriented: focuses on identifying and fixing defects in the final product.
Nature of Activity	Proactive activity establishing engineering standards and guidelines.	Reactive activity testing and verifying artifacts against specifications.
Primary Goal	Improve development and testing processes to prevent bugs from occurring.	Detect and correct bugs in software before delivery to customers.
Techniques	Audits, process definitions, training, CMMI/ISO standards compliance.	Test case execution, black-box testing, automated regression runs.
Responsibility Scope	The entire software engineering organization and management.	Dedicated Quality Control testing team.
Timing	Implemented continuously throughout the entire SDLC.	Implemented during the testing and verification phases.
Failure Handling	Analyzes root causes of defects to update development process rules.	Logs defect reports and retests fixes.
Cost Impact	Reduces overall lifecycle cost by preventing defect injection early.	Prevents defective software from reaching end-users.

⚡ Quick Pre-Exam Revision Summary

5-Minute Recap

💡 Core Takeaways & High-Yield Summary

Error is human mistake $\rightarrow$ Defect/Bug is flaw in code $\rightarrow$ Failure is runtime behavioral deviation.
STLC phases: Requirement Analysis $\rightarrow$ Test Planning $\rightarrow$ Test Design $\rightarrow$ Env Setup $\rightarrow$ Execution $\rightarrow$ Closure.
Defect life cycle states: New $\rightarrow$ Assigned $\rightarrow$ Open $\rightarrow$ Fixed $\rightarrow$ Retest $\rightarrow$ Verified $\rightarrow$ Closed.
IEEE 829 Test Plan contains 16 formal sections (Scope, Strategy, Pass/Fail criteria, Risks, Schedule).
Verification is static checking without code execution; Validation is dynamic testing with code execution.
Severity is technical impact (Fatal/Major); Priority is business urgency for fixing (High/Low).