To enhance the quality of software testing and to produce a unified testing methodology applicable across several projects, the testing process could be abstracted to different test levels.

In this article, we will focus on the different testing levels and their significance.

• What are the levels of software testing?
• Attributes of the Test Levels

What are the different test levels in software testing?

Many different test levels help verify the behavior and performance of software testing. These test levels are designed to recognize missing areas and reconciliation between the phases of the software development life cycle. In SDLC models, there are characterized phases such as the gathering of requirements, analysis, design, coding or execution, testing, and implementation. All these phases go through the process of software test levels.

The software is tested at different levels. Initially, the individual units are tested alone and once they are tested, the interfaces established between them are integrated and checked. After this, all software is tested to ensure that the output produced conforms to the user's requirements.

There are mainly four levels of testing. We will briefly explain all these levels and a detailed description of each of these levels will be taken up as separate articles.

Component or Unit Testing:

Unit tests are performed to test individual software units. Since the software comprises several units/modules, error detection in a single unit is simple, cost-effective and less time-consuming. The Unit test ensures that the functional and the non-functional behavior of the component is designed as per specification. Below are some of the key considerations for Unit tests:-

• Each component is tested in isolation from the rest of the System.
• Component testing is usually performed by developers before handing over the code to QA team.
• Component testing is usually done in the developers local environment before the code is propagated to higher environments.
• Defects logged during unit testing is fixed there and then, and there is no formal defect management process that is followed for unit testing defects.

Integration Testing:

Integration testing is carried out once Unit testing is complete. It focuses on the interaction between the components or systems. Integration testing can be component integration testing or System Integration testing.

• Component Integration Testing: It focuses on the interaction between the components of a System. E.g. for a Flipkart website, the interaction between Order Details page and the Cart page can be classified as Component Integration testing.
• System Integration Testing: It focuses on the interaction between the systems or micro-services. Typically, all the third-party integrations are covered under System Integration testing. E.g. Flipkart product details page has an option to share the product via Twitter and Facebook. Both of these are third-party applications and this integration with Twitter and Facebook comes under System Integration Testing. Some of the key considerations for Integration testing are listed below :
  • Integration testing ensures that the functional and non-functional behavior of the interfaces is working as per design.
  • Interfaces, API's and micro-services are typically covered in integration testing.
  • Integration testing is carried out as soon as two interacting components are ready to test, without waiting for the entire system to be ready. This ensures early detection of defects and also helps in isolating the defects to particular component interaction.
  • Component Integration testing is often the responsibility of developers though the testing team can equally participate. System Integration testing is solely the responsibility of the testing team.

System Testing:

Once Integration testing is completed successfully, we move on to the next level of testing, which is called System testing. IEEE defines the system tests as "A testing performed on a complete and integrated system to check the system's compliance with its specific requirements". System testing can be classified as :

• Functional System testing: This ensures that the system is performing all the functions that were specified in the software requirement specification. E.g. On an Amazon website, a user should be able to search a product, add to cart, and finally place an order using a debit/credit card.
• Non-Functional System testing: This ensures that the non-functional aspects of the system are working to acceptable standards. E.g. On an amazon website, the search results should be shown to the user within 3 seconds. The cart page should not crash on a simultaneous user load of 50k users. Some of the types of Non-functional requirements are :
  • Performance - System performs to industry standards.
  • Load Handling - Performance of system under increased load
  • Recovery - How the system recovers on failures. E.g. What happens when Payment gateway goes down.
  • Reliability - Ability of software to repeatedly perform its function consistently with time.
  • Usability - Ease with which a user can perform desired functions

Some of the considerations for System testing are as follows :

• System testing is done from a user perspective while component testing and integration testing is done from a technical perspective.
• System testing is often performed in a dedicated environment that is close to production in terms of hardware and software configurations.
• Stubs and mock services are not used in System testing.
• System testing usually takes more time than Component and Integration testing.

Acceptance Testing:

Acceptance testing is performed after System testing is successfully executed. Acceptance testing is done to provide the end-users the confidence that the system will work according to their expectations. While all the other levels (Component, Integration, and System) are executed by the software producers, acceptance testing is the only level that is carried out by the customers and end-users. The amount of acceptance testing required depends on product risk, and also how much testing has been successfully executed in previous levels.

Acceptance testing could be of various types, some of the key ones are listed below.

