Open In App

Software Testing – SOA Testing

Last Updated : 26 Nov, 2022
Improve
Improve
Like Article
Like
Save
Share
Report

SOA Testing is the process of evaluating a certain software where one can check web processes for functionality and make sure different components can communicate effectively throughout. Before diving deep into the testing model directly we need to understand SOA Architecture.

What is SOA?

Service Oriented Architecture (SOA) is an architectural strategy that allows programs to utilize network services. It defines a way to make software components reusable and interoperable via service interfaces. Through a network call made over the internet, services are offered to create applications in this architecture. The service integrations in apps are accelerated and simplified using widely used communication standards. The best feature, all these microservices are completely independent and can run without any particular set of supporting application programs. 

SOA

 

What is Service?

A self-sufficient, independent type of software that completes a specified duty is known as a service. It comprises three subcomponents:

  • Interface: The interface here specifies how a service provider will carry out requests from a service consumer.
  • Contract: The contract here refers to the set of instructions about how the service provider and service consumer will interact.
  • Implementation: The implementation is the code used for executing the concerned service.

Here are a few characteristics of services:

  • It logically depicts a commercial activity with a predetermined result.
  • It can stand alone.
  • For its customers, it is a mystery.
  • It could include other supporting services.

What is SOA testing?

SOA uses a large number of technologies. Applications developed using SOA comprises a collection of loosely connected services. This testing emphasizes the following 3 system layers:

  1. Service Layer: As it clarifies, it includes services that are being offered to the user as per the SRS document provided. For instance, a social media application contains, login/sign up, post, delete, edit services, etc. All these services interact with the attached database and retrieve the required information and execute the desired service.
  2. Process Layer: This layer consists of the processes and services that make up a single functionality. UI and procedure are emphasized primarily on this layer. As per our example, a social media application takes a lot of UI and database integration as here every click leads to a completely new process. We take into account the following operations: removing data, creating new trackers, updating data, and adding new data.
  3. Consumer Layer: As the name itself suggests, this is the consumer’s layer i.e. it is the medium by which the consumer and provider interact. Hence, this layer contains the entire user interface. As per SOA architecture, a sub-classification in the consumer layer is described as follows:
    • End-to-end level.
    • Interface level.
    • Service level.

A top-down approach is used for test design, as in designing, the services multiply on each level starting with just UI and Database. And a bottom-up method is used for test execution because test execution, the bottom-most layer has the largest number of independent services that are required to be tested first and foremost in order to check if their independent functionality works or not.

SOA Testing Strategy

SOA testing strategies are divided into two categories:

1. Test Planning Approach:

  • The testers must be able to completely understand the architecture of the application in order to test it. As this understanding will finally determine the working strategy while planning a test.
  • To simplify the test planning approach we must break down the application into several services. And test them independently in terms of their functionality, working parameters, usage, etc.
  • As per the SRS document, the application’s architecture should be classified into generic as well as application-specific categories. For example, Login/Register should be a generic category, and the functions to calculate the amount should be in a specific category.
  • A complete application should be divided into various components, like data (local storage/database), services (Login/Register), and the front end. 
  • It is essential to study each element and predict all possible use cases for them so that one can have all exceptions covered.
  • All test cases should be linked to the company’s scenarios using a complete checklist.

2. Test Execution Approach:

  • Each and every aspect of all the services should be tested independently, irrespective of its precedence, order of occurrence, size, complexity, etc.
  • Data flow validation and verification is an essential function of integration testing. After individual testing (Unit Testing), integrated testing determines whether the services collaborate well.  
  • To ensure that data flows smoothly between the front-end application and the database, it is best to conduct system testing. Where an independent team, tests the whole application with just SRS documentation as a reference and yields unbiased results.
  • Performance testing is an effective way to ensure the maximum possible efficiency and improve the overall quality of a system. As it determines what are parameters required to be worked upon for increasing the efficiency, speed, and accuracy of the program.

SOA Testing Methods

