Software Testing in Software Engineering: Levels, Types and Techniques

Learning Objective: This article explains the major levels, types and techniques of software testing, including Unit Testing, Integration Testing, Performance Testing, Security Testing, Acceptance Testing, Alpha and Beta Testing, Regression Testing and GUI Testing.

1. Introduction to Software Testing

Software testing is an important activity in software engineering used to evaluate whether software behaves as expected and to identify defects before and after release. Testing is performed at different levels and using different techniques depending on the objective of the test.

The source material used for this article particularly focuses on the different levels of testing and specialized testing techniques used during software development and maintenance.

Testing is performed at different levels because different types of defects can appear at different stages of software development.

2. Levels and Major Areas of Testing

Testing Area	Main Focus
Unit Testing	Testing individual software units or components.
Integration Testing	Testing combined modules and their interfaces.
Performance Testing	Evaluating response time, throughput, resource usage and scalability.
Security Testing	Checking protection of information and system functionality.
Acceptance Testing	Evaluating whether the system is acceptable for delivery and intended use.
Alpha Testing	Testing conducted at the development site before wider release.
Beta Testing	Field testing involving intended users under real-world conditions.
Regression Testing	Checking that changes have not adversely affected existing functionality.
GUI Testing	Testing the graphical user interface and user-visible elements.

3. Unit Testing

Unit Testing is a level of software testing in which individual units or components of software are tested. The purpose is to validate that each unit performs as designed.

A unit is the smallest testable part of software. It generally has one or a few inputs and usually produces a single output.

Key Point: Unit Testing is the first level of testing and is normally performed before Integration Testing.

Who Performs Unit Testing?

Unit testing is generally executed by the developer. The source material identifies Unit Testing with the White Box Testing method.

Example of Unit Testing

Individual program elements such as a function, method, loop or statement can be tested to determine whether they work correctly.

Benefits of Unit Testing

Increases confidence when changing or maintaining code.
Helps detect defects introduced by code changes quickly.
Supports code reuse.
Can make development faster.
Defects found at this level generally cost less to fix than defects found at higher levels.
Makes debugging easier.

These benefits are highlighted in the source material, particularly the lower cost of fixing defects detected during unit testing and the ease of debugging.

4. Drivers and Stubs

Drivers and stubs are temporary software components used particularly during incremental integration testing when some modules are not yet available.

Driver	Stub
Used in Bottom-Up Integration Testing.	Used in Top-Down Integration Testing.
Calls the module under test.	Is called by the module under test.
Simulates the behavior of an upper-level module that is not yet integrated.	Simulates the behavior of a lower-level module that is not yet integrated.

Driver Example

Suppose modules B and C are ready, but module A, which calls functions from B and C, is not ready. A developer can create a dummy piece of code representing module A. This dummy component is called a driver.

Stub Example

Suppose module A is ready, but modules B and C called by A are not ready. Dummy modules representing B and C can be created to provide the required outputs. These dummy modules are called stubs.

TOP-DOWN APPROACH Module A ↓ [STUB] ↓ Module B / C BOTTOM-UP APPROACH [DRIVER] ↓ Module B / C ↓ Module A

Importance of Stubs and Drivers

They substitute for missing or unavailable modules.
Different modules may require different stubs or drivers.
Developers and unit testers may be involved in their development.
They are commonly used during incremental integration testing.

5. Integration Testing

Integration Testing is a level of software testing in which individual units are combined and tested as a group.

The objective is to test the integration and interfaces between components and their interactions with other parts of the system, such as operating systems, file systems, hardware or other systems.

Unit Testing asks: Does the individual unit work?
Integration Testing asks: Do the combined modules work together?

Integration Testing Approaches

Incremental Integration
Non-Incremental / Big-Bang Integration
Top-Down Integration
Bottom-Up Integration
Bi-Directional / Sandwich Integration

5.1 Incremental Integration

In the incremental approach, two or more logically related modules are joined and tested. Additional related modules are then added and tested until all modules have been integrated successfully.

Stubs and drivers can be used to simulate data communication with modules that are not yet available.

5.2 Non-Incremental or Big-Bang Integration

In the non-incremental approach, also known as Big-Bang Testing, all units are linked together at once and the complete system is then tested.

Limitation: When an error is found in Big-Bang Integration Testing, isolating the source of the error can be difficult because individual interfaces have not been verified incrementally.

5.3 Top-Down Integration

Top-Down Integration follows the design hierarchy from the top toward the lower levels. Testing starts with the main or high-level module and progresses toward submodules.

If a required lower-level module is unavailable, a temporary program called a stub is used.

Depth-First Integration

All modules on a major control path of the design hierarchy are integrated first. The process then continues with other paths.

Breadth-First Integration

