In the advancement of the digital era, as you may or may not be aware we are in the fourth industrial revolution, the importance of integration has never been more critical in the delivery of solutions at a rapid pace. With Integration being one of the three layers of software architecture, other two being data and the presentation layer. Service Oriented Architecture has become the defacto standard for integration. But what is SOA? As per wikipedia. “A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. A service has four properties according to one of many definitions of SOA” Below are a few lessons I have learnt through the implementation and testing of web services: Upskilling on web services and integration testing: Learning how web services work is quite straight forward once you are assigned to a project where the technology is used, i.e. not as tough as I had expected. Yes it is easy to install tools like SoapUI or Postman and there are countless of videos online, but in the long run watching YouTube videos wasn’t as impact-full as being thrown in on the deep end of testing the real thing. In actual fact watching all those videos and reading up on the concepts of what SOA and web services testing was contributed to my confusion on the abstract concepts creating an expectation of high complexity. What I am saying in a nutshell is do not be intimidated by the concepts or high technical nature of web services testing. Don’t expect existing web services to be documented and if they are don’t expect them to be helpful though. Setting up a valid message request and then finally getting a successful response is only the beginning of testing: Working in an environment where existing web services may not be well documented, it is a challenge to get a successful response. Much time is spent on having to identify mandatory fields and the format of the data expected in those fields for the message that you are sending. Executing End to End Business Processes test scenarios via web services is lesson of patience, but is well worth the investment : Due to the lack of a front end, the testing team learn the dependencies and intricacies of how the eventual front end will work. For a single click process to be executed there are several web service calls needed to process data. Examples of the web services functions including to lookup data references, calling multiple web services to prepare a transaction or message for the eventual business process you want to execute. You will learn the importance of generating reusable test data: So you need to execute a script, but somehow the input data does not match the database? This happens so often it is devastating to think of a tester who need to execute scripts but who doesn’t have the SQL skills to source data for themselves. Knowing how to generate and harvest test data is crucial for effective running of integration scripts. This is even further compounded when Performance Testing of the integration layer is a requirement. If you want to be efficient you will learn how to automate the creation of test data as part of your data management strategy. Welcome to the world of automation: Due to the nature of web services testing, once you use tools such as SoapUI and Postman, you are in the world of automated testing. Hearing about the abstract concepts of web services and SOA can be very intimidating, but transitioning from testing front-ends to test web services was easier than expected. Tools such as SoapUI and Postman are available with free or trial installations and kickstarting your career, or dabble, in automation testing is open for the taking. Continuous Integration, not yet Continuous Delivery: In addition to storing your integration scripts in a version control repository like SVN or GIT, you are setup to automate the checkout and scheduling of your SOA Integration scripts using tools like Jenkins. Integrating your SOA scripts into Jenkins was one of the first things we accomplished in our movement to a DevOps / CI CD culture.