How to Test a Web Service

As a web service is something that has no user interface, we can’t interact with it without a special tool. That tool should allow composing XML requests via its own user interface. Commonly such user interfaces are text editors where you write your XML requests and controls for posting requests to the server.

Why not just unit tests?
Unit test is essential for every piece of program code. In many companies there is even a convention that code that did not pass unit test is not given for testing by quality control people. Unit test is simply part of development, not testing.
The minuses of considering passing unit tests enough acceptance criterion for a web service are:

1. Unit tests are developed by a developer. Usually by the same person who has developed the application being tested. If a developer misunderstood a requirement or made a mistake in program code, many of his faults will be duplicated in the unit test.
   
2. Classical unit tests are designed to test internal program code. But what is needed is to generate and run SOAP requests to web service methods. So if follow terminology that will be not unit tests but automated tests. And automated testing is activity carried out by testers, not developers.
   

One of the best tools (and the one I have experience with) is SoapUI by Eviware, and here are its advantages I used when testing a web service:

1. Project structure. As in every well-established testing activity, I’ve started with test specification. The main part of a test specification is test cases divided into test areas. SoapUI allows structuring your test project into test suites (the same as test areas in my test specification) that contain test cases, which can contain test steps. This structure is well-managed in SoapUI – you can add, modify, delete and change order of every item in the structure.
   
2. Test cases. SoapUI provides enough convenient tools to manage and run your test cases, and view SOAP responses to your test requests.
3. You can perform Load Testing.
   
4. Automation. But what if your web service contains too many methods with too many input and output parameters? It may take several days for each complete test of your web service if your tool does not provide functionality to automate your testing. SoapUI supports Groovy Script – a scripting language that is very similar to Java. I’d classify it as ‘light Java’. You can write scripts to access the database which is used and / or influenced by your web service. You can automate validation of your web service’s response against you input. You can automate the output of validation results into a file (which could be just a text file of HTML depending on your choice). And you can run an entire test suite with one click, which, combined with your validation and output automation scripts, allows you to perform entire test of your web service in minutes.
   

Free vs. Paid Version.
Paid version provides more convenience and is very good if you do not have experience in programming or scripting. For example, instead of finding out how to connect to a database in the free version, you can buy paid version which contains a special type of test step – "database connection". Read more at the product comparison page.

Summary.
Testing should be performed by somebody anyway it requires resources in any case. Of course project manager can assign developers who can write scripts similar to unit tests but testing not only internal methods in program code but making correct test requests via SOAP protocol. But since testers are responsible for testing why not use tool that does not require knowledge of complicated technologies like .NET? A tester who has some experience in programming can organize and perform test activities efficiently with help of SoapUI.