• Contract Acceptance Testing: In some of the projects, the criteria for accepting a product is predefined, and documented as a contract. The acceptance testing is carried out to check if the software complies with the documented criteria. E.g. A train ticket booking software could have acceptance criteria that it should support simultaneous bookings of up to 1000 users per minute. So simply ensuring that the software can book the ticket will not result in the acceptance of software. The software has to prove that it can take up a minimum of 1000 bookings per minute without any performance degradation.
• Regulation Acceptance Testing: The software must meet regulatory standards of different countries and industries before it is released to production. E.g. US, UK has strict laws that a website should adhere to accessibility standards.
• User Acceptance Testing: This testing is mainly carried out by end-users. There could be different user groups who will use the software, and we need to ensure that each group is represented in UAT. E.g. A ticket booking system will be used by customers, agents, and admins. All these groups will have a different perspective of how the software should work for them, so it's essential to include all of them in UAT
• Operational Acceptance Testing: Operational testing ensures that software is ready to be used and maintained in a live environment. Typical checks can include Back-up facilities, training for end-users, Disaster recovery plans, etc.
• Alpha Testing: Alpha testing is usually carried out by the internal staff of the software development company. It's done when the software is at the verge of completion, and it's done at the developer's site. The team could include an independent testing team.
• Beta Testing: Beta testing is done by a group of customers. It is done at the customer's site and usually performed after Alpha testing has been completed successfully.

Test levels have a hierarchical structure that accumulates from the bottom up. Where the upper levels assume the satisfactory completion of the lower level tests. Each of these levels of testing has a specific goal, and that helps ensure minimal repetition across the levels. Without this structured approach, a big-bang test approach, which would mean doing multiple test levels in parallel would be a very daunting task. Below is the diagrammatic representation of the test levels.

Attributes of the Test Levels

Test levels are characterized by the following attributes:

• Specific objectives: Each test level has a predefined objective. Such as a component test is used to verify a single unit of source code. The objective of unit tests is to isolate the smallest testable parts of an application and verify that it works properly in isolation. Similarly, the integration testing verifies that the integrated components, are working correctly, and any data flow between them is seamless.
• Test basis, referenced to derive test cases: Test basis is all the documents from which the requirement of a component or a system can be inferred. Each of the test levels has a test basis which should be referred to create scenarios for that test level. E.g. for a component testing, the test basis could be code or component specifications. For Integration testing, the test basis could be sequence diagrams or component level architecture.
• *Test object: Test Object describes what should be tested in a test level. This refers to the component, integrated components, or the full system. Each test level has a different object to test. For example, for unit testing test object Code, Classes, component. For Integration testing, the test object could be Interfaces, micro-services, etc. *
• Typical defects and failures: As the focus area for each level of testing is different, the kind of defects that they produce also differ. Component-level testing would typically result in defects related to incorrect code and logic. Integration testing between two components will result in defects related to interface mismatch, and incorrect message structures. E.g. On a Flipkart website, when you integrate product detail page with cart page, a typical error could be that Cart page expects some mandatory product attribute that is not passed by the product details page.
• Specific approaches and responsibilities: The test levels follow the bottom-up approach, which starts from Component (Unit) testing and goes on to Acceptance testing.
  • Unit testing is performed by developers, and generally, they follow the approach of fixing the defect as and when they find it without a formal defect management process.
• Integration testing verifies the flow of data from one module to another module. It's often the responsibility of developers, but testers can also contribute to it.
• System testing is done by the testing team, and the approach is to focus on overall functional and non-functional behavior of the system. Typically it's done in a dedicated environment that mimics the production environment in terms of hardware and software.
• Acceptance testing is the responsibility of customers, end-users and product owners. The approach for Acceptance testing is to test the whole system from an end-user perspective, and also check the usability aspects of the system along with functional aspects.

Each level of testing is characterized by an environment, that is, a type of hardware, software, data, and interface. We also found that Unit and Integration testing are usually performed in a development environment. While for System and Acceptance testing, a production-like test environment is ideal.

The cost of maintaining the software is much more than the cost of producing the software. To reduce this maintenance cost, the testing process across each of these levels should be efficient and well planned.

In this article, we have seen different levels of testing and also got an idea of how each of these test levels contributes to the success of overall software. Now that you are clear on the objectives of each of these test levels, I am sure you will apply it in your real-time projects and ensure efficiency and optimization of the test process.