I use to be a very strong advocate for SOAPscope. That's before I upgraded from v4.1. to v5.2. Now I have an odd bug where I have to re-enter my licensing information every time I start the server. SOAPscope crashes when I attempt to add certain WSDLs to my project. And the new user interface is much much slower and a bit more clunky looking (making it difficult to navigate).

soapui to the rescue! A co-worker, Steve Keizer, turned me on to soapui yesterday. Then I noticed Chris McMahon had blogged about it (a strong reference in my mind). Within ten minutes, I had it up and running, pointing to my WSDL (the one that crashes SOAPscope), and had executed my first test. And, it's free...

Web Services are everywhere. If you want to build your web service, there are chances that you will be developing it on top of/or using some existing web services. Also, output of your web service might be consumed by some other web services. During my involvement in testing web services one thing that I found very challenging is the scope of Web Services testing.

You start doing security testing and will come to know that you do not have to cover security testing because our web services are using some back end web services and hopefully they must have done job properly. Similarly there are other aspects of functionality, which you will not be testing and will be relying on other web services for your task. Well, I am not opposing the concept here all I am saying is that it makes it difficult to figure out what to test and what to leave for other people/teams.

As I am quite busy lately with testing Web Services, I found this article by Bernie Domanski, Ph.D. in z/Journal Review a great introduction into Web Services and the common performance issues that will pop up in your implementation.You can read the article here (http://zjournal.com/PDF/domanski.pdf). (PDF File)