As more applications move towards Service-Oriented Architecture (SOA), it is imperative to at least know the basics of SOA Testing. To start with – Service-Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing enterprise systems where business needs and technical solutions are closely aligned. Continuing on our pursuit of identifying different ‘Types of Software Testing‘, let’s look at SOA Testing closely…
What is Service-Oriented Architecture?
How do you pay your utility bills? Or for any ecommerce purchase? Now-a-days most of us pay it via debit card, credit card or net-banking, right? But have you ever thought how it works? What is the Billdesk option? Yeah! It’s a payment gateway. Did you know that e-commerce website and payment gateway are two different systems altogether? Payment Gateway is a ‘service’ which can be reused by any e-commerce site. Whenever a payment needs to done, the e-commerce site calls/Requests the Payment Gateway service >> after payment is done a response is sent to the e-commerce website!
As the name suggests, Service-Oriented Architecture is an application architectural style where different modules / components are integrated via ‘services’ to meet the business needs. As you might have guessed, distributing & then integrating individual components (services) helps to maintain the agility and flexibility to business processes. The changes to the process or application can be directed to a particular component without affecting the whole system. Services, the building blocks here, can be added, removed or modified according to the business function they perform. By allowing companies to decouple business logic, and consume both legacy apps and new components of logic at run-time as workflows, new applications can be delivered faster, and cheaper.
As the name suggests, Web Services are nothing but independent application components available for use over the internet (web). The most common way to implement a Service-Oriented Architecture based system is with Web services, but the standards that define Web services are evolving rapidly and many of the Web services tools are still somewhat immature.
- Service Provider (say Payment Gateway) publishes the service over Internet
- Connection: The client application (say e-commerce website) sets up the communication to this service via a URL and a WSDL.
- Request: The end-user (it’s we) chooses the payment gateway at checkout >> an http connection is established between client application and the Service provider via SOAP message.
- Response: After successful payment, Service provider sends the SOAP message response embedded into the http response back to the client application
Service-Oriented Architecture (SOA) Testing
Now that you know the concept of Service-Oriented Architecture, what do you think should be SOA Testing? Yeah! Testing of the applications built using Service-Oriented Architecture, i.e. different loosely coupled services. While testing a SOA based application – what should be the main levels or focus areas of testing? Let’s discuss…
- Service: First & foremost – the Services J testing if the deployed service is satisfying the business function it is designed for. Each and Every Service needs to be first tested independently, i.e. request-response.
- Process: Secondly the Integration, i.e. whether the integrated application (front-end ó service(s) ó back-end) is working as expected.
- End-to-End: Last but not the least – the User Interface. The front-end. After all that’s the first thing which user sees 😉
Few Challenges in SOA testing
- Stubs/Drivers: The biggest of all is the lack of interfaces for Services. A service connects two components, e.g. a website and a database. Most of the times, while testing a web service one of the component will be unavailable (under development, third-party, not tested, etc.). Stubs and Drivers are used to imitate the interfaces.
- Before progressing, the complete architecture of the application needs to be understood, even by the Test team
- Since business needs and technical solutions are closely aligned in an SOA application, Test design need to be based on both business and technical analysis
- Test Data: Testing process spans across multiple systems thus creating complex data needs
- Distributed: Service-Oriented Architecture is a collection of heterogeneous technologies, i.e. SOA Testing requires people with different skill sets. Additionally, it might involve different third-parties developing and testing different components.
- Since the application is an integration of multiple services – Security testing (authentication and authorization) is pretty much difficult.
- Since an individual service might be used by different applications, Performance testing should be done for fine tuning and optimum performance.
- All level of testing should be done for a successful delivery – Service, Process & End-to-End
SOA Testing Tool – SOAP UI
Though there are many tools available in the market for SOA testing but SOAP UI stands out as the most popular among all – might be because it’s open-source 🙂 Developed by SmartBear, SOAP UI is an open source & by far the most popular functional testing desktop tool for Services and API Testing which supports multiple protocols – SOAP, REST, HTTP, JMS, AMF & JDBC.
Note: There are some open source and commercial tools to aid some part of testing SOA-based applications. However, there is no evaluation criteria in place to assess these tools and find out if they provide the facilities that are needed to fully test SOA-based applications.
Service-Oriented Architecture offers a number of potential benefits, such as cost-efficiency and agility. However, adopting Service-Oriented Architecture is not without considerable challenges. Though Web service is an important component for many SOAs, but if you’re only testing web services, you are not likely testing the entire technology stack that makes up the application. With so many interconnected parts making up applications that can be delivered virtually anywhere, testing no longer becomes a mere matter of finding bugs within the developer’s code, or problems that occur on a given user interface. Perhaps most importantly, there are serious challenges related to the testing of SOA-based systems that must be addressed before the Service-Oriented Architecture paradigm enjoy broad-based success.