Below are the different SOA Testing Methods:

  1. Data Driven Testing: Data Driven Testing, here data pools, CSV files, Excel files, ADO objects, ODBC sources, and other types of files are typically involved in this sort of data file. The test scripts are written by the testing functions, which also read the test data and output values from the data store.
  2. Stubbing: Stubbing refers to the procedure of using stubs. These stubs are like placeholder interfaces, to test the dependability of an application’s independent services. User interaction to a certain level is possible using them. For example, While filing any form online, we often get messages like “Required”, “Weak Password” etc. Such interactions are done using placeholders.
  3. Regression testing: Regression testing is essential when a software product is revised periodically, and newer versions are released from time to time. Thus, to ensure to provide the same stability, efficiency, and performance of the application, regression testing is required.
  4. Service level testing: Service Level Testing refers to the evaluation of individual services and all the parameters of a service in terms of their performance, accuracy, time/space complexity, and efficiency.
  5. Functional testing: Functional testing verifies that the application properly satisfies the requirements or specifications. This kind of testing is especially interesting in the outcome of processing. It concentrates on simulating actual system utilization and makes no assumptions about system structure.
  6. Security testing: Security Testing as the name suggests deals with all kinds of risks associated with the software or service in reference. In order to prevent the loss of information or the organization’s reputation, security testing of any system is essential.
  7. Performance testing: Performance Testing is used for determining the ultimate efficiency of the product associated. It is done using checking parameters like time complexity and space complexity. Finally, it results in understanding the scalability, stability, and reliability of the software.
  8. Integration testing: Integration Testing focuses on detecting if the interface is accurate or not. It is not an independent testing procedure as it involves, unit testing of all modules first followed by testing them once they are integrated all together.
  9. End to End testing: End to End testing as the name self explains covers all the aspects of the software right from the beginning till the very end. It is also not an independent process, it includes multiple unit testing procedures involved followed by integration testing, and then some of the attributes like the database are changed in order to reconfirm the reliability of the software. 

Challenges faced in SOA Testing

  • Increased workload: Since these are independent services, there are many interfaces i.e. one service has one interface and because of this, the workload increases exponentially.
  • Increased cost of hardware: This testing is itself a complete plan, as initially all services are tested independently and then in collaboration with all complementary services which automatically increases the cost of hardware, and memory and ends up taking a lot of time. 
  • Regression testing is a must: The software is vast in nature and comprises a number of different functions and these functions frequently update themselves as per the needs. Thus, regression testing is a must here to ensure that not only do these new updates break existing functionality but also collaborate as smoothly as possible.
  • Debugging is difficult: The multilayered SOA architecture makes it complex and debugging becomes difficult, as the process requires examining an individual layer multiple times and ensuring its integration with all the fellow services is working as expected or not.
  • Performance testing is unexpected: Planning a performance test is completely based on the hit-and-trial method. Here no one can predict how much load will be placed on the service when it is used along with the other service’s interfaces. 
  • Different skill sets are required: A variety of different technologies are used together and then finally SOA is formulated. People with a variety of skill sets are required for testing an SOA application, which automatically increases the price of planning and testing any project.
  • Security testing is challenging: Security testing comes with its challenges because it requires a deep understanding of all the services individually, which are going to be clubbed together. As the applications expand, it becomes challenging to handle security. 

Benefits of SOA testing

  • Platform Independent: SOA combines numerous services from diverse sources, such as different platforms and codes, to create a sophisticated unified system out of separate services.
  • Highly Scalable: Every organization is unique in terms of the services or goods it provides, as are their ever-changing demands. SOA enables services to run on various servers inside the same environment, enhancing flexibility. If the volume of data grows, it is simple to manage by launching more instances of a service to meet the demands of your organization.
  • Easy on Maintenance: SOA is self-contained, and testing, updating, upgrading, and maintaining applications is simple. As an important feature, the user will encounter no problems or complications while reacting to company demands and technological improvements.
  • Functionality Reusability: In SOA services are reused, which reduces costs and saves time. It lowers the costs of deployment, development, maintenance, and integration. Many websites, for example, utilize Google Maps to identify addresses. Instead of developing a new location service, they just utilize the current one.
  • Highly Reliable: Service-Oriented Architecture creates more reliable apps since shorter codes are easier to debug than huge programs and may be fixed in a specific component without impacting other features.

SOA Testing Tools

