In the last article, we learned about the software testing and the software development life cycle. We got to know more about various software development models.

 In short, whichever software development model we use, there are several things we must know about good testing:

• For every development activity, there is corresponding testing activity.
• Each testing level has test objectives specific to that level.
• The analysis of design and tests for a given test level should begin during the corresponding development activity.
• Testers should be involved in reviewing documents as soon as drafts are available.

Levels in Software testing

Software testing is a process of testing software to ensure that the product is delivered bug-free to the customer. Levels of software testing ensure that no component is left without testing. There are different levels of testing, each has its own role to perform.

There are four levels of testing:

• Unit/component testing
• Integration testing
• System testing
• Acceptance testing

Let’s discuss these levels, their need and their importance step by step.

Component testing

It is also known as unit, module, and program testing. This is the first level of testing, where a component or unit of a software or product is tested.  It checks for the defects and then verifies the functionality of the product.

Component testing is the testing of individual software components.

Component testing occurs with access to the code being tested. Usually a programmer/ developer does unit testing. Bugs are found sooner and not being recorded formally. This testing is performed by developers.

An approach of unit testing called test-first approach or test-driven development, is to prepare and automate test cases before coding. This approach is iterative and based on cycles of developing test cases, then building and integrating small pieces of code

Advantages of component testing

• As unit testing tests component testing, it is easier to find bugs.
• Since unit testing is testing components, making changes in a small component is easier than making changes in the later stages.
• Unit testing saves time as well as cost.
• Development process is faster as we are focusing on one component at a time.
• Codes can be reused in unit testing.
  

Integration testing

Integration testing tests the interfaces between components or units. The goal behind this testing is to ensure that the interface is bug-free when combined and the software is working fine.

 Integration testing is often carried out by the integrator, preferably by a specific integration tester or test team.

Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.

Let’s understand the integration testing with the help of amazon website.

 Suppose, I am a user and I want to buy a book, what will be the workflow? Now, let’s look into the modules and their integration:

• Sign in/register page: After signing-in or registering my account on amazon, I land to the amazon home page. The flow from sign-in/register page to the home page is where we do our integration testing.
• Search: After landing on home page, we will be searching for the book I want to purchase. Search is a module and connection to the next page is the data flow and integration.
• Product listing page: When search will be done, the result page shows, this page is called the product listing page. Whether the products shown are according to the search or not, this is where we are going to do our testing.
• Product details page: When I am clicking a specific book of my choice, it leads me to the product details page where I can find the description of the book, ratings & reviews of the book, and price etc.
• Cart: I put the book of my choice into the cart and proceed to checkout.
• Checkout: At the time of the checkout, the address is fetched from “my account” section where I have saved all of my addresses.
• Payment: During checkout, the Payment details are populated from the details added in “my payments” section.

Below is the workflow shown for purchasing a book on amazon. We discussed so many components or say modules which were included in the workflow.

 With the workflow, you can see how many different modules are integrated, and how data flows from one module to another.

Testing each of these module is called the component/ unit testing while testing the flow and integration of these modules is the integration testing.

Now, that we understand the difference between the component testing and integration testing in detail, Let’s look into the benefits of the integration testing.

Advantages of integration testing

• Reduces the risk of the software failure.
• Covers multiple modules to provide broader test coverage.
• Impacts the overall test efficiency of the software.
• Helps to detect the issues related to the interface between modules.
• Helps to stimulate the interaction between various modules.

Now, that we have discussed about the benefits of integration testing, let’s go ahead and talk about the levels of integration testing.

Levels of integration testing

• Component integration testing: It focuses on the interaction between the components. For example, the interaction between the order details page and the cart page on amazon. This is usually done by developers.
• System integration testing: It focuses on the interaction between the systems or micro-services. Typically, all the third party integrations are covered into it. For example, there’s an option to share the product details outside amazon through social media, like, Facebook, twitter, and WhatsApp etc. This integration comes under third party and the testing is called system integration testing.

Let’s look the approaches of integration testing:

Approaches of integration testing

Big-bang approach

All components or systems are integrated simultaneously; after which everything is tested as a whole. This is called big-bang integration testing. Big bang approach has the advantage that everything is finished before integration testing starts.

 The major disadvantage is that it is time consuming and difficult to trace the cause of the failures with the late integration.

