Software Testing Basics

Software testing is an engineering activity, not a trial-and-error task. It follows:

Defined processes
Systematic techniques
Standards and documentation

Like other engineering disciplines, testing requires planning, design, execution, measurement, and control.

Why Testing is an Engineering Activity

Uses scientific methods
Based on requirements and design
Requires tools and techniques
Produces measurable results

Engineering View of Testing


Requirements → Test Planning → Test Design → Test Execution → Analysis

Characteristics

Structured approach
Risk-based decision making
Continuous improvement

Role of Process in Software Quality

Software quality refers to the degree to which a software product:

Meets requirements
Is reliable and maintainable
Satisfies user expectations

Why Process is Important

Quality is built into the process, not just tested at the end.

Process and Quality Relationship


Good Process → Good Product → High Quality
Poor Process → Defects → Low Quality

Key Processes Affecting Quality

Requirements engineering
Design process
Coding standards
Testing process
Review and audit

Process Models Supporting Quality

Waterfall
V-Model
Agile
DevOps

Table: Process vs Product Quality

Aspect	With Process	Without Process
Defects	Fewer	More
Cost	Lower	Higher
Reliability	High	Low
Maintenance	Easy	Difficult

Testing as a Process

Testing is a well-defined process with specific inputs, activities, and outputs.

Testing Process Stages

Test planning
Test analysis
Test design
Test execution
Defect reporting
Test closure

Testing Process Flow


Plan → Design → Execute → Report → Close

Importance of Testing Process

Improves test coverage
Reduces risk
Ensures traceability
Provides repeatability

Table: Testing Process Activities

Phase	Main Activity
Planning	Strategy, schedule
Design	Test cases
Execution	Run test cases
Reporting	Defect logging
Closure	Metrics, reports

Basic Definitions in Software Testing

1. Error: A human mistake during coding or design.

2. Defect (Bug): A fault in the software that may cause incorrect behavior.

3. Failure: When software does not behave as expected during execution.

Relationship Diagram: Error → Defect → Failure

Verification

Checks whether the software is built correctly.

“Are we building the product right?”

Validation

Checks whether the right product is built.

“Are we building the right product?”

Test Case

A set of conditions and inputs to verify a requirement.

Basic Definitions Table

Term	Meaning
Error	Human mistake
Defect	Fault in software
Failure	Incorrect behavior
Verification	Process check
Validation	Product check
Test Case	Test scenario

Software Testing Principles

Software testing follows fundamental principles that guide effective testing.

Principle 1: Testing Shows Presence of Defects

Testing can prove defects exist, not that software is defect-free.

Principle 2: Exhaustive Testing is Impossible

Testing all combinations is not feasible; focus on risk-based testing.

Principle 3: Early Testing Saves Cost

Defects found early are cheaper to fix.

Principle 4: Defect Clustering

Most defects are found in few modules.

Principle 5: Pesticide Paradox

Repeated tests stop finding new defects; tests must be reviewed and updated.

Principle 6: Testing is Context Dependent

Different software needs different testing approaches.

Principle 7: Absence of Errors Fallacy

A defect-free system is useless if it does not meet user needs.

Software Testing Principles Table

Principle	Meaning
Defects presence	Testing finds bugs
No exhaustive testing	Limited testing
Early testing	Cost reduction
Defect clustering	Few modules, more bugs
Pesticide paradox	Update test cases
Context dependent	Project specific
Absence of errors	User satisfaction

Summary

Testing is a professional engineering discipline
Quality depends on process
Testing follows a defined life cycle
Clear terminology avoids confusion
Principles guide effective testing

The Tester’s Role in a Software Development Organization

Role of a Tester

A software tester is responsible for ensuring that the software:

Meets specified requirements
Is free from critical defects
Delivers expected quality to users

Testing is not only about finding bugs but also about preventing defects.

Key Responsibilities of a Tester

Understand requirements and specifications
Design test cases and test data
Execute test cases
Report and track defects
Participate in reviews
Ensure product quality

Tester’s Position in SDLC


Requirements → Design → Coding → Testing → Deployment
        ↑            ↑          ↑
      Tester reviews at each stage

Tester vs Developer (Brief)

Aspect	Tester	Developer
Focus	Quality assurance	Feature development
Goal	Find defects	Build functionality
Perspective	User & risk-based	Technical

Origins of Defects

Origins of defects refer to the source or stage where defects are introduced during software development.

Major Sources of Defects

Requirements Phase: Ambiguous or incomplete requirements
Design Phase: Poor architecture decisions
Coding Phase: Logical or syntax errors
Testing Phase: Inadequate test coverage
Maintenance Phase: Incorrect bug fixes

Defect Origin Table

Phase	Common Defects
Requirements	Missing requirements
Design	Incorrect algorithms
Coding	Logic errors
Testing	Missed defects
Maintenance	Regression bugs

Defect Classes

Defect classes categorize defects based on their nature and impact.

Common Defect Classes

Class	Description	Example
Functional	Feature not working	Login failure
Interface	UI or integration	Button misaligned
Performance	Slow response	Page load delay
Security	Vulnerability	SQL injection
Compatibility	OS/browser issues	App crash
Usability	Poor user experience	Confusing UI

Why Defect Classification is Important

Helps root cause analysis
Improves process quality
Enables defect trend analysis

The Defect Repository and Test Design

A defect repository is a centralized database where all detected defects are:

Stored
Classified
Tracked
Analyzed

Typical Defect Repository Fields

Field	Description
Defect ID	Unique identifier
Description	Defect details
Severity	Impact level
Priority	Fix urgency
Status	Open/Closed
Root Cause	Source

Role in Test Design

Identifies defect-prone areas
Improves test case effectiveness
Supports risk-based testing
Prevents recurrence of defects

Defect Repository Flow


Defect Found → Logged → Analyzed → Fixed → Verified → Closed

Defect Examples

Example 1: Functional Defect

Login fails with valid username and password.

Example 2: Performance Defect

Report generation takes 5 minutes instead of 30 seconds.

Example 3: Interface Defect

Submit button overlaps text on mobile view.

Example 4: Security Defect

Password visible in plain text.

Example Table

Defect Type	Example
Functional	Payment not processed
UI	Broken layout
Performance	Slow API
Security	Unauthorized access

Developer / Tester Support for Developing a Defect Repository

Developer Support

Provide clear root cause analysis
Update defect status accurately
Suggest preventive measures
Improve coding standards

Tester Support

Log detailed defect information
Classify defects correctly
Attach screenshots/logs
Verify fixes properly

Collaborative Approach Diagram


Tester → Defect Log → Repository → Developer
   ↑                                 ↓
   └──────── Verification ──────────┘

Benefits of Collaboration

Faster defect resolution
Better defect data quality
Continuous process improvement

Summary Table

Topic	Key Point
Tester’s role	Quality assurance
Defect origins	Introduced at any SDLC phase
Defect classes	Categorization
Defect repository	Central defect database
Defect examples	Real-world cases
Dev–Tester support	Collaboration

Exam Writing Tips

Write definitions first
Use tables for classification
Draw simple diagrams
Give real-life examples
Keep answers structured

Software Testing Basics