Below are 4 SOA testing tools:

  1. SOAP UI: It is an open-source program used for testing Services and APIs. It is a desktop program that supports a variety of protocols, including SOAP, REST, HTTP, JMS, AMF, JDBC, and others. Assists in the development, inspection, and execution of web services. Load testing and automation testing both can be conducted using SOAP UI’s built-in functions.
  2. iTKO LISA: It is a product package that provides a functional testing solution for distributed systems i.e. a number of systems connected to each other in a network. Its potential usage includes regression testing, integration testing, load testing, and performance testing. It is preferred for creating and running test scenarios while testing a service.
  3. HP Service Test: HP Service Test is a functional testing tool that can be used for both UI and shared services testing. It allows for both functional and performance testing with a single script. It is compatible with HP QC, allowing for the accurate simulation of JEE, AXIS, and .NET systems.
  4. Parasoft SOA Test: API testing has been made easier with this analytical tool set. Multiple Web Services, REST, MQ, JMS, TIBCO, HTTP, and XML protocols are covered under this tool. A bunch of testing methods like functional, integration, regression, security, and performance can be conducted. 

SOA Testing Solved Example

Let us consider an e-commerce website with the following functionalities and sub-functions:

SOA Testing Solved Example

 

1. Phase 1: This is the testing strategy phase, here the app is divided into Services and business functions. Let some of the services be as follows,

  • Sign up/Register a new user i.e. add the details of a new user into the database.
  • Sign in/Login a user on the portal i.e. fetch the details from the database and if the correct credentials are, login is successful. 
  • Check the “Forget Password” button functionality i.e. when a registered user presses this button, send a code to the registered email. 

2. Phase 2: Now comes the test planning phase, where distinguished test cases are written as per the level involved. Some possible test cases according to various levels are discussed ahead.

  • End to End level: Each and every use is monitored here and test cases regarding every case are created and the service is tested for the same.
    1. Place one order from a registered user i.e. placed an order by logging in on the portal.
    2. Place one order from a newly registered user i.e. placed an order by registering first time on the portal.
    3. Place one order where multiple items with quantity as “N” are present in the cart.
    4. Completely cancel one placed order i.e. order in active state i.e. delete an order
    5. Cancel or remove a few items from a placed order i.e. edit an order
  • Integration level: In this level test cases are written for database and user interface integration. A few of these kinds are given ahead.
    • Build a new test case, where an order with a single item has been placed along with verifying whether it is reflected in the database or not. (check the integration on both sides i.e. UI and Database)
    • Build a new test case, where an order with a single item has been placed along with verifying if the reflected amount in the database and the calculated total amount are the same. (check the integration on both sides i.e. UI and Database)
    • Build a new test case, where an order with a single item has been placed along with verifying if the availability of the product is accurate or not. (check the integration on both sides i.e. UI and Database)
    • Ensure that the order status displayed on the user interface is the same as that of the database order status i.e. double check order status (both UI and the Database)
  • Service level – Each and every service is tested for all possible test cases.

3. Phase 3: This phase is the “Execution” phase. Here all the final outcomes are released as per the operation performed. Test execution follows a bottom-up strategy, which means that service-level testing comes first, followed by integration-level testing, and finally end-to-end testing. The table attached ahead helps in understanding better.

Test Case Request Predicted Result

“Sign up/Register”

Name= GFG user123

Email = #####

Password = $$$$$$

Confirm Password = $$$$$$

(Check if all details match use cases for min password length, security password condition, etc.)

  • if, Yes grant registration completed.
  • if, No give warnings.
   <message>Registration Successful/Failed</message>

Sign in/Login”

Email = #####, Password = ########

(Details sent by dummy user)

(Get the Sign in done, check if details match in the database)

  • if, Yes grant login access.
  • if, No give warnings.
  <message>Login Successful/Failed</message>

“Forget Password”

Registered Email = geek@example.com

(Details sent by dummy user after click)

(check if it exists on the database)

  • if, Yes send OTP on the Email.
  • if, No give warnings.
<message>Successful/Try Again</message>

“Edit Order”

Order Id = ABC123

(Details sent by dummy user)

(Check if an Order is placed for the logged-in user display the an edit button)

  • if, Yes let the user edit.
  • if, No give warnings.
  <message>Order Edit Successful/Failed</message>

“Delete Order”

Order Id = GFG001

(Details sent by dummy user)

(Check if Order is placed for the logged-in user and display the delete button)

  • if, Yes let the user deletes.
  • if, No give warnings.
<message>Order Deletion Successful/Failed</message>


Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads