What is Integration Testing?
Testing the data flow between two or more modules is called Integration Testing.
It focuses on checking data communication between multiple modules.
It is a White Box Testing technique.
It is conducted:
- By the tester at the application (UI) level.
- By the developer at the coding level.
Types of Integration Testing (Incremental & Big Bang)
Incremental Testing
Testing is done by integrating two or more logically related modules.
The application is then tested for proper functioning.
Other related modules are integrated incrementally and tested.
Stubs and Drivers are the dummy programs used to facilitate this activity.
Incremental testing has two approaches:
- Top-Down
- Bottom-Up
Non-Incremental Testing
The Big Bang approach, where modules are integrated together.
Top-Down vs Bottom-Up
Top-Down
- We first test the higher-level (calling) modules, such as the UI or main controller.
- Then we integrate the lower-level modules one by one.
- If a lower-level module the higher one calls isn't ready, we replace it with a dummy Stub that returns fixed responses.
Bottom-Up
- We first test the lower-level modules, such as utilities or data access.
- Then we integrate the higher-level modules that use them.
- If the higher-level module that calls them isn't ready, we write a dummy Driver that calls the lower module and passes it test data.
| Top-Down | Bottom-Up | |
|---|---|---|
| Order | Higher-level modules first | Lower-level modules first |
| Dummy used | Stub — replaces a missing lower-level (called) module | Driver — replaces a missing higher-level (calling) module |
| Example | Checkout UI tested with a stub payment service that always returns "APPROVED" | Tax calculator tested with a driver class that calls it with sample orders |
| Strength | Main flows and UI checked early | Core logic checked thoroughly early |
An easy way to remember it: a stub is called (it sits below), a driver calls (it sits above). Modern teams do the same thing with mock servers and test doubles — for example a WireMock stub for a payment API; see Mock Servers.
What is System Testing?
We test the application with each and every module, i.e., End-to-End Testing.
It tests the application's overall functionality against client requirements.
It is a Black Box Testing technique conducted by the testing team.
It starts after:
- Component (Unit) Testing
- Integration Testing
are completed.
In System Testing, we perform both:
System Testing Focuses On
- User Interface Testing (GUI)
- Usability Testing
- Functional Testing
- Non-Functional Testing
What is Pilot Testing?
Pilot testing verifies a component of the system, or the entire system, under real-time operating conditions.
Its purpose is to evaluate:
- Feasibility
- Time
- Cost
- Risk
- Performance
It is done exactly between UAT and Production.
A select group of end users tests the system and provides feedback before full deployment.
Alpha Testing vs Beta Testing
Alpha Testing
A type of UAT done by one of the organization's employees to identify bugs before releasing the software to real users or the public.
Beta Testing
A type of UAT done by end users in a real environment.
It is the final test before shipping the product.
Direct feedback from customers is a major advantage.
Alpha Testing
Performed By
- Internal employees (testers)
Location
- Developer's site
Reliability, Security, Robustness
- Not performed
Techniques
- Both White Box and Black Box Testing
Issue Handling
- Critical fixes addressed by developers immediately
Beta Testing
Performed By
- Clients / End users (not employees)
Location
- Client location / End-user environment
Reliability, Security, Robustness
- Checked during Beta Testing
Techniques
- Black Box Testing (Real-world usage)
Issue Handling
- Feedback implemented in future versions
Alpha & Beta Entry/Exit Criteria
Entry Criteria for Alpha Testing
- SRS or BRS is ready.
- Test cases for all requirements.
- Testing team with good knowledge of the software application.
- Test lab environment setup.
- QA build ready for execution.
- Test management tool for uploading test cases and logging defects.
- Traceability Matrix ensuring each design requirement has at least one test case.
Exit Criteria for Alpha Testing
- All test cases have been executed and passed.
- All severity issues are fixed and closed.
- Delivery of the test summary report.
- Confirmation that no additional features can be included.
- Sign-off on Alpha Testing.
Entrance Criteria for Beta Testing
- Sign-off document on Alpha Testing.
- The environment is ready to release the application to the public.
Application Under Test (AUT)
AUT is also known as Pre-Production Testing.
It is performed by end users and testers to validate the application's functionality after successful acceptance testing.
It is formal testing conducted to determine whether an application is developed according to the requirements.
Monkey, Ad-hoc & Gorilla Testing
Monkey Testing
Performed randomly with no predefined test cases.
Testers may not know:
- What the system is about.
- Its purpose.
The objective is to check for system crashes.
Ad-hoc Testing
Performed without planning or documentation.
There are:
- No test cases.
- No SRS.
However, the tester has knowledge of the application.
Testers must understand the system well before testing.
The objective is to randomly divide the system into subparts and check their functionality.
Gorilla Testing
Performed on a few selected modules with a few test cases.
The objective is to check whether the module is working properly or not.
How Monkey Testing Differs from Ad-hoc Testing
Ad-hoc Testing
- The tester knows the application.
- A group of testers tests whatever they think is required based on their knowledge of the application.
Monkey Testing
- The tester has little knowledge of the application.
- Testers do not follow any specific path.
- They test randomly by clicking on objects and entering invalid data to see whether the application returns an error.
Use Case
A use case is a description of how a user interacts with a system or product.
It is usually prepared by business analysts (sometimes with product owners or architects) from the customer's requirements. Testers use use cases to derive end-to-end test scenarios — each main and alternative flow becomes one or more test cases.
It is a list of actions the actor takes while interacting with the system to achieve a goal.
Here, an actor can be:
- A human.
- An external system.
Use cases describe the system's functional requirements.
Where Each Level Fits: One Feature, Four Levels
| Level | Who | Example for "apply a coupon at checkout" |
|---|---|---|
| Unit | Developers | The discount calculation returns 90 for 100 with 10% off |
| Integration | Developers and testers | The cart service calls the coupon service and receives the discount |
| System | Test team | End to end: add items, apply coupon, pay, receive a confirmation email with the right total |
| Acceptance (alpha/beta/UAT) | Business users and customers | The marketing team confirms the campaign coupons work as they planned |
Practise choosing the right kind of testing for realistic situations in the Manual Testing Simulator.
From Real Projects
Before any automation, my work on each project started with the requirement: understanding the business flow, identifying scenarios, writing test cases and getting them reviewed. On Canolog, where sales, inventory, finance, service and parts all connect, that analysis is what found the gaps between modules. Execution was tracked in TestRail and defects in Jira. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. Integration problems hide between modules, so test the handovers, not just each module on its own.
📚 Official documentation: ISTQB Glossary of testing terms
FAQs
1. What is Integration Testing?
Testing the data flow and communication between two or more modules.
It is a White Box Testing technique performed by:
- Testers at the UI level.
- Developers at the code level.
2. What is the difference between Top-Down and Bottom-Up Integration Testing?
Top-Down
- Tests higher-level modules first.
- Uses Stubs for missing lower-level modules.
Bottom-Up
- Tests lower-level modules first.
- Uses Drivers for missing higher-level modules.
3. What are Stubs and Drivers?
Dummy programs used in Integration Testing.
- A Stub stands in for a missing called (lower) module in Top-Down testing.
- A Driver stands in for a missing calling (higher) module in Bottom-Up testing.
4. What is System Testing?
End-to-End Black Box Testing of the application's overall functionality against client requirements.
It is performed after:
- Unit Testing
- Integration Testing
It covers:
- GUI Testing
- Usability Testing
- Functional Testing
- Non-Functional Testing
5. What is the difference between Alpha Testing and Beta Testing?
Alpha Testing
- Conducted by internal employees.
- Performed at the developer's site.
Beta Testing
- Conducted by real end users.
- Performed in the user's environment.
- Checks reliability, security, and robustness.
- Feedback is used to improve future versions.
6. What is Pilot Testing?
Testing a component or the whole system under real-time conditions.
It is conducted between UAT and Production, where a select group of users provides feedback before full deployment.
7. How is Monkey Testing different from Ad-hoc Testing?
The tester knows the application and tests based on their knowledge.
Monkey Testing
The tester has little knowledge of the application and tests randomly using invalid inputs to trigger crashes.
8. What is a Use Case?
A description of how a user (actor) interacts with a system to achieve a goal.
It is used to describe the functional requirements of the system.