So, big-bang approach might seem like a good idea when planning the project, being optimistic and expecting to find no problems.

Incremental approach

All programs are integrated one by one, and a test is carried after each step. The incremental approach has the advantage that the defects are found early. A disadvantage is that it can be time consuming as stubs and drivers need to be developed first in order to carry out integration testing.

 Stubs and drivers are used to replace the missing modules in the software and simulate the interface between the software components.

A stub is called from the software component to be tested; a driver calls a component to be tested.

Within incremental integration testing a range of possibilities exist, partly depending upon the system architecture:

• Top-down testing: The testing is done from top to bottom, following the architectural structure or control flow. Components are substituted by stubs.
• Bottom-up testing: This testing tests the lowest module first. The other modules are added one by one moving upwards. Components are substituted by drivers.
• Sandwich Testing: The sandwich approach involves testing the bottom and top modules in the architectural structure of the software.
  In this approach, the whole software system is converted into three layers to begin the testing. First is the middle layer, the second is the layer above, and the third is the layer below.
  The goal of a tester is to reach the middle layer by testing both the layers simultaneously.

In order to reduce the risk of late defect discovery, integration should normally be incremental rather than ‘big-bang’.

System Testing

System testing is the third level of software testing. It aims at testing the complete system or software in different environments. The main purpose of this testing is to evaluate the system’s compliance.

System testing is most often the final test on behalf of development to verify that the system to be delivered meets the specification and its purpose is to find as many defects as possible.

System testing should investigate both functional and non-functional requirements of the system. This testing comes after the integration testing and before the acceptance testing. This testing s carried out by individual testers who are independent of the developer’s team.

To minimize the risks associated with the behavior of the system in a given environment, during testing it is recommended to use the environment as close as possible to the one on which the product will be installed after delivery.

Based on the idea of how to use the product, use cases are created. For a specific use case, one or more scenarios can be defined. Test cases are written for each script to be tested.

Acceptance Testing

When the system testing is performed and all or most defects are resolved, the system will be delivered to the user or customer for acceptance testing.

Acceptance testing is most often the responsibility of the user or customer, and the environment required for executing acceptance test cases is almost similar to the production environment.

The goal is to establish confident in the system or software. Acceptance testing is most often focused on a validation type of testing, trying to determine whether the system is fit to purpose. Finding defects should not be the main focus here.

Acceptance testing may occur at more than just a single level, for example:

• A Commercial Off The Shelf (COTS) software product may be acceptance tested when it is installed or integrated.
• Acceptance testing of the usability of a component may be done during component testing.
• Acceptance testing of a new functional enhancement may come before system testing.

Acceptance testing can be of several types based on the requirements and the functionality:

User acceptance testing mainly focuses on functionality of the system. User acceptance testing is performed by the users and application managers.

Operational acceptance testing validates whether the system meets the requirements for operation. In most organization, system administration will perform the operational acceptance tests shortly before the system is released.

Contract acceptance testing is performed against a contract’s acceptance criteria for producing custom-developed software.

Compliance acceptance testing or regulation acceptance testing is performed against the regulations which must be adhered to, such as governmental, legal or safety regulations.

When the software is being released for the mass users, feedback is necessary from the users. Alpha and beta testing are performed based on these requirements.

Alpha testing is performed by the people who are members of the Organization and not involved in the development team. It is also called as internal acceptance testing as it tests by its own members.

Beta testing is performed by users who are going to use those in the future. It is also called as external acceptance testing as the outsider user tests it.

Now, we know about test levels and their types and characteristics of each level. Let’s move onto our next section which discusses about testing types.

Software testing types

A test type is a group of test activities aimed at testing a component or system focused on a specific test objective.

Test types are introduced because testing the functionality of the component or system at each level is not sufficient to meet the overall objectives.

So, we need to select the appropriate type of testing that helps making and communicating decisions according to the test objective easier.

Above diagram shows the types of testing manual testing includes and their subsets.

Testing of function (functional testing)

The function of a system is ‘what it does’. Some functionalities are ‘assumed’ to be a part of the requirement and not documented. Since, it is difficult to test the undocumented and implicit requirements, these requirements are still a part of the requirement specification for system. Functional tests are based on these functions, described in documents or understood by the testers and may be performed at all test levels.