All modules directly subordinate to a particular level are integrated first, moving horizontally across the design hierarchy.

Top-Down Integration Procedure

Start with the top or initial module.
Substitute stubs for unavailable subordinate modules.
Test the top module.
Replace stubs one at a time with actual modules.
Test the newly integrated environment.
Perform regression testing when appropriate.
Repeat the process through the design hierarchy.

Advantages of Top-Down Integration

Useful when major flaws occur toward the top of the program.
Representation of test cases becomes easier after I/O functions are added.
An early skeletal program can be demonstrated.

Limitations of Top-Down Integration

Stub modules must be produced.
Stub modules may become complicated.
Test conditions can be difficult to create before I/O functions are available.
Observation of test output may be difficult.

5.4 Bottom-Up Integration

In Bottom-Up Integration, testing begins with lower-level modules and proceeds toward higher-level modules.

If the main module is not yet available, a temporary program called a driver is used to simulate the main module.

Advantages

Useful when major flaws occur toward the bottom of the program.
Test conditions are easier to create.
Observation of test results is easier.

Limitations

Driver modules must be produced.
The complete program does not exist until the final module is added.
Critical high-level modules may be tested relatively late.
An early prototype may not be possible.

5.5 Bi-Directional / Sandwich Integration

Bi-Directional Integration combines the Top-Down and Bottom-Up approaches. It is also referred to as Sandwich Integration.

The approach can test higher-level and lower-level portions of the system in parallel, using stubs and drivers where necessary.

Advantages

Useful for very large projects with several subprojects.
Top-down and bottom-up testing can proceed according to the development schedule.
Combines the benefits of both approaches.

Disadvantages

Can require significant testing resources.
May not be suitable for smaller systems with highly interdependent modules.

6. Unit Testing vs Integration Testing

Unit Testing	Integration Testing
Tests individual units.	Tests combined modules.
Focuses on the behavior of individual modules.	Focuses on interactions and interfaces between modules.
Typically performed by developers.	Often performed by a test team.
Defects are generally easier to isolate.	Defects can be more difficult to isolate.
Usually starts from module specifications.	Focuses on interface specifications and module interaction.
Does not necessarily verify external dependencies.	Verifies interaction with integrated dependencies.
Maintenance is generally less expensive.	Maintenance can be more expensive.

7. Performance Testing

Performance Testing evaluates whether software performs adequately under its expected workload.

Important performance characteristics include:

Response Time
Reliability
Resource Usage
Scalability
Throughput

Important: The source material distinguishes performance testing from ordinary defect detection by emphasizing the identification and elimination of performance bottlenecks.

Performance Testing Objectives

Parameter	Meaning
Speed	Determines whether the application responds quickly.
Scalability	Determines the maximum user load the application can handle.
Stability	Determines whether the application remains stable under varying loads.
Response Time	Measures how quickly the system responds to requests.
Throughput	Measures the amount of work or transactions handled in a given period.
Resource Utilization	Examines CPU, memory, disk I/O and network I/O consumption.

7.1 Load Testing

Load Testing evaluates the system while the workload is gradually increased, up to an expected or threshold level.

The load may be increased by increasing:

Concurrent users
Transactions
Data volume
Duration of operation

The main purpose is to observe response time and system behavior under expected heavy workload.

Load Testing = Testing software under expected or increasing workload.

7.2 Stress Testing

Stress Testing evaluates system stability when resources are insufficient or when workload exceeds expected limits.

Examples of resource constraints include:

Low memory
Low disk space
Limited CPU resources
High numbers of concurrent users
Other constrained system resources

Stress testing is used to explore the upper limits of system capacity and observe how the system behaves under less-than-ideal conditions.

Load Testing → Expected workload
Stress Testing → Beyond expected or constrained conditions

8. Security Testing

Security Testing determines whether an information system protects data and maintains intended functionality.

The source material identifies six basic security principles:

Confidentiality Integrity Authentication Authorization Availability Non-Repudiation

Confidentiality

Confidentiality protects information from disclosure to unauthorized parties.

Integrity

Integrity protects information from unauthorized modification.

Authentication

Authentication involves confirming the identity of a person, system or source.

Authorization

Authorization determines whether a requester is permitted to receive a service or perform an operation.

Availability

Availability ensures that information and services are available to authorized users when required.

Non-Repudiation

Non-repudiation provides assurance concerning the origin and receipt of a message or transaction so that a party cannot later deny the relevant action.

Examples of Security Problems

A Student Management System is insecure if one branch can improperly edit another branch's data.
An ERP system is insecure if an unauthorized data-entry role can generate restricted reports.
An online shopping system requires protection of customer payment information.
Applications should not expose users' actual passwords through database queries or interfaces.

9. Client-Server Testing

Client-Server Testing is commonly associated with two-tier applications where a front-end communicates with a back-end.

Typical Components

Front End: Forms, reports and user interaction.
Back End: Database or data management system.

Examples of database technologies mentioned in the source include MS Access, SQL Server, Oracle, Sybase, MySQL and Quadbase.

Testing Areas

User Interface Testing
Manual Testing
Functional Testing
Compatibility Testing
Configuration Testing
Intersystem Testing

10. GUI Testing

GUI Testing is the testing of the Graphical User Interface of an application.

The GUI contains visible elements such as:

Menus
Buttons
Icons
Toolbars
Menu bars
Dialog boxes
Windows
Text fields
Lists
Links

GUI Testing Guidelines

Check screen validations.
Verify navigation.
Check usability conditions.
Verify data integrity.
Verify object states.
Verify date and numeric field formats.

GUI Quality Considerations

GUI testing considers not only functionality but also user-visible characteristics such as layout, colors, fonts, font sizes, labels, text boxes, captions, buttons, lists, icons, links and content.

The source material also emphasizes usability factors such as screen layout, navigation, readable reports and appropriate presentation of controls.

Advantages of Good GUI Testing

Improves the look and feel of the application.
Supports a better user experience.
Improves consistency of screen layouts.
Can improve usability and acceptability.

11. Acceptance Testing

Acceptance Testing evaluates whether a system is acceptable for delivery and whether it complies with business requirements.

The source material describes acceptance testing as a level of testing generally performed after System Testing and before the system is made available for actual use.

Acceptance Criteria

Acceptance Consideration	Examples
Functional	Correctness and completeness
Data	Data integrity and data conversion
User Experience	Usability
Performance	Performance and timeliness
Security	Confidentiality and availability
Deployment	Installability and upgradability
Scalability	Ability to accommodate growth
Documentation	Availability and completeness of documentation

Types of Acceptance Testing

User Acceptance Testing
Operational Acceptance Testing
Contract Acceptance Testing
Compliance Acceptance Testing

User Acceptance Testing

User Acceptance Testing focuses primarily on functionality and validates the fitness-for-use of the system from the business user's perspective.

Operational Acceptance Testing

Operational Acceptance Testing validates whether the system meets operational requirements. It may include backup and restore, disaster recovery, maintenance activities and security checks.

Contract Acceptance Testing

Contract Acceptance Testing is performed against acceptance criteria defined in a software development contract.

Compliance Acceptance Testing

Compliance Acceptance Testing evaluates the system against applicable regulations, legal requirements or safety requirements.

12. Alpha Testing

Alpha Testing is conducted by a skilled testing team at the development site before the software is released more widely.

The source material describes two phases:

Initial testing by in-house developers, often using debugging facilities.
Further testing by software QA staff in an environment similar to intended use.

Advantages of Alpha Testing

Can uncover defects missed during previous testing.
Provides additional information about product usage and reliability.
Helps identify risks before launch.
Supports preparation for customer support.
Can reduce maintenance costs by identifying defects before wider release.

Limitations

Not all functionality may be tested.
Testing may focus primarily on defined business requirements.

13. Beta Testing

Beta Testing is also referred to as field testing. It involves providing the software to intended users who use it under real-world conditions.

The purpose is to identify issues from the user's perspective that may not have been discovered by the development and testing teams.

Key Point: Beta testing provides an opportunity to obtain feedback from users before a general release.

14. Alpha Testing vs Beta Testing

Alpha Testing	Beta Testing
Performed at the developer's site.	Performed at the end user's site or environment.
Conducted in a controlled environment.	Conducted under real-world conditions.
Developers and dedicated testers are involved.	Intended users participate.
Performed before wider release.	Used as pre-release field testing.
Developer can make changes relatively quickly.	Feedback is provided by users through appropriate channels.
Can involve white-box and black-box approaches.	Typically emphasizes black-box testing.

15. Regression Testing

Regression Testing confirms that a recent program or code change has not adversely affected existing functionality.

Previously executed test cases may be selected and re-executed after changes to verify that existing functionality continues to work.

When is Regression Testing Required?

Requirements are changed.
A new feature is added.
A defect is fixed.
A performance issue is fixed.
Code is modified.

Regression Testing Strategies

Retest All

All tests in the existing test suite are executed again. This can require significant time and resources.

Regression Test Selection

Instead of running the entire test suite, a relevant subset of test cases is selected. Reusable and obsolete test cases can be identified.

Prioritization of Test Cases

Test cases can be prioritized according to business impact, criticality and frequency of use to reduce the regression test suite.

Effective Regression Test Selection

Test cases associated with frequent defects.
User-visible functionality.
Core features of the product.
Functionality that has undergone recent changes.
Integration test cases.
Complex test cases.
Boundary-value test cases.
Samples of successful and failure test cases.

Regression Testing Tools

The source material identifies tools such as:

Selenium – used for automating web applications.
Quick Test Professional (QTP) – an automation tool for functional and regression testing.
Rational Functional Tester (RFT) – an automation tool used for software application testing and regression testing.

16. Comparison of Important Testing Techniques

Testing Type	Primary Objective
Unit Testing	Verify individual software units.
Integration Testing	Verify interactions between modules.
Performance Testing	Evaluate performance characteristics under workload.
Security Testing	Evaluate protection of information and system functionality.
Acceptance Testing	Determine whether the system is acceptable for delivery.
Alpha Testing	Conduct controlled pre-release testing at the development site.
Beta Testing	Obtain feedback through real-world user testing.
Regression Testing	Verify that changes have not broken existing functionality.
GUI Testing	Verify the application's graphical user interface and usability-related elements.

17. Software Testing – Overall View

SOFTWARE UNIT │ ▼ UNIT TESTING │ ▼ INTEGRATION TESTING │ ┌─────────┼─────────┐ ▼ ▼ ▼ TOP-DOWN BOTTOM-UP SANDWICH │ │ │ └─────────┼─────────┘ ▼ SYSTEM / OTHER TESTING │ ┌───────────┼───────────┐ ▼ ▼ ▼ PERFORMANCE SECURITY ACCEPTANCE │ │ │ └───────────┼───────────┘ ▼ PRE-RELEASE │ ┌──────┴──────┐ ▼ ▼ ALPHA BETA │ │ └──────┬──────┘ ▼ RELEASE │ ▼ REGRESSION TESTING AFTER FUTURE CHANGES

18. Practical Example: Student Management System

Consider a Student Management System containing modules such as Admission, Student Records, Examination and Reports.

Testing	Example
Unit Testing	Test the function that calculates a student's percentage.
Integration Testing	Verify that Admission data is correctly available to the Examination module.
Performance Testing	Check system response when many students access results simultaneously.
Security Testing	Ensure unauthorized users cannot modify examination records.
Acceptance Testing	Verify that the system satisfies institutional requirements.
Alpha Testing	Conduct controlled testing by the development/testing team.
Beta Testing	Allow selected real users to use the system and provide feedback.
Regression Testing	After adding a new report, verify that existing reports still work.
GUI Testing	Verify menus, buttons, navigation, labels and screen layout.

19. Quick Revision for Students

Question	Answer
What is Unit Testing?	Testing individual software units or components.
What is a Driver?	A temporary component that calls the module under test, commonly used in Bottom-Up Integration.
What is a Stub?	A temporary component called by the module under test, commonly used in Top-Down Integration.
What is Big-Bang Integration?	Integrating all components simultaneously and then testing the complete system.
What is Performance Testing?	Testing software performance under expected or varying workloads.
What is Stress Testing?	Testing behavior under excessive workload or constrained resources.
What is Security Testing?	Testing protection of information and intended system functionality.
What is Acceptance Testing?	Testing whether the system is acceptable for delivery and intended use.
What is Alpha Testing?	Controlled pre-release testing at the development site.
What is Beta Testing?	Field testing involving intended users under real-world conditions.
What is Regression Testing?	Re-executing selected tests to ensure changes have not adversely affected existing functionality.
What is GUI Testing?	Testing the graphical user interface and its visible interaction elements.

20. Conclusion

Software testing is a systematic activity that supports software quality by examining individual components, interactions between components, system behavior, performance, security, acceptance and user-facing interfaces.

Unit Testing verifies individual units, while Integration Testing verifies the interaction between modules. Performance Testing evaluates characteristics such as response time, throughput, resource utilization and scalability. Security Testing examines principles including confidentiality, integrity, authentication, authorization, availability and non-repudiation.

Acceptance Testing evaluates whether the software is acceptable for delivery. Alpha and Beta Testing provide different forms of pre-release evaluation, while Regression Testing ensures that software changes do not unintentionally break existing functionality. GUI Testing focuses on the interface through which users interact with the application.

Final Takeaway: Effective software testing is not limited to finding programming errors. It examines software from multiple perspectives—component correctness, integration, performance, security, usability, acceptance and continued reliability after change.

Educational Source Note

This article has been structured and formatted from the provided educational material on software testing. The terminology, classifications, examples and comparisons have been retained and organized into a blog-friendly format.

Recommended use: Software Engineering, Computer Engineering, Computer Technology, Diploma Engineering and undergraduate classroom reference.

Blog Tags:
Software Engineering Software Testing Unit Testing Integration Testing Performance Testing Security Testing Acceptance Testing Alpha Testing Beta Testing Regression Testing GUI Testing Computer Engineering Computer Technology