Introduction
When a new project is released, its creators often have to optimize its development and promotion expenses. This is especially true for different startups and projects that are in their early development stages. As a result of that, the following questions may arise:
- How to save money on startup development?
- How to sensibly develop an MVP?
- How to effectively invest in development?
And the answer to all of those lies with SOA – Service-Oriented Architecture.
Testing is an important stage in SOA development. It concerns the architectural style of SOA, which has components of the application interacting with each other by means of communication protocols (usually through the net).
So, today we will discuss what is SOA testing, its strategies, methods, and tools.
What is SOA?
SOA is a modular approach to software development. It’s based on remote access with standard protocols to distributed and loosely coupled, easily replaceable services (components) with standardized interfaces.
In simple terms, using the SOA approach is like building something using details from different construction kits – LEGO, Sluban, Ausini, etc. Various details can connect thanks to some universal elements, and can also easily replace each other if necessary. So, SOA isn’t restricted to any particular technology and can be applied using a wide variety of them.
The main thing that makes SOA stand out is its usage of independent services. They fulfill clearly defined tasks, which are triggered in a standard way through clearly defined interfaces. The services have no information of the interfaces (applications) that trigger them, and the apps have no knowledge of how the services perform their tasks.
Let’s have a closer look at services and how they operate.
What is a Service?
A service is an entity that fulfills a specific function of either a program or a business process. It can be used multiple times and simultaneously in different business processes and applications.
Let’s say you want to add a weather forecast to the main page of your online shopping site. In that case, the website developers just need to purchase the necessary service from a third-party vendor and integrate it into the webpage. There’s no need for them to make a new weather forecasting module from scratch, and no need for the business owner and the project founders to waste extra resources on it.
The process of implementing a service looks something like this:
- A service provider puts the service up on the internet (into the Web Services Registry).
- Our website (our client, to be precise) makes a search request for the needed service in the Web Services Registry.
- The Web Services Registry tells the client the address of the necessary service. It gives a URL and a WSDL (an XML-based language used for describing web services and accessing them).
- An HTTP connection is established via a request to the service provider. A SOAP message tells the provider which particular service logic needs to be used.
- The provider’s response will be built into the HTTP response. It will be presented in the format appropriate for our application.
When all is set and done, the website will gain a new fully functional feature – in this case, a weather forecasting module.
SOA Testing
SOA consists of various technologies, and applications developed using SOA are made up of different loosely coupled services. Them being loosely coupled means that the connections between components are weak (but unbreakable), so changes in one component don’t affect the other’s existence or performance too much.
An SOA system like that can look as follows:
Because of this structure, SOA testing has its fair share of specifics. It concerns the architectural style of the SOA, where application components interact using communication protocols, usually via the net. Needless to say, testing itself is a very important part of using SOA effectively.
SOA testing can be divided into three main layers.
Services Layer
Let’s imagine a travel website that allows users to book a room in a hotel and get plane tickets based on that hotel booking. In that case, the services provided by the website would have to include:
- Hotel booking;
- Ticket booking and purchase.
The website will have to choose flight options based on the date and location of the booked hotel. Since this is the main business advantage of the website, this level fulfills the business requirements of the project. The website functions will display the data from the necessary databases and link to multiple different services, including:
- Hotel search service;
- Hotel booking service;
- Flight ticket tracking service;
- Ticket purchase service.
The connections in the services layer can be represented as follows:
Process Layer
This layer deals with the processes happening in the system after the user interface is activated. The systems interact with each other by interprocessing different kinds of data, which allows the user to receive the result that matches their technical and user requirements. The functional spectrum of data processing includes:
- the function to create new data;
- the ability to add corrections to an existing data block;
- updating and adding new data groups;
- correctly destroying unclaimed data.
If we refer to the example above, the project’s users will be activating the services from the upper layer (Services Layer) to work with the lower layer (Process Layer). Here’s how it connects to the services layer:
Consumer Layer
This is the level at which consumers interact with the SOA. It lets the SOA maintain a set of functions that is independent of both the client and the channel. Each of these functions is used separately and is displayed through one or several channels. Essentially, this layer is the entry point for all external consumers (relative to SOA). They can be other systems, other SOAs, cloud service users, people, etc.
This division between a consumer and the rest of the base SOA lets organizations maintain flexibility and facilitate more repeated uses, as well as improve quality and coherence. The consumer layer connects to the others as follows:
Now that we have a certain understanding of how the three SOA layers connect, we can discuss how they are tested.
SOA Testing Strategy
How to Plan SOA Testing
You can’t just jump into an SOA solution test unprepared. There are a couple of precautions and preliminary measures QA specialists need to take before starting the process. They go as follows:
- Testers must understand the full architecture of the application. The app has to be split into independent services (an independent service has its own request and response structure and doesn’t rely on any other service to form a response).
- The application structure must be reorganized into three components – data, services, and interface apps.
- Every component must be thoroughly analyzed; business scenarios must be written.
- The business scenarios should be classified as general scenarios or scenarios for specific apps.
How to Carry Out an SOA Test
After doing all of the above, you can get started on the testing itself. The basic principles of of an SOA test are:
- Every service component must be tested.
- Integration testing is necessary for checking the data flow between various services and data integrity.
- Performance testing must be carried out for the sake of precise configuration and achieving optimal performance.
- System testing of the entire model is necessary to check the data flow between the client application and the database.
But these are just the core notions of SOA tests. There are several test types, each of which has its own general strategy. So let’s have a quick look at the 9 SOA testing methods.
SOA Testing Methods
Tests Based on Business Scenarios
As the title suggests, this kind of tests use business scenarios as their foundation. Here’s how you do it:
- Analyze different business aspects connected to the system.
- Develop scenarios based on the integration of:
- Various web services of the application;
- Web services and the application.
- Configure data based on the scenarios described above.
- Configure data so that it also covers end-to-end scenarios.
That way you can ensure that the software performs as it’s supposed to in any given situation.
Stubs
A stub is a controllable replacement for an Existing Dependency (or collaborator) in the system. By using a stub, you can test your code without dealing with the dependency directly. Here’s how you can work with stubs:
- Create fictive interfaces for service testing.
- QA specialists can input various data into these interfaces and then check their output.
- You can create a stub during integration testing, when the app is using an interface of a third-party service that сan not be tested.
It’s a very simple and effective method of checking the app’s performance.
Regression Testing
Regression testing checks if the changes you’ve made to a piece of software have negatively affected its existing functionality.
- You should do regression testing when the app has multiple releases in order to ensure the stability and availability of its systems.
- Create a complex set of regression tests which covers the services that make up an important part of the app.
- This set of tests can be used multiple times for different project releases.
Service Level Testing
Service level testing, unsurprisingly, concerns the services of an SOA application. The main conditions are:
- Service level testing includes tests of a component’s functionality, security, performance, and compatibility.
- Each service must be tested independently at first.
Functional Testing
Each separate component must go through functional testing in order to:
- make sure the service correctly responds to all requests;
- make sure correct error messages are displayed when incorrect data is entered (after entering a wrong password, for example);
- check if the service correctly processes the request and response for each of its operations;
- check error messages if they occur on a server, client, or network level;
- ensure that responses come in the correct format;
- ensure that the response data is the data requested.
Security Testing
The following factors must be accounted for during security tests:
- The service must conform to the industry standard defined in WS security testing.
- The security measures’ work must be impeccable.
- Data encryption and the encryption of digital document signatures, authentication, and authorisation.
- Test for SQL injections, malware, XSS, and other vulnerabilities.
It’s integral that you’re very thorough with this kind of testing, for (hopefully) obvious reasons.
Performance Testing
Performance testing is necessary, because a service can be used several times in a row and by multiple apps simultaneously, which can lead to a sharp decrease in its speed. As a result, performance tests must account for the following factors:
- The service’s performance and functionality must be tested in high-load conditions.
- The service’s performance individually must be compared to its performance as part of the application it’s connected to.
- Load testing of a service is necessary to
- check its response time
- check for bottlenecks
Keeping the service’s performance swift will make working with the software more comfortable for both users and developers.
Integration Level Testing
Integration testing analyzes how well all the different components of an SOA solution work together.
- Integration tests mostly concern interfaces.
- This stage encompassess all the possible business scenarios.
- At this stage, the app needs to go through non-functional testing once again.
- Security, requirement, and performance testing ensure the system’s availability and stability across all aspects.
- Communication and network protocols need to be tested to ensure the consistency of data transfers between services.
End-To-End Testing
Also known as E2E testing, this method refers to testing the software’s entire workflow from beginning to end (hence the name). This stage guarantees that the app corresponds to all the business requirements both functionally and non-functionally, making it an ultimate test of sorts.
SOA Tests and Their Issues
SOA testing has a number of issues that we can’t overlook.
- The process encompasses several systems, which creates complex data requirements.
- An application is a set of different components which tend to change. The need for regression testing arises more and more frequently.
- It’s hard to isolate defects because of the multilayer architecture.
- It’s hard to predict loads since the service will be used in different interfaces. This makes planning performance testing more difficult.
- SOA is a set of diverse technologies, so an SOA application test requires people with different skills. This, in turn, increases the planning and implementation expenses.
- Since one application is an integration of several services, security testing comes with its own fair share of problems.
SOA Testing Tools
There are tons of tools available on the market to help testers check the quality of SOA applications. Here are some of the most popular SOA testing tools.
Postman
Postman is a set of tools for API testing. It’s a development, testing, control, and publishing environment for API documentation. The purpose of Postman is to test the process of sending requests from the client to the server and receiving the server’s response.
JMeter
JMeter is a load testing tool developed by Apache Software Foundation. Even though JMeter was initially developed as a means of testing web applications, it’s currently capable of carrying out load tests for JDBC connections, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP, and TCP.
Notably, it can create a large number of requests with the help of multiple computers, with the process being controlled from a single machine. The architecture that supports external developer plugins allows you to expand the tool’s functionality. The program has virtual user authorization mechanisms and supports user sessions. It also logs test results and can visualize them as diagrams, tables, etc.
Conclusion
SOA is a very unique style of software architecture. As such, it requires a very unique approach to testing. Even though the structure of an SOA application may make the process somewhat bothersome, the versatility that this kind of architecture provides is well worth the work.
If you develop your strategy correctly and choose the tools and resources for high-quality SOA testing efficiently, you will be able to deliver a perfectly tested application to your client.
If you have any additional questions about SOA testing or SOA architecture, feel free to drop me a line or book a free consultation with our team. We will be happy to share our expertise!