Functional testing is based on an analysis of the specification of the functionality of a component or system. Functional testing is often referred as black-box testing. Black-box testing can be non-functional also and it is basically done without the knowledge of the code or structure of the system/component under test.

Black-box testing is the testing, either functional or non-functional, without reference to the internal structure of the component or system.

Function (or functionality) testing can be done focusing upon suitability, interoperability, security, accuracy and compliance. Security testing, for example, investigates the functions related to the detection of threats to the software, such as viruses.

Interoperability is the capability of the software product to interact with one or more specified components or system. Interoperability testing is the process of testing to determine the interoperability of a software product.

Security is attributes of software products that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data. Security testing is the testing to determine the security of the software product.

Testing functionality can be done in two perspectives: requirements-based or business- process-based.

In Requirements-based testing, tests are designed as per the functional requirements specified in the requirement specification. We prioritize the requirements based on the risk criteria and use this to prioritize the tests. This will ensure that the most important and most critical tests are included in the testing process.

On the other hand, business-process-based testing uses knowledge on business processes. Business processes describe the scenarios involved in the day-to-day business use of the system. Use cases are a very useful basis for test case from a business perspective.

Testing of software product characteristic (non-functional testing)

Non-functional testing focuses on the testing of the quality characteristics, or non-functional attributes of the system. We are mainly interested in how well, and how fast something is done. Non-functional testing is performed at all testing levels.

Types of non-functional testing includes performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing, and portability testing.

• Performance: The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate.
  
  
• Performance testing: The process of testing to determine the performance of a software product.
  
• Load Testing: A test type concerned with measuring the behavior of a component or system with increasing load. This testing is done by determining the performance of the software application under a specific set of expected load. The goal is to improve the performance issues and ensuring stability and the smooth functioning of the software application after deployment.
  
  
• Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements. This testing is done by determining the performance of the software by increasing the load at or beyond the expected load and check where the system crashes.
  The main goal is to ensure the stability, and performance of the software after deployment.
  
  
• Reliability: The ability of the software product to perform its required functions under stated conditions for a specified period of time, or for specified number of operations.
  
  
• Reliability testing: The process of testing to determine the reliability of a software product.
  
• Usability testing: Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions.
  
• Portability: The ease with which the software product can be transferred from one hardware or software environment to another.
  
  
• Portability testing: The process of testing to determine the portability of a software product.
  
• Maintainability: The ease with which a software product can be modified to correct defects, modified to meet new requirements, modified to make future maintenance easier, or adapted to a changed environment.
  
  
• Maintainability testing: The process of testing to determine the maintainability of a software product.
  

This is all about the types of non-functional testing and their need in the entire software testing process.

Testing of software structure/ architecture (structural testing)

The third type of testing is structural testing. It is the testing the structure of the software. Structural testing is often referred to as white-box testing or glass-box testing because we are interested in the code/ structure of the software.

White-box testing (structural testing) is the testing based on the analysis of the internal structure of the component or the system.

It can occur at any test levels, but it generally happens at the component and integration testing levels and less on higher levels.

The techniques used for structural testing are structure-based techniques, also referred to as white-box techniques. Control flow models are often used to support structural testing.

Testing related to changes (confirmation and regression testing)

The final type of testing is the testing of changes. If we had made any changes, the functionality, the structure, and the way the software performs, changes. There are two types of testing that checks for the defects in software after the changes are made.

Confirmation testing: When a test fails and we determine that the cause of the failure is a software defect, the defect is reported, and we can expect a new version of the software that has had the defect fixed. In this case we need to execute the test again to ensure that the defect has been fixed. This is known as confirmation testing (also known as re-testing).

            When performing re-testing, we have to keep the same data sets and the same environment that we were using before the changes were made.

Regression testing: When the changes were made, the software goes into the re-testing phase. After completion of re-testing/confirmation testing, the fix may have introduced or uncovered a defect in some other part of the software.

After the re-testing is done, regression testing is performed in order to find the defects in other parts of the software where the change has not been made.

            All the test cases in the regression test suite would be executed every time a new version of the software is produced. Regression tests are executed whenever the software changes.

Now, we know all about the software testing levels and testing types. We will be moving onto the next topic where we will be discussing about the software testing techniques.