So for anyone following my blog posts currently about the conference, are asking themselves “How are Orges like Web Services?” To that I must give credit to Brian Bryson from IBM who used it in my first presentation on Testing SOA Applications.
Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their life cycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. – Wikipedia Definition
The above is a small summary of what SOA actually is. To the traditional tester this means a different way of approach compared to traditional interface level testing. As the traditional model will most likely be an Interface wired up to a Web Service, we need as testers to remove the Interface from our testing to truly be able to functionally test the web service. This means,
Gui-less or “Headless” testing. This is the idea of testing beneath the interface layer and testing the web service directly. This means that the functional test must interact directly with the web service, similar to testing of API’s or Object level testing. Here is some of the reasons why you should test beneath the GUI layer.
- Application level validation – The GUI may restrict you from the data you input that does not guarantee that the application/service will be tested to handle bad data. The web services has no input validation it will accept what you send it, but the question is “How will it handle it?”
- Security – Data via an interface is usually malleable and easy to manipulate. This can cause security weakness. Testing beneath the interface allows you to be better aware of how the service handles malicious data.
- Performance – The web can be a bottleneck, testing the application/service beneath the GUI will allow you to accurately get a feel for how well the service itself can handle under heavy load.
So the main way to achieve this testing effort is via automation. This is one of the area’s in software testing where Automation is a must. It is not an easy manual effort and web service components are usually constantly changing, and automation testing will help with the regression testing effort and ensuring that the web service is maintaining its ability to meet its requirements. Below is a few hints on how to test SOA apps.
- Use SOAP Testing tools to gain easy access to Methods to data input.
- Try functional level tools such as Fitnesse to deliver functional level tests integrated with acceptance tests at low cost.
- Try security testing methods like Injection, overflow, malicious data, parameter tampering.
- Boundary Test, The web may limit character intake, but does the method?
- If inter service testing – does the data being sent back always come in a form understandable by the requesting service?
- Load test the service – How does it handle under extreme requests/transmissions? Monitor the CPU/Memory usage on the service machine. Is there memory leaks?
- Data Variation – Try anything. Combinations of Data and values to really understand how the service handles varying sorts of information.
Now that you have some basic idea’s, there will be many variations of tools on the marketplace to help you achieve your testing goals, whether it be open source or license software. The main thing to remember is use your head and don’t follow the traditional path, but the road less taken.