There are 4 test levels including:
- Component testing
- Integration testing
- System testing
- Acceptance testing
Test level
Test levels have the following characteristics:
- Specific Objects
- Test basis, referenced to derive test cases
- Test object
- Typical defects and failures
- Specific approaches and responsibilities
- A suitable test environment is required
The main objective of the Test level:
- Reduce risk
- Verify whether the behavior is functional and non-functional
- Build trust that changes don’t break existing components or systems
- Finding fault
- Prevent errors arising at higher test levels
1. Component testing
Component testing, also known as unit testing, aims to verify that each unit of software is developed as designed.
Objective
Focus on components, modules that can be tested separately.
Special
Execute separately from the rest of the system, requiring emulators, virtual services, stubs, drivers.
Test type
- Functional-testing
- Non-funtional
Test basis
- Detailed design
- Code
- Data model
- Component specifications
- Test objects
Typical test objects
- Component, unit or module code and data structure
- Classes
- Database modules
Environment Development environment with framework, debug tool,
Typical defect and failure
- Incorrect functionality (for example, not described in design analysis document)
- Data flow problem
- The code and logic are incorrect
- Errors are usually corrected as soon as they are found
Responsibilites
Developer
Approach
Accessible through Test-first model method – Test driven development (TDD) means to test first and code later.
2. Integration testing
Objective
Focus on the interaction and interface between components or systems.
Special
2 different levels of integration testing are:
- Component integration testing – Component integration testing
- System integration testing – System integration testing
Test type
- Functional testing
- Non-funtional testing
Test basis
- Software and system design – Software and system design
- Sequence diagrams – Sequence diagrams
- Interface and communication protocol specifications – Interface and protocol
- Use cases
- Architecture at component or system level – Architecture at component or system level
- Workflows – Workflow
- External interface definitions – External interface definitions
Typical test objects
- Subsystems – Subsystem
- Databases
- Infrastructure- Infrastructure
- Interfaces – Interface
- APIs
- Microservices
Environment Specific environment: eg staging environment, develop, ..
Typical defect and failure
- The message structure is inconsistent between systems
- The data is incorrect, data is missing, or data encoding is incorrect
- The sequence or timing of the cycles is incorrect
- Error in communication between components
- Communication errors were not handled or handled incorrectly between components
- Incorrect assumptions about the meaning, unit or marginal value of data transmitted between components
- Failure to comply with mandatory security regulations
Responsibilites
Developer and tester
Approach 
The larger the scope of integration, the harder it is to separate errors for specific components or systems.
- Big-bang integration
- Incremental integration
3. System testing
Objective
Focus on the behavior and capabilities of an entire system or product.
Special
There are almost no documents based on experience
Test type
- Functional testing
- Non-funtional testing
Test basis
- Documentation of software and system requirements (functional and non-functional)
- Risk analysis report
- Use cases
- User history and analysis
- System behavior model
- Instructions for using the system
Typical test objects
- Application to use
- Hardware system and software
- Operating systems
- System under test (SUT)
- System configuration and configuration data
Environment Compatible with production environments
Typical defect and failure
- The calculation is incorrect
- Incorrect or unexpected system functions or non-functional behaviors
- Incorrect control and / or data flow in the system
- Failure to properly implement and not completely function until the end
- System error does not work properly in production environment.
- System error does not work as described in the user system manual.
Responsibilites
Independent test tester The t techniques are best suited for the aspect (s) of the system being tested
Approach
- Black box testing
- According to my experience
4. Acceptance testing
Objective
- Build trust in the quality of the entire system
- Confirm that the system is complete and will work as expected
- Verify that the functional and non-functional behaviors of the system are the specified forms of acceptance acceptance
Test basis
- Business processes
- User or business requirements
- Regulations, legal contracts and standards
- Use cases
- System requirements
- System or user documentation
- Installation procedures – Risk analysis reports
Typical test objects
- The system is testing
- System configuration and configuration data
- Business process for a fully integrated system
- Recovery systems and hot sites (to check ongoing resilience and disaster recovery)
- Sample report
- Production data is available and converted
Environment Specific environment: eg staging environment, develop, ..
Typical defect and failure
- System workflow does not meet user or business requirements – Business rules are not correctly implemented
- The system does not meet contract or regulatory requirements
- Non-functional errors such as security holes, inadequate performance at high load or improper operation on supported platforms
Responsibilites
- Customer
- User
Approach
- Functional
- Non-function
- Black box
- White box
Refer:
istqb.org
https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.qualitylogic.com%2F2018%2F01%2F11%2Fcloser-look-integration-testing%2F&psig=AOvVaw2QzIEhmZRr6WBBs8FWOT_U&ust=15903730 vfe & ved = 0CA0QjhxqFwoTCLjVl8-3y-kCFQAAAAAdAAAAABAm