Testing at different levels is performed throughout the life cycle of software development and maintenance. The level of testing determines what tests are performed on: a single module, a group of modules or a system as a whole. Conducting testing at all levels of the system is the key to the successful implementation and delivery of the project.

Testing Levels

1. 1. Component Testing or Unit Testing

1. 1. Integration Testing

1. 1. System Testing

1. Acceptance Testing

Component or Unit Testing

Component (Unit) Testing checks functionality and looks for defects in parts of the application that are accessible and can be tested separately (program modules, objects, classes, functions, etc.). Typically, component testing is done by calling code that needs to be tested and supported by development environments such as frameworks for unit testing or debugging tools. All found defects are usually corrected in the code without formal description in the Bug Tracking System.

One of the most effective approaches to component (module) testing is the preparation of automated tests prior to the beginning of the basic coding (development) of the software. This is called a test-driven development or a test first approach. In this approach, small pieces of code are created and integrated, in front of which tests run before the beginning of the encoding are run. The development is carried out until all the tests have been successfully passed.

The difference between component and unit testing

In essence, these levels of testing are the same, the only difference is that in component testing, real objects and drivers are used as parameters of functions, and in concrete testing – specific values.

Integration Testing

Integration testing is intended to test the connection between components, as well as interaction with various parts of the system (operating system, equipment or communication between different systems).

Levels of integration testing:

• Component Integration testing

Verifies the interaction between the components of the system after the component testing.

• System Integration Testing

Verifies the interaction between different systems after system testing.

Approaches to integration testing

• Bottom Up Integration

All low-level modules, procedures, or functions are assembled and then tested. After that, the next level of modules is assembled for integration testing. This approach is considered useful if all or almost all modules of the developed level are ready. Also, this approach helps to determine the level of availability of the application based on the test results.

• Top Down Integration

Initially, all high-level modules are tested, and gradually low-level ones are added one by one. All lower-level modules are simulated with plugs with similar functionality, then they are replaced with real active components as they become available. So we are testing from top to bottom.

• “Big Bang” Integration

All or almost all the developed modules are assembled together as a complete system or its main part, and then integration tests are conducted. This approach is very good for saving time. However, if the test cases and their results are recorded incorrectly, the integration process itself will be greatly complicated, which will become an obstacle for the testing team when achieving the main goal of integration testing.

System Testing

The main task of system testing is to check both functional and non-functional requirements in the system as a whole. Defects such as incorrect use of system resources, non-compliant combinations of user-level data, incompatibility with the environment, unintended use scenarios, missing or incorrect functionality, inconvenience of use, etc. are detected. To minimize the risks associated with the behavior of the system in a particular environment, during testing, it is recommended that the environment be used as close as possible to that for which the product will be installed after issue.

There are two approaches to system testing:

• requirements based

For each requirement, test cases (test cases) are written to verify compliance with this requirement.

• use case based

Based on the idea of how to use the product, cases of using the system (Use Cases) are created. For a specific use case, one or more scenarios can be defined. To test each scenario, test cases are written, which must be tested.

Acceptance Testing

A formal testing process that verifies that the system meets the requirements and is conducted with the aim of:

• • whether the system satisfies the acceptance criteria;

• making a decision by the customer or another authorized person accepts the application or not.

Acceptance testing is performed based on a set of typical test cases and scenarios developed based on the requirements for this application.

The decision to conduct acceptance testing is taken when:

• • the product has reached the required level of quality;

• the customer is acquainted with the Product Acceptance Plan or other document describing the set of activities related to the acceptance testing, the date, the responsible, etc.

The acceptance testing phase lasts until the customer makes a decision to send the application for revision or issuance of the application.

In the next article we will consider the topic of Test artifacts. Stay with us!