Software Testing in Software Engineering: Objectives, Principles, Process & Types
What is Software Testing?
Software Testing is a planned activity used to evaluate whether software behaves as expected and to identify defects before those defects cause problems for real users.
Testing does not only ask:
Testing can be applied to:
- Requirements
- Design documents
- Source code
- APIs
- Database behaviour
- User interfaces
- Complete applications
- System integrations
- Documentation
- Configuration
Why is Software Testing Necessary?
Software systems are created by humans, and human work can contain mistakes. Requirements may be misunderstood, designs may be incomplete, code may contain logical defects, integrations may fail, and unexpected user behaviour may expose problems.
Evaluate whether expected requirements are satisfied.
Reduce the chance of serious failures in real use.
Finding defects earlier can reduce expensive later rework.
Provide evidence that important software behaviour has been checked.
Real-Life Example
Imagine an online banking application that incorrectly transfers ₹10,000 instead of ₹1,000 because of a calculation defect.
The application may still open normally, accept login details, and display the correct screens. Without proper testing, a serious financial defect may remain hidden.
Objectives of Software Testing
Different projects can have different testing objectives, but the most important objectives include the following.
Find Defects
Discover incorrect behaviour, missing functionality, and inconsistencies.
Prevent Defects
Reviews and early testing activities can identify problems before they reach later development stages.
Verify Requirements
Check whether the product has been built according to specified requirements.
Validate User Needs
Determine whether the completed product is suitable for its intended users and purpose.
Reduce Risk
Identify failures that could damage business, safety, security, money, or user trust.
Build Confidence
Provide stakeholders with evidence about product quality.
Support Decisions
Provide information that helps decide whether software is ready for release.
Meet Standards
Check compliance with applicable contractual, legal, regulatory, or technical requirements.
Improve Quality
Testing information can help improve both the product and development process.
Error, Defect and Failure
These three words are related, but they should not be treated as exactly the same thing.
Error
An error is a human action or mistake that can produce an incorrect result.
Example: a developer misunderstands a percentage formula.
Defect
A defect is a flaw introduced into a software work product.
Example:
when the correct logic should divide by 5.
Failure
A failure happens when the system executes and does not perform a required function correctly.
Example: the student receives the wrong percentage on the result page.
Software Testing vs Debugging
| Basis | Testing | Debugging |
|---|---|---|
| Purpose | Detect failures and reveal defects | Find the cause of a defect and fix it |
| Main Performer | Testers, developers, users, or other stakeholders depending on context | Usually developers |
| Main Question | Where does the software behave incorrectly? | Why did the failure happen and how should it be corrected? |
| Output | Test results and defect information | Corrected code or design |
Debugging investigates and fixes the cause.
Seven Principles of Software Testing
The seven testing principles are extremely important for semester exams and testing interviews.
Testing Shows the Presence of Defects
Testing can show that defects exist, but successful testing cannot mathematically prove that absolutely no defect exists.
A system passing 1,000 tests may still fail under a condition that was never tested.
Exhaustive Testing is Impossible
Testing every possible input, state, path, browser, user action, and data combination is usually impossible except for very small systems.
Testing should therefore be prioritised using risk, techniques, and business importance.
Early Testing Saves Time and Cost
Testing activities should begin as early as possible.
Finding an unclear requirement during review is generally easier than fixing the same issue after design, coding, testing, deployment, and customer use.
Defects Cluster Together
A relatively small number of modules often contain a large proportion of the defects.
Complex, frequently changed, or historically problematic modules may require more testing.
Tests Wear Out
If the same tests are repeated again and again without change, they may stop finding new defects.
Test cases should be reviewed, improved, and expanded when the product changes.
Testing is Context Dependent
The testing approach depends on the type of software.
Testing a banking application, mobile game, medical system, and university website requires different priorities and techniques.
Absence-of-Errors Fallacy
Finding and fixing many defects is useless if the software still does not solve the user's actual problem.
A technically stable product can still fail if it implements the wrong requirements.
Verification vs Validation
Verification and Validation are closely related concepts in Software Engineering.
Are We Building the Product Right?
Verification checks whether work products satisfy specified requirements, standards, or design expectations.
Examples:
- Requirement reviews
- Design reviews
- Code inspections
- Static analysis
Are We Building the Right Product?
Validation checks whether the completed or evolving product satisfies intended user needs and expected use.
Examples:
- Executing user workflows
- System testing
- Acceptance testing
Static Testing vs Dynamic Testing
| Basis | Static Testing | Dynamic Testing |
|---|---|---|
| Execution Required? | No | Yes |
| Typical Targets | Requirements, designs, source code, test cases, documentation | Executable software |
| Examples | Reviews, walkthroughs, inspections, static analysis | Unit, system, performance, acceptance testing |
| Can Start | Very early | When executable software or component exists |
| Useful For | Finding defects without execution | Observing actual behaviour during execution |
Static testing is particularly valuable because almost any readable work product can be reviewed, including requirements, source code, test plans, contracts, models, and test cases.
Types of Static Reviews
Informal Review
Simple review without a highly formal process.
Walkthrough
The author usually leads participants through the work product.
Technical Review
Technical peers evaluate suitability and technical correctness.
Inspection
A formal review with defined roles, process, and defect recording.
Software Testing Process
Modern testing is not only “write test case → run test → report bug”. A complete test process includes planning, monitoring, analysis, design, implementation, execution, and completion activities.
Software Testing Life Cycle (STLC)
Many university books and companies explain testing using the Software Testing Life Cycle.
1. Requirement Analysis
The testing team studies requirements to identify:
- Testable requirements
- Functional behaviour
- Non-functional requirements
- Acceptance criteria
- Risks
- Missing or unclear requirements
- Automation opportunities
2. Test Planning
The team decides how testing will be performed.
A test plan may include:
- Scope
- Objectives
- Test approach
- Resources
- Tools
- Schedule
- Risk
- Environment
- Entry criteria
- Exit criteria
3. Test Case Development
Test conditions are converted into test scenarios, test cases, test data, and expected results.
4. Test Environment Setup
Required hardware, software, browsers, devices, services, databases, accounts, network configuration, and test data are prepared.
5. Test Execution
Test cases are executed and actual output is compared with expected output. Failures are investigated and defects are reported.
6. Test Closure
The team checks whether testing objectives were achieved and prepares a final summary.
Closure may include:
- Test completion report
- Coverage achieved
- Defect statistics
- Open risks
- Lessons learned
- Archived testware
Entry Criteria and Exit Criteria
Entry Criteria
Conditions that should be satisfied before a test activity begins.
Examples:
- Build available
- Environment ready
- Requirements approved
- Test data prepared
Exit Criteria
Conditions used to decide whether testing can finish.
Examples:
- Required tests executed
- Target coverage achieved
- Critical defects resolved
- Acceptable residual risk
Levels of Software Testing
A test level groups testing activities according to the development level or system scope being tested.
Modern ISTQB terminology distinguishes five test levels.
Traditional University View
Many Software Engineering textbooks simplify the levels as:
Unit / Component Testing
Individual functions, methods, classes, or modules are tested separately.
Example: testing calculateTotal() independently.
Integration Testing
Two or more components are combined and their interfaces are tested.
Example:
Integration Strategies
Top-Down Integration
Higher-level modules are integrated first. Temporary lower modules may be replaced by stubs.
Bottom-Up Integration
Lower-level modules are integrated first. Drivers may be used to call unfinished higher-level logic.
Big-Bang Integration
Many components are combined together at once. Fault isolation can become difficult.
System Testing
The complete integrated system is evaluated against system requirements.
Acceptance Testing
Acceptance testing evaluates whether the system is suitable for delivery, deployment, or operational use.
Major Types of Software Testing
Software testing can be classified in many different ways. One test can belong to more than one category.
Static / Dynamic
Functional / Non-Functional
Black / White / Grey Box
Retesting / Regression
Functional Testing
Functional testing checks what the software does.
It verifies functions, features, inputs, outputs, and business rules.
Example
For a login page:
- Valid username + valid password → Login successful
- Invalid username → Error shown
- Wrong password → Error shown
- Blank password → Validation displayed
- Locked account → Access denied
Non-Functional Testing
Non-functional testing checks how well the system performs rather than only whether a particular feature exists.
Performance Testing
Evaluates response time, throughput, resource use, and stability.
Load Testing
Checks behaviour under expected or increasing user/workload levels.
Stress Testing
Pushes the system beyond normal operating limits to observe failure and recovery.
Endurance Testing
Checks system behaviour under sustained load over a long period.
Scalability Testing
Checks how the system handles increased users, transactions, data, or resources.
Security Testing
Evaluates vulnerabilities, access controls, confidentiality, integrity, and security behaviour.
Usability Testing
Checks how easily users can understand and use the product.
Compatibility Testing
Checks behaviour across browsers, operating systems, devices, networks, or environments.
Reliability Testing
Evaluates consistency of system operation over time.
Recovery Testing
Checks whether the system recovers correctly after crashes, failures, or service interruptions.
Installation Testing
Checks installation, upgrade, uninstall, rollback, and configuration processes.
Accessibility Testing
Checks whether people with different abilities can effectively use the software.
Performance Testing Family
| Testing Type | Main Question |
|---|---|
| Performance | How fast and efficient is the system? |
| Load | How does it behave under expected workload? |
| Stress | What happens beyond expected limits? |
| Endurance | Can it operate reliably for a long time? |
| Scalability | Can capacity increase when demand increases? |
| Volume | How does the system behave with very large amounts of data? |
Black Box, White Box and Grey Box Testing
No Internal-Code Knowledge Required
The tester focuses on inputs, outputs, requirements, and observable behaviour.
Useful techniques include:
- Equivalence Partitioning
- Boundary Value Analysis
- Decision Tables
- State Transition Testing
Internal Structure is Known
Tests are designed using code structure, branches, statements, paths, or internal logic.
Examples:
- Statement coverage
- Branch coverage
- Path-related testing
Partial Internal Knowledge
The tester has some understanding of internal architecture, database, or design but primarily tests from an external perspective.
Software Test Design Techniques
Good testing does not mean entering random values. Test techniques help select a small but effective set of tests from a very large number of possibilities.
1. Equivalence Partitioning
Input data is divided into groups expected to behave similarly.
Example: valid age is 18–60.
Invalid Class
Age < 18Valid Class
18–60Invalid Class
Age > 60Instead of testing every age, representative values are selected from each partition.
2. Boundary Value Analysis
Defects often appear at the boundaries between valid and invalid data.
For valid age 18–60, useful test values include:
3. Decision Table Testing
Decision tables are useful when output depends on combinations of conditions.
| Condition | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Valid Username? | Yes | Yes | No | No |
| Valid Password? | Yes | No | Yes | No |
| Login? | Yes | No | No | No |
4. State Transition Testing
Useful when system behaviour depends on the current state and an event.
Example ATM card:
5. Statement Testing
White-box tests are designed to execute statements in the code.
6. Branch Testing
Tests are designed so decision outcomes and branches are exercised.
7. Error Guessing
The tester uses experience to predict where defects are likely to exist.
Examples:
- Empty fields
- Duplicate submission
- Very long input
- Zero values
- Negative numbers
- Special characters
8. Exploratory Testing
Learning, test design, and test execution happen together. The tester explores the product using knowledge, observation, and feedback.
9. Checklist-Based Testing
Tests are guided by a prepared list of important conditions or quality checks.
Test Scenario vs Test Case
Test Scenario
A high-level statement describing what should be tested.
Example:
Verify user login functionality.Test Case
A detailed set of conditions, inputs, steps, and expected results used to verify specific behaviour.
Example Test Case
LOGIN-001
Verify login using valid credentials
Registered user account exists
Valid username and password
Enter credentials and select Login
Dashboard is displayed
Characteristics of a Good Test Case
- Clear
- Repeatable
- Traceable to requirements
- Contains expected result
- Uses suitable test data
- Avoids unnecessary ambiguity
- Covers important positive and negative behaviour
Positive Testing vs Negative Testing
Positive Testing
Checks behaviour using valid and expected input.
Example: login using the correct password.
Negative Testing
Checks how the system behaves with invalid, unexpected, or prohibited input.
Example: blank password, invalid email, or negative quantity.
Smoke, Sanity, Retesting and Regression Testing
Smoke Testing
A broad, shallow check of important functionality used to determine whether a build is stable enough for more detailed testing.
Example:
- Application opens
- Login works
- Main pages load
- Critical APIs respond
Sanity Testing
A focused check of a limited area after a small change or fix to see whether the affected functionality behaves reasonably.
Retesting / Confirmation Testing
The specific failed test is executed again after a defect is fixed to confirm that the original problem has been corrected.
Regression Testing
Previously working areas are tested after change to identify unintended side effects.
Regression: Did the change break something else?
Alpha Testing vs Beta Testing
| Basis | Alpha Testing | Beta Testing |
|---|---|---|
| Location | Usually controlled by the development organisation | Real or realistic user environment |
| Users | Internal staff and selected representatives | Selected external or real users |
| Timing | Before wider beta/release | Closer to final public release |
| Main Purpose | Find remaining problems in a controlled setting | Collect real-use feedback before full release |
Acceptance Testing Types
User Acceptance Testing
Business users evaluate whether the system supports required work.
Operational Acceptance
Evaluates readiness for operation, deployment, backup, restore, monitoring, and support.
Contract / Regulation Acceptance
Checks contractual, legal, compliance, or regulatory requirements where applicable.
Defect Life Cycle
A defect usually moves through several states from discovery to closure. The exact workflow depends on the organisation.
Other possible states can include:
- Rejected
- Duplicate
- Deferred
- Cannot Reproduce
- Reopened
Severity vs Priority
Severity
Severity describes how serious the defect's impact is on the system.
Example:
Payment service crashes.Priority
Priority describes how urgently the defect should be fixed.
Example:
Company name misspelled on the home page before a major launch.Priority = Urgency
What Should a Good Defect Report Contain?
- Defect ID
- Clear title
- Environment
- Preconditions
- Steps to reproduce
- Actual result
- Expected result
- Severity
- Priority where applicable
- Screenshot, logs, or video evidence
- Build/version information
Important Testing Documents and Testware
Test Plan
Defines scope, objectives, approach, resources, schedule, and control.
Test Scenario
High-level testing condition or user activity.
Test Case
Detailed steps, data, expected result, and conditions.
Test Data
Input values required to execute test cases.
Traceability Matrix
Maps requirements to tests so coverage can be monitored.
Test Summary Report
Summarises execution, coverage, defects, risks, and completion status.
Requirement Traceability Matrix (RTM)
A Requirements Traceability Matrix helps connect requirements with test cases.
| Requirement | Description | Test Case | Status |
|---|---|---|---|
| REQ-01 | User Login | LOGIN-001, LOGIN-002 | Covered |
| REQ-02 | Password Reset | PASS-001 | Covered |
| REQ-03 | Account Lock | LOCK-001 | Covered |
Test Coverage
Coverage indicates how much of a selected test basis has been exercised by tests. Different coverage measures answer different questions.
Requirement Coverage
How many requirements have associated tests?
Statement Coverage
How many executable statements were exercised?
Branch Coverage
How many decision outcomes or branches were exercised?
Common Software Testing Metrics
Example
Suppose:
- 100 test cases planned
- 90 executed
- 72 passed
Execution percentage:
Pass percentage:
Defect Removal Efficiency
Some Software Engineering courses also discuss Defect Removal Efficiency (DRE).
It provides one view of how effectively defects were discovered before release.
Risk-Based Testing
Because exhaustive testing is impossible, testing effort should focus more strongly on areas with greater risk.
A payment failure may deserve more testing than a minor alignment issue because its business impact is much higher.
Test Environment
A test environment is the combination of hardware, software, services, data, network configuration, tools, and other resources required to execute tests.
An environment may include:
- Operating system
- Browser
- Mobile device
- Application build
- Database
- API services
- Network
- User accounts
- Test tools
Software Testing in Agile Development
In Agile development, testing is not normally delayed until the entire application is complete.
Developers, testers, business representatives, and other team members collaborate throughout short development cycles.
Early Testing
Requirements and acceptance criteria are reviewed before implementation.
Continuous Feedback
Testing provides fast information during each iteration.
Whole-Team Quality
Quality is a shared responsibility instead of belonging only to testers.
Shift-Left Testing
Shift-left means moving important testing and quality activities earlier in the software development lifecycle.
Examples:
- Requirement reviews
- Static analysis
- Unit tests
- API tests
- Security checks
- Automated CI tests
Testing in DevOps and CI/CD
Modern delivery pipelines often execute automated checks whenever code changes.
Continuous testing can provide faster feedback, but automation still requires good test design and maintenance.
Manual Testing vs Automation Testing
| Basis | Manual Testing | Automation Testing |
|---|---|---|
| Execution | Performed by a person | Executed using scripts/tools |
| Best For | Exploratory, usability, visual and changing features | Repeated, stable, high-volume tests |
| Initial Setup | Usually lower | Often higher |
| Repeat Execution | Requires repeated human effort | Can run repeatedly once maintained |
| Human Observation | Strong | Limited to programmed checks |
Good Candidates for Automation
- Regression tests
- Repeated API tests
- Stable business flows
- Data-driven tests
- Cross-browser repeated checks
- Continuous integration tests
Tests That May Still Need Human Judgment
- Exploratory testing
- Early changing features
- Visual user experience
- Usability assessment
- One-time investigative tests
Benefits of Test Automation
Fast Repetition
Large regression suites can be executed frequently.
Consistent Execution
The same automated steps can be repeated consistently.
CI/CD Support
Automated tests can provide quick feedback after code changes.
Large Data Sets
Automation can efficiently execute many data combinations.
Risks and Limitations of Automation
Maintenance Cost
Scripts may require updates whenever the application changes.
False Confidence
A green automated suite does not mean every possible problem was tested.
Wrong Tests Run Faster
Automating a poor test design only repeats the weakness more quickly.
Tool Dependency
Tools require skills, environment support, and maintenance.
Maintenance Testing
Testing does not end permanently when software is released.
Maintenance changes may require testing because the system can be modified due to:
- Bug fixes
- New features
- Platform changes
- Database migration
- Security updates
- Operating-system changes
- Third-party service changes
- Retirement or data migration
Maintenance testing usually includes confirmation testing of changes and regression testing of affected areas.
When Should Testing Stop?
Testing cannot normally continue forever.
A project may stop testing when agreed completion criteria are satisfied.
Possible exit criteria include:
- Required test cases executed
- Target coverage achieved
- No unresolved critical defects
- Residual risk accepted
- Required acceptance criteria satisfied
- Release deadline reached with agreed risk decision
Common Software Testing Myths
Myth: Testing Proves There Are No Bugs
Testing can reveal defects but cannot prove complete absence of defects.
Myth: Testing Starts After Coding
Reviews, planning, and analysis can begin much earlier.
Myth: Anyone Can Test Without Skill
Good testing requires analysis, domain knowledge, techniques, communication, and critical thinking.
Myth: Automation Means No Manual Testing
Automation and human testing solve different problems and often work together.
Common Mistakes Students Make
Memory Tricks
Side Effect = Regression
Important Exam Questions
Important 5-Mark Question
- Testing shows presence of defects.
- Exhaustive testing is impossible.
- Early testing saves time and cost.
- Defects cluster together.
- Tests wear out.
- Testing is context dependent.
- Absence-of-errors fallacy.
Important 10-Mark Question
- Define Software Testing.
- Explain why testing is necessary.
- Write major objectives.
- Explain seven testing principles.
- Explain testing process or STLC.
- Explain testing levels.
- Explain functional and non-functional testing.
- Explain black-box and white-box testing.
- Give a suitable example.
Quick Revision Notes
Find information about software quality and risk
No software execution
Software is executed
Building the product right
Building the right product
Individual component
Interfaces between components
Complete system
Business/user acceptance
What the system does
How well the system works
External behaviour
Internal structure
Check side effects
Check defect fix
Impact
Urgency
Build stability check
Test near limits
Quality work begins before final coding
Frequently Asked Questions
What is the main purpose of Software Testing?
The main purpose is to evaluate software, identify defects, reduce risk, provide quality information, and build confidence that the system satisfies its intended requirements and use.
Can testing prove that software has no defects?
No. Testing can demonstrate the presence of defects but cannot normally prove that every possible defect has been removed.
What is the difference between functional and non-functional testing?
Functional testing checks what the software does. Non-functional testing checks quality characteristics such as performance, security, usability, reliability, and compatibility.
What is the difference between smoke and sanity testing?
Smoke testing broadly checks whether important features of a build are stable enough for further testing. Sanity testing is usually a narrower check focused on a particular change or affected functionality.
What is the difference between regression testing and retesting?
Retesting confirms whether a specific defect has been fixed. Regression testing checks whether that change caused new problems in previously working areas.
What are the major test levels?
Modern testing terminology distinguishes component, component-integration, system, system-integration, and acceptance testing. Many university books group them more simply as unit, integration, system, and acceptance testing.
Is automation better than manual testing?
Neither approach replaces the other completely. Automation is excellent for repeatable checks, while manual and exploratory testing remain valuable when human observation, investigation, and judgement are required.
Conclusion
Software Testing is much more than finding bugs after coding. It is a complete quality activity that begins with understanding requirements and continues through planning, reviews, test design, execution, defect management, regression testing, automation, and maintenance.
A good tester does not try to test everything randomly. Testing is planned according to risk, requirements, coverage, business importance, and suitable test techniques.
For exams, remember the complete flow:
Also remember that no single testing type is enough. Static testing can find problems before execution, component testing checks small units, integration testing checks interfaces, system testing checks the complete product, acceptance testing checks business suitability, and non-functional testing evaluates qualities such as performance, security, usability, and reliability.
The strongest testing approach combines different levels, techniques, people, tools, and feedback so that serious problems are discovered as early as practical and the remaining software risk is understood before release.
